Content migration means moving content from one digital platform to another. Sounds simple, right? In fact, there’s a lot of planning, preparation, and decision-making needed for a migration to go smoothly. It’s essential for non-technical people to be involved in the process. So we created this handy guide to help non-developers understand their role in content migrations.
This guide is for you if you’re a designer, marketer, project manager, web editor, or anyone involved with content! It’s based on a talk I recently gave at DrupalCamp New Jersey 2024 with my colleague Marien, and contains insights we’ve gained from dozens of complex migrations over the years.
Read on for a non-technical crash course on content migration.
Is it Better to Migrate Content or Start Over?
It depends on the quality, complexity, and volume of your content, your goals for the new site, and the resources you have available to complete a migration. If your existing content holds value it’s worth exploring your options for a migration, but you may decide it’s more effective to start from scratch. Either way, it’ll take planning and work.
Think of it like moving house. Both my colleague Marien and I moved this year, but our experiences looked very different. I moved across Canada, boxing up all my belongings and spending four days in a U-Haul. There was a lot of sorting, packing, unpacking, and more sorting to do! Meanwhile, Marien immigrated from France to Canada with just a few suitcases. He then had the task of buying new things to fill his empty apartment.
How Much Work is a Website Content Migration?
Again, it depends (annoying but true!). It can take as little as a few weeks to complete a simple content migration, or several months to move a large amount of complex content. Resources are another contributing factor—things go a lot faster when you have dedicated content migration support from an experienced team (you guessed it: like us!).
Our team has supported dozens of migrations over the years so we’ve seen first-hand how unique each migration can be. Our work with the Institut national de santé publique du Québec (INSPQ) is a good example of a large-scale migration—it involved more than 30,000 pages, 30 content types, 500 fields, 500 contexts, 300 views display, and 21,000 files! Although internal migration is better for some projects, in this case we recommended and created migration scripts entirely in code.
What’s the Difference between Manual and Automated Migration?
It’s possible to move content manually by copying, pasting, uploading or recreating it on the new website. But the process can be tedious, time consuming, and prone to human error—especially if you have complex content or a lot to migrate.
Automating your content migration with software tools or code can be faster, cheaper, and more consistent. It can also make it easier to track and monitor progress. You’ll need technical expertise to customize the process to your content, ensuring accuracy and efficiency. Also, it’s important to still do a manual review to identify any issues and opportunities to optimize content.
- Manual content migration may be appropriate if:
- You’re doing a content refresh
- You have a small amount of content (e.g. only a few landing pages)
- Your content is highly unstructured (e.g. all in a WYSIWYG editor instead of blocks or fields)
Automated content migration may be more suitable if:
- You have large amounts of content (nobody wants to recreate 10 years worth of blog posts by hand!)
- Your content is well structured
- You’re expecting a high frequency of content changes, meaning you’ll need to rerun the migration many times
What are the Stages of a Content Migration, and Where Do I Fit In?
Most content migrations will include the following seven stages where the support of non-technical professionals is critically important.
Discovery
If there’s one thing I’ve learned from conducting multiple migrations, it’s that discovery should never be underestimated or neglected. A thorough discovery phase will save time and prevent issues further down the line.
Doing a content audit is a good place to start. Make sure you set up tools like Google Search Console early on, as it takes time to generate useful data. Involve anyone who’s an expert in any area of the website. And be sure to document everything you discover, or it might as well not exist!
Things to review and document include:
- Content types
- Taxonomies
- Content structure (e.g. WYSIWYG or paragraphs, the fields, relationships, etc.)
- Files
- Web forms
- Users accounts
- Blocks
- Views
- Redirects
- Modules
Look out for any dependencies that could cause issues, such as contrib modules or custom code that aren’t compatible with your new CMS. If you’re migrating from Drupal 7 to 10, check out our guide to porting a CKEditor 5 plugin.
Clean Up & Optimize
Many organizations take the opportunity to redesign an outdated website when migrating to a new CMS. At the very least, it’s a good idea to review and refresh your content. Like clearing out your closet before moving house, you should remove any unwanted content before the migration. Some content may need updating or merging instead. It’s also worth optimizing for SEO, and improving the accessibility of your content.
Mapping Content
Next, we’re going to decide where everything will fit on the new website. This is a great opportunity to restructure your site and create a user-friendly information architecture.
You’ll want to create documentation that maps the content source (where it currently is) to its destination (where it’s going.) This includes straight-forward mappings as well as anything that’s changing to improve the structure. For example:
- Old custom fields → New custom fields
- Old content types → New content types
- Uncategorized groupings of content → New content types
- Unstructured page content → New custom fields
- Keyword / text fields → New taxonomies
- Hardcoded components → New blocks
It’s also important to document how the content will be extracted from the source, transformed to fit into the new content model, and then uploaded to the new site. Developers are responsible for this part if you’re doing an automated migration.
Mapping Redirects
If your site structure is changing, some of your existing URLs may not work after the migration is complete (e.g. if you’re retiring or merging pages.) Document where obsolete URLs should be redirected. For example, if you’re planning to absorb a page called “Our Team” into a page called “About Us”, you’ll probably want to redirect /our-team to /about-us. Mapping redirects for a large number of pages can be time-consuming, so ask your web developers to help! We can use tools such as wildcards to partly automate the process.
Trial Runs
Automated migrations need to be repeatable—especially if content on your live website is still changing (although there will usually be a content freeze in the final stage of the migration.) It’s best to start trial-runs as soon as possible. This will help you identify issues and fine-tune the process early on. You may need additional help with the formal testing, so work with developers to decide on the key pages and templates to test.
Content Fixes
No matter how well you prepare, issues are bound to crop up when content starts being migrated. Developers deal with many of these issues—it’s our job to keep tweaking the process until it’s efficient, accurate, and capable of being rerun again and again.
However, there are some instances where content issues need fixing at the source. This is where you can provide essential support! It’s often more efficient for content to be fixed on the old website before it’s migrated, as the latter restricts our ability to re-run migrations.
Testing
As a content expert, you should be involved in testing the content! Check that all the content was migrated and ensure everything is working in relation to:
- Linked images & files
- Translations
- References
- Transformations
- Layout/visuals
- Redirects (including missing redirects and redirect loops)
- Links (e.g. broken)
- Metadata
Some of the migrations we’ve worked on involved tens of thousands of pages. In these cases, it isn’t feasible to check every single piece of content. Developers can help you automate this process to an extent, but some manual review is still required. You can carry out spot checks—for example, you could identify a percentage of pages based on their templates, complexity, features or components. And remember, content doesn’t always have to be pixel perfect. If you’re looking at a blog post from 2015 that doesn’t get much traffic, it’s ok to settle for good enough.
Once the migration is complete, it’s important to monitor user data over the coming days, weeks, and months. Using tools like Google Search Console, look out for things like crawl errors, missing content, and redirect loops. You can also choose to resubmit your sitemap to search engines; this should prompt them to start crawling and indexing your new website sooner.
Get Expert Support With Your Website Migration
Evolving Web helps you migrate with confidence and peace of mind. Drawing on our 16+ years of experience, we offer expert guidance and support from discovery through launch and beyond. We’re a Drupal Certified Enterprise Grade Migration Partner with a track record of implementing Drupal 7 to Drupal 10 migrations for clients like UC Berkeley & Princeton University. Our 90+ technologists, creatives, project managers, and strategists are also ready to meet your design, development, and maintenance needs.