The concept of differential migration

The usual process goes like this : for any given project, a 1st run of data migration leads to part of the data getting lost or corrupt in the process. For the sake of this demonstration, let’s say that 30% of the data ends up not being migrated properly or contains errors. In that case, IT departments will usually amend the data migration rules in order to fix the errors then erase what was done previously and start the migration all over again – even if initially 70% of the data was migrated properly. The process starts over and over again – each run followed by a correction then a reboot – until 100% of the data is integrated as requested.

Myddleware enables what we call « differential migration » : instead of starting the migration process over and over again, with the risk of creating new errors at each run, we focus on the 30% of data that wasn’t integrated properly and leave the other 70% alone. We then we work our way up, correcting the rules as we go and reducing the share of corrupt data until 100% of the data is integrated as requested. In a nutshell, it is a rather gradual multiple-step process.

Simultaneously with migration, Myddleware can program the synchronisation of both old and new systems. That way, clients can keep working with the old system without having to re-enter data in the new one. Clients can check the correct functioning of the new system and train their employees on it, while still working on the old one. Once the new system is up an running, they can then easily switch to the new one without stress.

We undertook this process for one of our clients, an online training course vendor. They wanted to swith to another CRM and connect it with Moodle, the training course application, in order to manage their courses directly from the CRM. So the project involved two main operations : the first operation entailed migrating data from one CRM to another while the second operation concerned the connection of the newly acquired CRM with Moodle. The client openly expressed how amazed he was by the smoothness of the process : we had managed to undertake a differential migration as well as the synchronisation of both old and new systems. This enabled the client to keep working on the old system while the new one was being set up. The client users switched from one to the other in two phases. During the 1st phase, two users worked on the new system for a whole day, while the others kept working on the old one, their data continously synced with the new platform thanks to Myddleware. When those two users confirmed that the system was working correctly, the other users followed and switched to the new system as well.

Once the data migration was completed, we then proceeded to set up transfer rules that enabled the client to manage his courses directly from his CRM without having to re-enter data in Moodle.

We definitely recommend this process if you are currently using Myddleware since we are adamant that these practises greatly enhance and facilitate data migration operations.

If you want to know more about other functionalities, please go to this page.

Comment below and share your advice on how to lead a successful data migration process !