Whether or not you are familiar with the process of moving large quantities of data, data migrations are something that probably fills you with a great deal of anticipation. There are good data migrations and there are some very bad ones, and a bad migration may have long lasting effects - you’ll be cleaning data up years down the line if you’re unlucky. So, how do we avoid that?
One of the most common reasons data migrations can fail is because of pressure to get them wrapped up as quickly as possible. You have a shiny new tool or are retiring a legacy system and there’s inevitably a desire to get the new system up and running so that the old one can be switched off. It’s entirely understandable - you want a quick return on investment and to mitigate the financial risk of running two systems in tandem.
It’s well known that rushing often leads to shortcuts and skipping steps however. While data migrations are rather straightforward (if sometimes time consuming) projects, skipping steps can very easily derail them. According to classic project management theory, if you want something more quickly for the same cost, then you will end up with a worse quality result. Not only will you be putting your team under extra pressure, but your end result will also likely be inferior.
Now we’re no longer rushing - consider what it is you’re actually attempting to do with your migration. This means thinking about your intended data structure and data mapping. The first step is to entirely forget about what data you’re actually tracking now and consider what data would be useful for you to track and justify each choice. There are a few obvious constants (name, email, etc.) but maybe there are some things you’d like to track which you don’t right now. This will help you set up your new database better too. Think about how you could segment your marketing differently or which reports might let you create more informative monthly reports.
Never just copy your old fields to your new database without questioning them. A new platform is a chance for a new start. And if you’re shutting down opportunities for change, then you’re not taking full advantage. While there’s certainly a lot to dig into in the planning stage and you will want to carefully consider your data strategy, you should be focused on keeping your data streamlined and easy to keep completed. You may well notice gaps in your current data against your new strategy and you’ll need to account for them.
There’s no getting around it - cleaning up old data and bringing it to your new standards is a task you’ll have to consider. Often, there’s an assumption that moving historic data to a new tool is going to fix all of your organisation’s problems. This can be a very misguided notion for numerous reasons, the largest of which is an assumption that your current data is up to a good standard. Unless you’re especially prudent at data cleansing, it’s likely a mixed bag and so it’s important to consider and prepare to clean the data either before or after your main migration exercise.
This can be an incredibly time consuming task, so it’s important to define the scope. Perhaps only certain data needs to be brought fully up to date, and some older data you are ok with having certain fields missing? This often comes down to a question of resources and priorities. It’s also a chance for you to evaluate old data and think critically about whether there are any identifiable patterns of simply unusable or irrelevant data, which can substantially reduce clutter in your database if not brought over to the new system.
.png)
When you’re transferring the data are you planning to do it in a big bang approach? Doing everything at once is definitely tempting. With everything resolved you can stop worrying about moving things over and can consider the job finished. While this is a nice thought, it’s first worth considering where all your data is. If it’s spread across multiple systems it’s definitely worth considering a phased approach.
As part of this, we would recommend that you implement a data freeze (another good reason for phasing your project). This is a date after which staff can no longer make edits to the source system for the migration. It can be as close to the migration as a day before, but it is important that edits are not being made to connected areas of a system that have already been migrated. The data freeze generally comes before the main migration after...
This point can also not be stressed enough. When dealing with software and business critical information, you should not be betting everything on one big transfer and crossing your fingers. Instead, you should be doing preparatory tests to make sure the migration performs as expected and only consider planning a date for the final migration exercise when you are absolutely sure that it can be successfully completed.
This should not add a significant amount of time to your project and it is vital to make sure that your data is being accurately transferred. It’s quite possible for data to load in the wrong fields or to not load in at all. This is not a problem when testing, but if you migrate your data and don’t properly notice until time has passed then rectifying the issues becomes more of a headache. Once you have tested and are confident your data is migrating correctly, you are all set for the transfer.
It can’t be stressed enough that data migrations live or die on the preparation put into them. Do not rush them. With all this being said, if you do put in the planning and think through possible risks they can, and often do, go quite smoothly. Your new system will be ready for your organisation to face new challenges in no time.
If you’re moving platforms or planning a data migration and want more advice on how to ensure your move is as smooth as possible, get in touch. We’d be happy to help!
.png)
If you have a project you’d like to share with us, or even just a quick question, we’d love to hear from you. Get in touch below!
Contact us
