Unless you’re starting a project to create a brand new website, you’re going to have to plan for some sort of content migration during your work. You may already have a Content Management system that you want to replace, or you may have something simpler like static HTML to build upon, but either way getting the right content into your new system is a challenge that needs careful planning. You need to find the right balance between automation of these tasks and manual changes by your content editors in order to get the most out of your budget. ClerksWell bring a wealth of experience from previous migration projects, in order to help you get the best results.
While every migration project is different, they do share similarities that we can use to focus the effort on the right aspects:
What systems are you migrating between?
The easiest scenario here is that you’re migrating from an old structure to a new structure, but they’re both going to run on the same content management platform. In this case, the job is just about re-organising the old data into the right new structure. Modern content management systems like Sitecore and Umbraco provide powerful APIs to allow reading and writing content, as well as user-friendly editorial user interfaces – both of which help to make this task simpler.
The more complex situation here is that you’re moving from an old CMS (or perhaps no CMS at all) into your new content management platform. The first consideration here is how can you get the data out of the old system. You may have access to an API that can be used to read the data if your source system supports it or you might only have access to an editing UI. In some cases it may be necessary to process raw data like HTML files or database tables. As mentioned above, your target system will almost certainly have an API to write data to – but your migration will have to work out how to parse and map the data from the old structures to the new ones. Depending on how well structured the source data is, this can be a significant part of the work.
What scale of migration effort is going to be required?
The scale of the migration work to be done is very important in deciding what approach to take to your project. The most obvious thing to consider when thinking about scale is how much content you have to move. As the volume of content increases, the value of automation tends to increase for a migration project. With smaller sites it can be quicker and cheaper to have a person move the content across by hand, but for large sites automation tools and scripts can make significant savings for you.
The second thing that affects scale is how well structured your content is. Field-based content management systems (like Umbraco and Sitecore) have relatively structured data, which is fairly easy for automated migrations to read. But sometimes content is composed more of blocks of rich text than easy-to-read fields. In this case it can be necessary to break the rich text up into the fields your target system needs. This is harder work, and can be more prone to errors than reading structured data.
Is migration really necessary?
You should also consider whether a migration is worthwhile at all. In situations where the Information Architecture and content of your site is changing drastically, you’re probably going to end up re-writing a lot of content in your target system. In that case, you should give serious thought to not migrating the old content at all, but just starting fresh content on your new system. When you end up changing most of it, the effort of migration can end up largely wasted. And that’s effort you could have spent on other aspects of your new website.
How does your content have to change?
When you’re dealing with well structured information, changing the data from one Information Architecture to another is usually not too complicated. Whether you opt for editors doing it by hand or by automation, the process is largely the same – the pages and fields in the old content management system need to be mapped to the right places in the new system. Once you understand the mappings you need, automation tends to work well here because content that is structured into fields and items is easy to map. If you have hundreds of product pages, each with the same set of structured metadata then scripting can easily perform the same set of tasks on each one.
If the information is less structured then this task is harder. Projects where the content largely exists as blocks of rich text, which need particular bits parsed out into fields for the new system are usually the most challenging. It’s pretty much guaranteed that there will be some pages that don’t quite match the pattern you’re expecting – which can break an automated migration. People can do this migration task effectively and flexibly, though at markedly slower speeds than computers. If automation is applied its success will depend strongly on how well the real-life data matches the rules the scripts are given for parsing it. Projects involving this sort of automation will benefit from ensuring people validate the output of these migration tasks, to check for errors.
It may also be necessary to generate new content as part of the migration. A good example here is if content structures are changing, it is good practice to create redirection rules to ensure requests to the old pages will arrive at the new pages. This helps to maintain search engine rankings, as well as to prevent frustration to people arriving at the site from bookmarks or links on 3rd party websites. If your content is being moved by automatic means, it’s easy to generate redirections at the same time.
What is the best technical approach to migrating your content?
When it comes to individual projects, the answers to the issues raised above will help work out the approach that will work best. While some projects will have an obvious “there is only one sensible approach” answer, it is common for a mix of solutions to be relevant. Generally, these will come from the following list:
Migrating content manually
Having people copy-and-paste or re-type content isn’t fast, but it copes well with unstructured content, and content where lots of change is required to make the old information work with the new site. It is also a practical solution for old CMS’ products which do not have APIs that can export content in a usable format. The people involved only need to be able to use the content management UIs of your source and target CMS’ – they do not need technical skills. However, this approach is generally not efficient when you have a large volume of content, since the time involved is likely to be too great.
Automation using scripting languages and tools
Where both the source and target CMS’ support a sensible API, using simple programs to move data can be effective. Scripts built in languages like Microsoft’s PowerShell are relatively fast to create, and can perform simple content moves much faster than people. However the costs and timescales are strongly dependent on the quality of the data. Costs may increase noticeably if the scripts need to make modifications to the data, or if the data is not well structured. Building and running these scripts requires technical skills, so it is not a suitable job for content authors.
Specialist content migration tools
Since migrations are important in many CMS projects, there are a variety of vendors who have built tools to try and speed the processes. Some are made by 3rd parties who specialise in migration, and some are built by CMS vendors themselves. These tools tend to support a fixed set of source and target systems (though many are extensible with development work) and they can also include processing engines that can be given instructions to modify the content in transit. License fees may be payable for these tools, and they often charge based on the scale of content to move. They work best when there are large volumes of content with at least some structure, and where timescales are tight. While these usually require a technical person to configure them, it is sometimes possible for the migration to be run by editorial staff.
Whenever content is being migrated, it is important to include this in the quality control phase of the project. Before launching a new system you need to ensure you spot and fix issues like spelling or typing mistakes, differences in formatting or failures to map content correctly from one system to another. Hence all three of the approaches above can be combined with some final manual editing to make the last few tweaks to the old content and correct any issues discovered.
Whatever your migration challenges, ClerksWell have the skills and experience necessary to get your content moved quickly and efficiently. Get in touch with us to find out how we can help you make your migration a success.