5 critical steps in planning a CMS content migration

Content migration is easily one of the most underestimated parts of any project. Most sites don't create all their content from scratch, so they'll have to move it from somewhere.  There are several technical approaches to doing this - which won't be covered in detail here - but first of all you need to plan the process.

1. Start planning early

Delaying content migration until the end of the project sets you up for failure.  There's no putting this softly: Content migration can easily take weeks of technical work, then weeks of cleanup (manual or scripted). You'll want that work to be completed well before launch, since, having content on your site is, you know, kinda important.

Planning should be part of the initial content strategy phase, and extend into the design phase when you know a bit more about your new content models.

Oh, and make sure to involve some developers in that early planning. They'll have previous experience with migrations, and can help both the client and content strategist/designer watch out for pitfalls.

2. Allocate sufficient budget and client resources

Investing in a thorough content strategy is a given for any successful migration project. In due time, developers will also provide an estimate for the technical side of the content migration, so that's another thing to budget for. But the client should also budget for a significant amount of internal resources throughout the migration.  

Content migration is rarely a streamlined, fire-and-forget process. The client will need to contribute in the auditing process to determine which parts stay and go. Even when using automated migration tools, the client needs to get involved afterwards to make sure content is still relevant and complete. Let's not forget, the client is also responsible for producing new content, which is another frequently underestimated task.

Speaking of budgets, make sure to determine which license models the CMS requires. For instance, Episerver determines this from a combination of the amount of sites, content items, servers and/or traffic, and whether you've chosen a Digital Experience Cloud or on-premise based deployment scheme. Your implementation partner will negotiate the license details for you.

3. Do a content and SEO audit

Migration is faster when the amount of content is reduced to the essentials. To arrive there, we first need to inventory all the content on the old site - pages, blocks (or equivalent), media files and metadata.A content strategist can help decide when to cut or merge existing content, and when to write all-new stuff.

The audit process should be backed up by analytics data - to see which content attracts the most (or least) inbound traffic, and also to determine if the content is focusing on the right target keywords. 

As part of a content re-structuring, it's also common that taxonomies change. Be sure to map all your existing taxonomies to the new regime. That tag cloud of yours from Episerver 5, and the underlying chaos of hundreds of categories, might not be such a hot candidate for migration.

4. Research automatic vs manual migration

Various automatic migration tools exist (, but don't expect them to be a magic cure. While running the migration script might be a matter of clicking a button, the main bulk of this approach is the mapping and configuration of your old and new content models. 

Some tools are the DYI kind that your development team can set up themselves, while some tool vendors prefer (demand, even) that they do the configuration part. While some clients may be loathe to involve another third party, in some cases the end result might be better for it - and it frees your development team to focus on finishing other tasks.

Most importantly when researching automatic migration tools: Don't be wowed by sales demos, make sure the vendor understands the requirements of your new content model, and that the tool is actually capable of pulling it off with the least amount of manual cleanup work afterwards.

5. Handle your SEO

Surprise, surprise: Deleting, moving and renaming your old content will mess up your sitemap. If you launch without handling it properly, inbound traffic will plummet, search spiders won't find your stuff, and users will grow annoyed by all your broken links. 

Your first order of business should be setting up redirects from your old URLs to your new URLs. Episerver needs a little help with this, but you'll find several add-ons that do the job. Most implementation partners even have their own custom-built solutions for this, since this comes up in every single project they deliver. Make sure to return proper HTTP codes (301, 302 and 404 in particular) for stuff that's moved, replaced or deleted. 

Many sites use Episerver's "Simple address" feature, which means several pages will be accessible via both the hierarchical URL (http://mysite.com/events/seminars/my-awesome-event/) and the shorter URL (http://mysite.com/awesomeevent). Search engines typically penalize duplicate content like this, so make sure your pages include the canonical URL metatag. 

Be sure that your new site generates a sitemap.xml file to tell search spiders about all your content, rather than relying on them to discover it all on their own. The sitemap should be re-generated frequently to reflect the up-to-date state of your content structure.