How to plan a website content migration

The first step you need to take when planning a content migration is to conduct an audit of the existing content on your website. This is because you only want to migrate pages that provide value. To return to our house moving metaphor, you only want to move things that you want in the new house. You don’t want to move anything and everything, then bin half of those things once you’re in the new house.

Read our recent insights article for more detail on how to run an effective content audit.

Once you’ve conducted this audit, you’ll know if you have pages that attract very little engagement and can therefore be deleted or rewritten. This will save time and effort by removing the need to migrate them.

Automated content migration takes time to set up, and the main factor in determining the amount of time that process will take is the amount of content types you want to migrate. Once set up for a content type, it’s not significantly more difficult to migrate 10,000 pages than migrating 100 pages.

So ideally you want to migrate as few content types as possible, while still preserving what’s valuable. Any content types that don’t add value to your new site should be discarded. A good example of this is events pages. If your site has events pages that stay live after the event has happened, it’s likely you will have developed a large backlog of events that are no longer of value. Usually, it’s not worth migrating this content type as having events from years ago on your new website doesn’t help you or your users.

You also don’t want to set up automated content migrations for content types that have relatively few pages. Setting up the scripts for an automated content migration takes time, and if a content type has relatively few pages, it will be quicker to set them up again on the new site manually rather than running an automated migration. A good rule of thumb is that if a content type has under 10 pages, it’s probably better to do it manually than run a migration.

We find the content types that most lend themselves to an automated content migration are articles or publications. These are easier to migrate because they can be listed by date and don’t play a role in the broader site structure.

If you’re drastically redesigning how a page works, for example by using different fields that were not on the old page, you may find it useful to just migrate page ‘stubs’, rather than the full page. Migrating page stubs means just migrating the page title/URL to a new unpublished page stub in the CMS. This provides a scaffolding for your content team to then populate using the fields designed for those pages in the new website using your CMS.

You should also review your taxonomy at this stage, as you’ll need to map content to new classifications if you are changing the taxonomy with the new website. Just like with your content audit, you should ensure you’re not migrating anything you don’t actually want on your new site. The milestone of a content migration is an ideal time to reassess your taxonomy and get rid of any classes that aren’t being used or aren’t useful. A common example of this is tags for articles. Tagging systems often become bloated over time as new tags are created without sufficient thought as to how they’ll be used. Rather than migrate these pointless tags, use the milestone of the migration to rethink how you’ll tag content, and get rid of infrequently used tags that aren’t adding value. Better yet, discard the tagging system entirely if it’s not adding value, and use a new way of classifying content on your new website.

Just like moving house, you need to set a moving date, and then work back from that. At some point, you want to start boxing everything up. Start too soon, and you’re left without any plates to eat from. Start too late, and the moving van turns up while you’re still packing.

For content migration, the ‘boxing up’ means providing the final cut of the website to be migrated. That means any changes made to your current website after that point will not be reflected in the new website when it is migrated.

The earlier the final cut is provided, the more time there is for set up and testing, but there’s also more time in which your website will no longer be updated with new content. For our content migrations, we usually recommend planning for two weeks between the final cut of the website and the date of the new website going live. Factor that period into your timing for the launch date of your new site.

You also need to consider how long setting up the automated content migration will take. This will depend on the number of content types you wish to migrate. Depending on the quality of the source data and its suitability for migration, it may need up to a week's worth of developer time to perfect the migration of a single content type.

Work back from your planned launch date and set dates when you’ll need to make key decisions such as which content types to migrate etc. Think about how long you need to populate new fields or set up pages from stubs if you’re only migrating the structure of certain content types. Thinking this through well in advance will help the whole process run far more smoothly.

When you’re planning a content migration, ensure you follow these simple steps: First audit your content so you understand what’s working. Then decide on what you want to move, with view to minimising wasted effort by not migrating content that doesn’t deliver value. Finally, plan backward from your launch date now you know how many content types you’ll be migrating. That will give you a timeline to ensure you keep the project on track.

Content migrations don’t happen often – they are only needed when you’re doing a major overhaul of your website. It’s unlikely your internal teams will have the skills to set up the scripts needed to automatically migrate content. That’s where we come in. We’ve handled content migrations for a wide range of major organisations, including charities, museums, and think-tanks. We saved them massive amounts of time and resources by moving thousands of pages without the need for manual set up. If you’re considering a big overhaul of your website book an exploratory call to find out how we can help.