Common Data Migration Issues
by: Brandon Amick
There are many reasons your organization might be undertaking a data migration: a change in the platform your data is stored on, a major change in software, or even a change in versions of certain software or hardware might require a data migration. But moving your data is never as easy as it seems. There are a few things you should keep in mind before starting the data migration process.
- Make sure all your stakeholders are on board with making a change. Spend time to determine if it is really the right decision for your company. On many occasions, we have migrated a company from one software to another or one database to another – only to go back and reverse all the migration we had previously done because they hadn’t considered the functionality of the new software or database in their existing environment. Mistakes can happen, and sometimes other circumstances may cause these data reversals, such as an acquisition or a merger, but such errors can be costly.
- Making a detailed plan is essential very early on. A thorough study of the new software, the skill level of the users, and potentially a gap analysis between the platforms can help you plan better. It can assist in addressing the upcoming changes in software or platform, create a plan for the management of the upcoming changes, and provide a process to discover any potential pitfalls. Plan, plan again, and then plan some more.
- Data almost never behaves the same on two different platforms. No matter how alike two pieces of software are, they will never behave exactly the same. As much as I wish that Oracle and SQL Server would just behave the same way and make my life easier, they simply do not. Anytime you migrate your data, it will almost inevitably have to be transformed. At a database level, you will have syntaxes that are no longer valid and must be rebuilt. On a software level, you may have to translate data because “Middle” worked just fine for your labels before, but now they need to say “Center” to have the correct alignment.
- After planning the process of the migration, create a separate plan for when and how the migration will take place. Some of our best data migrations have occurred with customers who know their data and have a plan for how it will be migrated. They have practice migration runs scheduled to predict how long the databases will be down, what personnel need to be on call, and how the actual migration will be run. Some have a “situation room” with staff on hand 24 hours a day so that someone is always available in case of an emergency. This kind of planning can have the best results, but unfortunately is not always an option, depending on budget. The process and time required to migrate data is almost always more involved than most companies realize.
- Most importantly, you must have a verification process in place. This is where the practice runs can be extremely useful. It allows you to find issues in the data migration before the real migration occurs. If you have verified multiple times that the data looks good after following the procedures of your migration process to the letter, then you can go into the real migration feeling confident. Your post-migration analysis will show that all your data will look just as it is supposed to.
These are just a few of the more common issues that companies tend to overlook – or are not willing to invest as many resources into – when migrating their data. It really cannot be stressed enough that the more planning, analysis, and verification you put into your migration, the better the results will be in the long run – potentially saving your company money by investing up front rather than repairing costly mistakes later.