Do you want to know more about what it takes to do a successful migration? Contact me and I’m sure we can help with your next swap-out.
At ECT, a substantial amount of our business is migration. Whether it’s a platform for ring back tones, a network-based contact center or a legacy IN, when a system reaches end-of-life it needs to be replaced. All the client data and features have to be migrated to the new platform and taking care of this is our everyday business. Sometimes, not all features on the old system are migrated and we very often add new features.
A successful migration requires a great deal of planning and a clear strategy. You have to determine when to do the installation, when to do the testing and when to migrate the data. In many cases, the carrier’s employees also need to be trained. At the same time, callers shouldn’t notice the migration.
For The Actual Migration, There Are Two Approaches
For the actual migration, there are two approaches. The first is the big bang approach in which you build up a complete parallel system and on the date scheduled for the migration, you flick the switch and shift to the new system. The most important thing here is a fallback scenario which leaves you the option to return to the old system if something doesn’t work the way it should.
The second approach is the more popular one: you migrate everything bit by bit, i.e. customer by customer, service number by service number. The advantage is clear: there are fewer risks and you can test each customer and each data set that you have migrated separately. However, this kind of migration takes much longer.
But how is it done? Prior to moving the data from the old system to ours, we make it “ready for action”. We create admin users and their respective user profiles. That way we make sure that, for example, a certain prompt on the old system will be the same prompt on the ECT system even though the IDs on both systems are different.
For the actual migration, when moving the parameters from one system to the other, we start by extracting the parameters from the old system. We then convert the features used according to predefined rules and mapping files. Finally, we transfer the parameters to the new system. All this is tested until it works to our customer’s satisfaction. After the migration, comes an observation phase where we search for errors, monitor the performance and look for anything out of the ordinary.
The Tricky Part
The tricky part is always to crack and interpret the old database structure. Fields like “name” or “billing address” are easy to migrate but many others fields are not quite so consistent and cannot be migrated one to one. Another challenge that we face on a regular basis is the extraction and conversion of routing plans. These are extremely difficult to read and vary from service number to service number. Migrating these requires a great deal of time and know-how. We have this know-how here at ECT and in the past, have performed successful migrations from e.g. Siemens INs or Alcatel systems.
When we do a migration, the emphasis is on flawless execution. We want a seamless and flexible transition to our platform to make sure that everything works, no features are missing and involve customers in the migration process whenever necessary.
