Content migration is usually the part of a web development project that is most underestimated. It's also one that typically causes launch delays. It is best to try to assess how long your content will take you to migrate earlier in your process and put in place a game plan for how you will do it. Doing some quick calculations may make you realize you've underestimated the effort it will take and force you to re-evaluate your plan for when you will start it and how you will execute it.
First, it's important to understand why content migration is almost always grossly underestimated. Most companies don't realize how much content is actually on their site. Then, they assume that migration is as simple as a straight copy and paste. If you've been through a content migration project before, you know it's much more than that. It requires content fitting into your new templates, adding back in images, relinking pages, tagging content with metadata, re-adding components, and more. For these reasons, it can be easy for a migration project to quickly run over the allotted budget and timeline.
So, how can you avoid this content migration problem and better estimate your timeline?
Start with a content inventory
Content inventories are tedious, there's no doubt about that. But creating a content inventory before starting your content migration can save you time in the end. When you sit down and actually look through all the content you have, you'll see which content you want to keep, which content you'll toss, and which content you'll need to rewrite when you migrate it over. Make this process easier on yourself by not adding things into your inventory that you know will be keepers or that will be discarded based on the same rule (i.e. keep all press releases published within the last four years and delete all releases older than four years).
A content inventory should be a living document that is updated by several members of your team so the burden doesn't fall on just one person. Keeping a detailed content inventory will not only help with your content migration, but with other website content / strategy changes in the future.
Estimating time per page
Now that you have your content inventory, you'll need to go through and mark your pages as 'Easy', 'Medium' or 'Hard'. Note that if you have thousands of pages of content, it's ok to guess how many are Easy / Medium / Hard. It all depends on how much time you want to invest in estimating to make your guesses more accurate.
- Easy: These are pages with a single content type, no related modules, and / or five or less content fields or images that need to be fixed. An example of an easy page would be something like a press release page.
- Medium: These pages are primarily based on a single content type, but with additional related content fields, 10 or less content fields overall, lots of links that need to be fixed, lots of images that need to be fixed, basic formatting fixes, and basic meta-tagging is required. An example of a medium page would be a product page that lists product suggestions and several images.
- Hard: These pages are based on four or more content types, have lists of content that need to be generated via metadata from other pages, have many embedded links and images to be fixed, and formatting that needs to be redone (probably some HTML skills required). This would be something like a homepage on your site.
Now that all the content from your content inventory has been categorized into Easy / Medium / Hard, you can start calculating your manual migration timeline. Typical manual migration looks something like this:
Easy: 15 minutes per page
Medium: 25 minutes per page
Hard: 45 minutes per page
Keep in mind that these estimates are not black and white and there are several things you'll need to consider when estimating:
- If you have a content-heavy site with lots of pages like 'articles', you can estimate a higher percentage of your timeline to the 'easy' side of the spectrum; however, if your site is more dynamic and there are more relationships between the content on your pages (you expect to have more reuse of the content during the migration), you should estimate a higher percentage of your migration to the 'hard' side (45+ min per page) of the spectrum.
- Migrations are (almost) always underestimated. This is because there is a lot of variability around how much your content will be changed from your old site to your new site - from how much will be reused (think componentization), how much new metadata tagging is required, mapping content to fit into your new templates, etc. Plan to add some extra time to your migration timeline for these scenarios – and avoid most of them with a comprehensive content inventory before you start.
- You almost always end up needing HTML skills to do content migration. Sites have embedded formatting that will most certainly get messed up when copying and pasting into your new CMS, so it's important to make sure someone on your migration team has these skills.
Cutting down your timeline
Some who go through this exercise may find that their migration will likely take more time and resources than they have available. If you find yourself in this situation and your site is made up of content that is well formatted and consistent, you may want to consider automating part of your migration with a tool like Siteport™. This can dramatically cut down on your migration timeline and budget.
Practice Makes Perfect
I've been through content migration projects multiple times, and like any skill, practice makes perfect. You'll get better at estimating your content migration projects the more you have under your belt, but this guideline should help give you a pretty good starting point for your first migration project.