Shhh, I’m Hunting Content...
If you don’t know what you have, it will be difficult to plan your move.Performing a content inventory is essential to discovering exactly what content exists and at what volume. During the audit, attempt to categorize your content by complexity (simple, moderate, or complex) or type (template or usage).You will likely want to use both.
Complexity implies difficulty in development and migration, and type implies the total number of page templates in your new CMS. This will assist in your migration approach later on when reasoning about automated versus manual migration. Without performing this content inventory, it will be very difficult to estimate the time and effort needed for your migration.
Until the migration is complete, it’s likely you will be using both the old and the new system.I’m not sure this is avoidable.Your business needs to continue to operate as usual and cannot stop making necessary content or data changes to your old site during migration. This makes tracking updates and changes critical during migration and begs the question: After completing the content inventory, how do I track the changes?
If possible, use an automated approach that will account for changes. This may be a 100% custom process or a custom extension to your existing CMS.If custom automation is too expensive in terms of development time and money, it may be best to simply use a spreadsheet to track changes which would include updates, new pages, and deletions. For your content migration to go smoothly, you need quality data, otherwise there is no way to guarantee all the content transferred successfully during the migration.
Lastly, make note of all search engine optimized (SEO) critical pages. If there will be a change in URL structure from the old site to the new site, a little extra work is needed before “go live”.Make note of these SEO critical pages on your spreadsheet, and augment the pages with their post migration URL’s. This information will make your Web Engineer’s job of protecting SEO for these pages much easier. Forget this step, and your SEO will suffer while your Web Engineer’s job becomes more difficult.No one wants to upset Web Engineers.
Does This UX Look Good on Me?
Think: lift and shift. Now is not the time to be making site design changes, there are enough other items in flux. Ask yourself: Do we really need the added pressure of designing a new look and feel right now?Think about the last time you went through this design process. It is not an easy task by itself and one you probably don’t want to go through while you are changing CMS’s, migrating your content, validating migrated content, performing user acceptance and quality assurance testing (UAT and QA), and mitigating a full host of other technology issues.
Simply using the “old” look and feel allows your development team to charge forward building the new templates and components without waiting for the design team, comps, or approvals.Where are your comps?Your old site is the comp. The developers already know what it’s supposed to look like, let them do what they do best.
It is recommended to hold your redesign for after migration. Everyone will be much more comfortable with your new CMS including, Authors, Managers, Developers, Web Engineers, etc.Besides, you can start planning and working on redesign concurrent with the migration and wait for implementation until after the migration is complete.
Start Them Up!
One of the problems to be solved during a migration to a new CMS is when to start the actual moving of the content. One successful strategy is to interweave development, testing, QA, UAT, and content migration.
Developers start building a page template that will allow someone to build a content page.Using the content inventory method mentioned earlier, pick a page that has the largest page count from the old site. The normal development process is followed to promote development work through testing, QA, and UAT processes.
In some cases, the content migration process will start as part of UAT. Depending upon your enterprise guidelines, this may or may not be possible.For tight timelines, this can be effective with the right resources performing UAT.Later, I will mention some resources to be considered for this UAT/content migration process.
The UAT/content migration process will likely result in feedback or changes to the developers for fixing issues.But this should not stop work on the next page template.Pick the next page with the next largest page count on the old site.Developers will likely finish this next page much sooner than the migrators finish migrating page template #1.Lather, rinse and repeat.
Looking at your content inventory again, you should be able to quickly determine if the simple and moderate complexity pages could be “auto-migrated” using a custom or commercial solution. Some firms offer custom automation services which could dramatically reduce your migration costs and time. There are a couple well known commercial solutions which are fairly expensive. Evaluate the estimated time it will take your team to perform either a manual migration or custom developed solution. This analysis should suggest a clear approach that is right for your business.
This may seem redundant to mention -- custom development may take a bit longer, but it is infinitely repeatable. Additionally it can be shared with other groups in your organization moving to the same CMS. Custom development may be a way to “capture” your effort and amortize its cost. A manual migration is essentially “lost” effort without a way to recoup the cost and time of manually migrating content.
When dealing with manual migration, it may be hard to find resources. Don’t overlook your marketing team or the group that will be using your new CMS day to day!This is an invaluable training opportunity for these teams, with real live content!CMS training classes are okay, but not training with your own content and your own page templates would be a missed opportunity. You will be attacking two problems at once: training and content migration.
Finally, if you are going to need to know what the old URL is for a page in the new CMS, then taking the time to record the old URL in your new CMS will be worth the time and cost. If you don’t record it, someone could waste hours trying to figure this out. The only scenario where this has no value is when the old URL structure is the same or similar to the new.
Which Way Did He Go George?
Production always seems to be the last environment to be built. Use QA for your migration. When the migration is complete, the Production environment will likely have been completed. Shut QA down, take a backup, and restore it onto Production. Again, depending upon your CMS, there may be some additional tweaks necessary.
Depending upon your CMS, this approach may or may not be possible. If it is, this will provide breathing room for many of the players involved including, Developers, Authors, Web Engineers, System Engineers, etc.
The cut over to Production does not have to wait until migration is complete. Pick a time convenient for your team to make the move. This approach allows you the leisure of deciding when it makes sense for you, rather than bending to the demands of when these systems will be made available.
Lost In Spaces
In this article, there was no mention of digital assets at all.This issue is complex and should be considered when performing a content migration, however digital asset migration is easily a topic unto itself.For this reason, it’s not addressed within this article, but if requested can be included in our series of articles on CMS Migration.
Editor's Note: Looking for more on content migration? Cheryl McKinnon offers up 6 Things You Need to Know When Moving Enterprise Content to the Cloud
Image courtesy of Maksim Kabakou (Shutterstock)