What does cooking have in common with data migration in telecom? Both can seem very complicated if you’ve never done them before, and both turn out much better in the hands of an experienced professional. We’re not chefs, but we know a crazy lot about data migration, so that’s what we’re going to tell you about today — specifically, some great migrations we’ve witnessed, some even bigger flops, and some dos and don’ts that make the difference between the two.
So, What Exactly Is Data Migration in Telecom?
Data migration is the process of transferring data from one system to another (e.g., from an old billing system from 200x running on a dying server to a brand-new one, running in a cloud). During this process, the data can be transformed, extracted, and changed in several ways. That makes it a necessary function of many business processes, ranging from switching the CRM solution to assigning the digital assets of a company you just purchased.
The biggest problem with data migration in telecom? The technique gap. Like with cooking, there are two types of approaches: some people think it’s insanely complex, and some think it’s a walk in the park. The first group is scared to boil an egg, and the second will grab a bunch of random ingredients and try to make filet mignon in a microwave. Both are the extremes.
Data migration in telecom will likely turn out a success if you hire professionals to do it. Some don’t, and that’s why so many migrations fail. In fact, studies have shown that 84% of all data migration projects go over time, over budget, or both.
Cooking Done the Right Way: Telekom Malaysia
In May 2019, Telekom Malaysia hired us to migrate their data into our system, which they had recently acquired. For those unfamiliar with the region: TM is one of Malaysia’s largest telcos, serving over 500,000 customers. They needed to migrate from their legacy solution to PortaSwitch while keeping all of their existing features intact. With half a million people involved, there was no room for mistakes.
The migration for Telekom Malaysia had three goals:
- Replace their existing (and pretty outdated) iTalk calling card platform.
- Keep the existing functionalities without ruining the user experience.
- Enable promotional campaigns after the migration to get some new customers.
Of course, there were a few obstacles. Telekom Malaysia had a custom IVR flow in both English and Malay, and that needed to keep working smoothly after the migration was done. Also, they needed some additional fields for their call detail records. Sounds like a challenge, right? In fact, not really.
The migration took a little over seven months, with 20 people involved in the project. With just five days of onsite training and five meetings, the PortaOne team was able to complete the migration safe and sound.
The Big Migration Gamble (for Lack of a Better Option)
So how did we do it? Before the migration even started, the project manager evaluated all of Telekom Malaysia’s business requirements. This included how they charged for products, how users activated and used their services, and so on. Basically, we needed to understand the old platform so we could properly set up the new one.
Then, we had two choices: we could migrate all the data in one big swoop (i.e., a “big bang” migration), or we could run both the new and old systems in parallel during the migration (i.e., a “trickle” migration). We went for the first route. We didn’t pick it because we love big bangs. Rather, the nature of TM’s business required us to undertake the complete migration in only two days.
But we didn’t just jump in. Our final step was to prepare a migration strategy – not just a recipe, a whole cookbook. Before we took a single step, we plotted out, in full detail, every action we would take, before, during, and after the migration. That crystal-clear pathway – a 25-page document, in the end – lowered all risks and guided our processes, from setting up the target system to processing the data and, finally, to importing it.
Testing Before Going Live
The next step after all that paperwork and scheduling was to undertake some user acceptance testing. PortaOne and Telekom Malaysia created a set of test cases. Them, TM deployed a target system according to the specs we wrote. Our tests showed that the target system was indeed ready for migration, so it was time to get cooking. The first task in the kitchen? Measuring how long it would take to migrate each segment.
In a sense, the second step was a kind of personal migration: our engineer Eleonora Zinchenko flew to Kuala Lumpur to assist on the final stages of the migration to a target system. She worked for two nights to prepare the system, then sent word that we were ready to move. We don’t just talk the talk. We walk the walk, too. Even if it means going across the world to get our hands dirty, so to speak, we accept all challenges head-on.
All’s Well That Ends Well
After we migrated a part of the data, the target system configuration needed some changes. Here’s where things got a little hectic in the kitchen: suddenly, the TM end users who had already migrated couldn’t access their services.
Luckily, our own team analyst, Dmytro Lavraniuk, was awake, traveling home with his family. Awake is the key word here since it was the dead of night for us, and most of PortaOne’s engineers were sound asleep, save for the duty engineers. And, fortunately, save for Dmytro.
Stepping into the Conversation: The Right Place and Time
It just so happens that Dmytro was checking his messages while waiting to board his plane. He noticed that the support engineers at the TM site were writing to each other, trying to solve the problem independently. Dmytro stepped in and offered to help, and they sent all the logs over for him to review. Within seconds, he spotted the cause of the problem and explained the fix. Crisis over.
After the second migration window was complete and we knew the data was safe, we took one last look to make sure everything was okay. The PortaOne engineers stayed onsite for a few days, just in case Telekom Malaysia needed more help. And voila – our full course meal was done.
What to Avoid When Migrating Your Data?
Not all migrations go that smoothly – we’ve seen some companies make some big mistakes. Here are just a few examples of what not to do (though to protect the names of everyone involved – and to protect ourselves from a lawsuit, of course – we’ve hidden any identifying details).
Being Short on Staff
First up, one smaller telco vendor won the tender to migrate data for a mobile carrier. They had one person from the company (the project manager) who worked onsite for the migration. They also had one support engineer (for troubleshooting) and one deployment engineer for patches. But most of the work was done by the project manager.
Poor Planning
Needless to say, things went very wrong, very fast. The project manager was swamped with the number of tasks and the ocean of communication going back and forth daily. During the migration, this lone project manager had to work around the clock, implementing at night and troubleshooting during the day. Add a large number of meetings to the mix, coupled with lots of documentation and testing, and you have a recipe for disaster.
Poor Timing
In the end, the telco chose a different company to finish the work. They completed the first part with a team of about half a dozen. Even with this big group of experts working on a small-scale project, the migration still took a year and a half.
Making Scope Changes “On the Fly”
In a different project-gone-wrong, a mobile communication platform had a data migration job that was scheduled to be done by an onsite team of about six to 10 people. Problems began cropping up when the company started asking the migration team for changes after the work had already started. (Think of that cookbook I described earlier, and how important it is to stick to the plan.) They threatened to not pay, and at the same time wanted the scope of work to be increased – not cool. The onsite tech team was a crew of experts, but they still estimated two to four years for the migration. In the end, the migration didn’t happen at all.
Vague Objectives
Here’s another case: a major Eastern European mobile phone provider had to migrate their postpaid user data. Before the migration started, all the integrations with external systems and partners had already been done. From the provider’s side, there was a team of 11 people: one project manager and 10 business analysts.
The provider and the company doing the migration spent more than a year just to clarify the current processes and document the state of affairs. They projected that at least four to five migration batches would be necessary. The actual migration took much longer than expected.
So, what can we learn from these stories?
The Big Lessons from Data Migration in Telecom
If you want your data migration process to flow smoothly, there are a few things to keep in mind. If you ignore these steps and the process goes wrong, you’ll have double the losses: in time, and in money.
1. A Good Chef Never Stops Trying. Don’t Let the Failures of Others Discourage You
If you have a large number of customers, like Telekom Malaysia does, you may be wondering if it’s even worth migrating your data. After all, it can seem like you’re risking downtime, or issues for your customers. But there are so many benefits to upgrading to a new system and ditching your outdated legacy one. You’ll see upsides ranging from saving additional time and improving your customer experience, all the way to using fewer internal resources. So be brave! Rest assured, your migration will go well if you entrust it to the right team.
2. Give Sufficient Time for “the Dough to Rise.” Always Have a “Plan B” for Management
Rome wasn’t built in a day, and you also can’t expect anyone to migrate data accumulated for years within one afternoon. Make a Gantt chart. It’s 2021 and there are a dozen tools available, besides MS Project — the decades-old weapon of choice for PMs worldwide. Then ask all parties involved to estimate every contingency. If possible, ask your migration partner to provide project reports on similar migrations with actual “time spent” calculations. Then, calculate an “optimal” timing and a “bad” one. Never plan for the “optimal.” Nobody ever got fired for performing migration ahead of the schedule.
3. Cut It!
When doing a data migration in telecom, you probably have a long list of all the things you want to happen. In reality, you’re going to have to accept some give-and-takes if you want the migration to occur on time and without a hassle. Consult with your migration partner to see where you’ll likely have to make scope adjustments and what you can actually expect as a result of those sacrifices.
A story “from the field”: our customer in the Caribbean used to apply late fees to subscribers when their payments came in later than expected. During the migration, the customer had to drop this feature to avoid the risk of having to add an extra month for implementation. The unexpected outcome: the actual subscriber base started increasing rapidly. Explanation: people were “afraid” of the late fees, despite an overall perception of this telco as being the best “value for money” in the region. After the late fees were gone, subscribers started switching over from the competition.
4. Communicate Openly with Your Kitchen Mates. Even if They Come from a Very Different Environment
All successful migration stories have one thing in common: consistent communication. The more you communicate, the more likely you will be to hit your original time frame and budget. Dmytro recalls: “At some point things were edgy with the Telekom Malaysia migration. So we called each other with the team and talked through the issues. It was a mixture of English, several regional dialects spoken in Malaysia, and Ukrainian. It was all one-on-one. Sometimes we just gestured to each other on camera or screen share. But it was way more productive than shooting each other a lengthy email or a memo.”
5. Always Do the Food Sampling and Iterate. Perform Test Migrations Before Moving Large Chunks of Data
We did a white paper on this. If you don’t have time to read it, see the visual below and remember to perform test runs on different customer batches before migrating the whole thing. Should there be data or metadata inconsistency, you’ll discover it without compromising an entire batch – meaning you’ll avoid downtime.
Finally, Here Comes the Secret Sauce!
The Internet is full of various “perfect data migration steps,” promising you heaven and a good night’s sleep. But over a decade of successful and affordable customer migrations, we’ve developed our own “steps” guide. As you might have guessed already: we’re giving no guarantees and make no promises of this “migration heaven.” However, this simple procedure is battle-tested, and it works.
BDEs (Not 💎) Are a PM’s Best Friend
Try to perform all the “scope innovations” with your business domain experts (BDEs) at the documentation stage. Make the discussion with your BDEs as open as possible. Explain the price of the “last minute” scope changes in the future (direct them to this blog post, if you like).
Still: Avoid Doing Their Job 🏗
Ask your BDE to picture their vision of “to state.” If there is none, stop and wait until such vision appears. Avoid “thinking it through” for your BDE, no matter how good your relationship is. If your BDE is too busy, ask this person to delegate the task to a subordinate.
🛠 MWaaS Is Your Ally
Learn to love MWaaS as much as we do. It takes a lot of pain off of your shoulders. Especially if you perform customer migrations regularly.
🥋 Keep Your Third-Party Apps in Check
Always check in with the process owners on behalf of any third-party apps if you have such integrations in your stack. If those are unavailable: try to locate and use the public API validation tools, etc. If such tools aren’t there either, then (1) now is the right time to rethink whether you need this third-party tool in your kitchen and to consider switching to a more responsible vendor, or (2) hire an expert on this app to assess your current readiness.
Plan for 🚨 Emergencies. Even If There Will Be None
Data migration in telecom is tricky because, usually, you don’t have the liberty of “switching off” either the legacy or the target system until the migration has proceeded sufficiently to ensure business continuity. Even if you are 99.99% sure everything will go smooth and quiet, notify your subscribers and all the subscriber-facing functions and get them ready for emergencies.
Wrapping Up
Data migration in telecom is not as big a deal as many companies think it is, or at least it doesn’t have to be. Yes, if you listen to the stories, you’ll know that some of these “recipes” haven’t turned out as planned. However, if you do it right, you’ll come out with a showstopper of a meal. All you have to do is make sure to cook by the book and work with a reliable partner from the start. Book our migration experts now to start. And remember: they don’t call PortaOne “the secret sauce for a good customer migration” for no reason. 😉
Mile Zivkovic co-contributed to this story.
