Every year around 1.5 million wildebeest journey from the Serengeti to the Masai Mara in in search of food and water. It’s called the annual wildebeest migration and is one of nature’s largest spectacles.
When new clients come to us looking to migrate content to a new system they invariably ask, ‘Just how huge is this going to be?’
Well in our experience, the scale of a Content Migration project is somewhere between moving house and the African wildebeest migration. (And both can quickly go awry if things aren’t set on the right path early!)
A bit of apprehension about undertaking a project of this size is understandable. Migrating years, sometimes decades, worth of business documentation can be incredibly labour intensive – but it needn’t be a complete nightmare. However Content Migration is generally not something we would encourage you to tackle alone. An experienced provider will help you to define a project roadmap that will expose any issues nice and early, before managing a strategic migration process.
The first thing to note is, clients often come to us to talk ‘hypothetically’ about their options for a new CMS – which is a sure sign to us that they already need one. File shares are still a reality for many businesses and it’s alarming how bad a shape these can be in. We’re often left wondering how employees in some businesses ever got things done, given the bottomless pit of information they had to sift through every day.
So, if you think you might need a new system, you probably do. Remember your current environment is not going to magically improve – in fact it will continue to get worse – so we would encourage you to take a deep breath and tackle Content Migration head on.
Preparedness is an obvious place to start – but lack of planning can sink a project like this very quickly, so it is vital. Scope your project in clear detail, defining things like goals, budgets, resources, risks and success indictors, and then communicate them to everyone involved. This keeps everyone on the same page, working towards the same outcomes. (But do keep in mind that sound planning should be tempered with a flexible approach that allows for a few curve balls).
Performing a diligent assessment of everything in your current environment and defining a criteria for existing data is the next step. You don’t want to throw the baby out with the bathwater, as time and money went into creating this corporate knowledge. But the focus should be on identifying quality data, scoping content types and document metadata, and throwing any irrelevant/inaccurate/out-dated files onto the scrap heap.
Ask the tough questions, such as: How do we rank documents in terms of importance? Is a document that hasn’t been opened in two years still needed? What must be kept from a compliance or legislation perspective? Do we migrate all versions or only the most recent?
Build and map
A thorough document audit will pay dividends at this point, as the information gleaned during stocktake will aid the configurations of your new CMS. You want to migrate documents across with rich, accurate metadata to allow your users to filter search and easily locate the documents they need.
Things to keep in mind:
- If metadata is not assigned in the original environment, which is fairly likely, then who will take ownership of assigning metadata? (Try to avoid the common ‘we will do it once we’re in the new system’ trap).
- If migrating to SharePoint from a file share, consider the implications of updating document links in spreadsheets
- If mapping in the new environment is not the same as the legacy system, then a migration register is essential to track information pertaining to each file e.g. source, destination, type, owner, importance, date to be moved.
Manual v automated migration
Unless you have only a small migration, or you are migrating at the content database level, a migration tool is likely to give the best outcome. However, migration tools, while powerful, are not a silver bullet and do not guarantee success – some human consideration is still important. You are likely to encounter content that fails to migrate, so being prepared for this by running test samples and having a strategy for handling content with illegal characters will help minimise your down time. Migration tools really come into their own when you need:
- Version control or collapsing versions into a single file
- Maintaining metadata fidelity (do you need to keep the original modified or created date?)
- Scheduling batches to run in the middle of the night
- Pre-migration and post-migration reporting and verification
- Workflow migration.
Managing the change
It’s important to be on the front foot with major change like this by developing a user adoption strategy. Again, this comes back to answering some important questions during the planning stage, and engaging people throughout the journey to ensure they understand why the migration is taking place. Considerations such as whether you will adopt a staggered or single release, alerting staff to downtime in advance and responding to the inevitable ‘where have my files gone’ queries after roll out, should all be planned for.
We hope this article has highlighted how Content Migration headaches can be minimised. As outlined above, we definitely believe the services of an experienced provider will be worth the financial outlay, as they will work faster and with a higher rate of accuracy. Contact a member of the team today and we will talk you through it in greater detail.