Data migration or how to roll out a release without losing users

The timelapse of technology development trends points us at an interesting tendency: any piece of software requires refactoring, roughly once in 5 years. Regardless of how perfect your system and database architectures might be, some feature-based or scaling requirements, prove to be incompatible with the initial design, making refactoring a paramount effort.

In some cases, you might need a partial effort, f ocused on small functions or entire modules, other times, a total refactoring is a must. The latter is true, especially when making ill-fated decisions when you’re designing your system architecture or choosing your stack. We’re not going to touch the decision-making process here (there’s an in-depth piece about that here).

Instead, we’re going to explore issues occurring at the end of the refactoring process, namely the migration aspects of data, from the old database to the new one. To avoid some obvious mistakes, I’ve gathered some key points that you must consider.

Quite often, legacy apps tend to have data validation issues. Usually, Refactoring brings improvements to solve these issues, so you need to ensure that migrated data addresses your new structures (i.e. does not need to be changed before inserting it into the new database). Here are some common margins of incompatibility:

Leave a Comment