Content migration is a notoriously underestimated part of an implementation project. Whether you are upgrading or moving to another platform, or redesigning your website, content migration is a huge undertaking that demands attention.
Enterprise websites usually contain thousands of pages, contributed to or written by numerous authors spread across the organization. Content is shared in several languages and likely includes a wide variety of local variants and localisation requirements. Not to mention the fact that ongoing content operations on your legacy systems won't allow you to stop while content is being migrated.
So how do you make an enterprise-level content migration as simple as possible? In this article we’ll review five key steps of a migration project that you need to consider.
Step #1: Define the scope and take inventory
The very first step is to run an inventory on your current content. This process is not something to be shrugged off, it’ll likely be more complex and take a lot longer than you’re expecting, so resource accordingly. You should also take this opportunity to conduct a full review of your content using the redundant, outdated, trivial or ‘ROT’ method. This will allow you to drop any content that isn’t bringing any value to your website, prior to migration, saving you time and effort later on.
Redundant - Content that is duplicated. Over the course of years this is common. Now is the opportunity to identify duplicate content and remove it.
Outdated - Content that is no longer relevant. It might be content that is no longer valid due to changes in your product portfolio or changes to technology etc. This type of content should be removed or archived.
Trivial - Content that is barely used or visited. Whatever the reason was that this content was created, if it doesn’t attract any traffic and has no SEO value, it’s time to remove it.
When considering what to migrate, traffic and SEO are variables that should be taken into consideration from the start. There are tools which allow you to scan and report on both matters which can give you valuable info on what to focus on for your migration project. Analytics are very useful in mapping the complete scope of your content using crawlers and traffic numbers can generate reports on where best to focus your output. SEO is a layer on top which allows you to review the quality of your content.
Language and localisation efforts require local champions to identify and approve content decisions. They will help with tone and style and do the analysis of local content on all levels described above, as well as identifying what needs to be adapted or removed. Analytics and search teams can collaborate to review traffic value and develop SEO strategies in response.
Step #2: Create your plan
The plan is where everything comes together, from copywriting to development. Enterprise-level content migration involves a lot of moving parts which need to be coordinated to manage expectations and workload. For example, a new component or technology might block copywriters from working on new content. Your plan should be prepared for such obstacles and have solutions ready to keep things moving. Though development and content teams tend to have their own workspace and project teams, in these kinds of projects we’ll need to manage work across and between disciplines. Working in an agile way and possibly even having daily stand ups with the complete team are always advantageous. Project managers of each team should be coordinating at a minimum.
The use of efficiency-enhancing tools cannot be underestimated either. Issue tracking systems like JIRA work well for development teams but might not be ideal for others. The key is to have each team work with the tools they prefer on the lowest operational level while maintaining a high-level overview of all workstreams (make these overviews visual as possible!). Finally, automate as much as you can because manually keeping track of everything is a daunting task.
Step #3. Manage support / buy-in from your team and management
Stakeholders have opinions on things. Your content migration project will likely be one of them. Consider all the feedback you could receive on tone of voice, branding and localisation alone and you’ll soon realise it’s key that you have a program expectation management. Consider working with local champions in their respective business units or countries to manage the conversation around your migration project, educate and explain the goals and do the necessary work on the ground to win support. Dedicate time to gaining buy-in from team and stakeholder alike, as this is critical to the project’s success.
Step #4. Run a test or pilot upload into a non-production environment
Running a pilot on automated content migration is crucial. No matter how much pre-planning you do, chances are you’ll run into something unexpected. Running a pilot or test load gives you the opportunity to cover for this and resolve potential issues before committing the complete migration of all scoped content.
Typically, you start with just a sample selection of content and a small team and run a pilot migration. Ideally this process is completed early on and can even be repeated several times. The earlier you start piloting the more accurate your activity and resource demand planning will be. It also allows for possible technical solutions or improvements to be built in time for a quickly approaching launch date.
Step #5. Migrate your content
Once you've tested your migration process and you're fairly happy with the results, the next step will be to start the actual migration. It’s important at this stage to focus on three core activities:
- The continuation of creating or adapting content on the source (legacy) environment
- Cleaning up migrated content. Content that has been migrated but requires additional work to make it acceptable to whatever standard has been set for the new enterprise website. This might involve SEO optimisation or rebranding of content.
- Creation of future content that doesn’t need to be published before the go live of the new environment.
Content freeze
Eventually it will be time to start the so-called delta migration period. During this period there is either a content freeze (meaning no new content can be created on the legacy/source system) or there is double posting of the content (meaning content is created both on the source and target system). There is no right or wrong between content freeze or double posting and this decision should be made on a case-by-case basis.
Go-live
After go-live the source platform is closed for content creation and all new content or changes are to be performed on the ‘target’ platform. The go-live moment therefore is the real cut-off moment for content creation if you opted for a double posting strategy. If a source freeze was agreed upon then that was the cut-off point for the source platform.
Bonus topic! - Maintenance and operations
Congratulations, you’ve migrated and launched your new enterprise website. Though the migration project is finished, work prepared during this project will now continue. That is if you prepared this phase! Very often we see projects run towards the end without really thinking about the phase that comes afterwards. In parallel, teams should think about how content creation will continue, what issues were encountered during the migration project and were moved into the backlog for later review, have the users all been trained properly for the new system, is the documentation up to date and readily available? These are just some of the any items to consider when ensuring smooth operations following a content migration.
Hopefully you now have an idea of what a migration project looks like and have a clearer notion of what’s involved. If you need any support and are facing a migration project, we are ready to help! Contact us!
