You’ve upgraded your network, investing heavily in 4G, 5G, virtualization, the telco cloud and more. Now you discover that many of your service platforms have remained back in the stone age, causing you high OPEX for maintenance and inhibiting innovation. Basic network services are still required in the most modern networks; even SMS is still alive and a necessity in 5G. Moreover, many communications service providers (CSPs) determine that their sophisticated business services, such as UCC, VPBX and call center applications, are the stickiest and most profitable in their portfolios, so they must retain these valuable subscribers and modernize the services to gain market share.
So, what do you do with these legacy services that are often running on bare metal with old, dedicated hardware?
You migrate and innovate.
At ECT, we’ve been doing this for years at CSPs, large and small. I have come to the conclusion that there are migrations and then there are Migrations (with a capital M). A migration can be as simple as the press of a button, after which all services, features, users, etc., are carefully moved from one place to another. But a migration can also be a two-year-long headache that takes you nowhere and leaves you having to start over again from square one.
So, what makes the difference between the good, the bad and the ugly? And how can you avoid the recurring migration nightmare? Many customers have asked me similar questions, so I’ve decided to share my experience here.
Get the Architecture Right
Virtually all major CSPs are moving towards a modern, cloud-native network and, regardless of where you are along the road, it’s important to remember where you’re headed. When migrating legacy services, you want to avoid replacing a bare-metal service platform with yet another bare-metal solution or a virtualized one that’s installed on dedicated hardware. Such migrations only inch you forward at most, and you’ll end up replacing them in the very foreseeable future. Of course, if you replace legacy service platforms with Cloud-Native Network Functions (CNF), you’re set to cross the finish line. But your network might not yet be ready for containerization. In this case, I recommend implementing services as Virtual Network Functions with a VNF Manager, such as Cloudify or Nokia’s CloudBand Application Manager (CBAM). But if you do this, be sure to obligate your vendor to later replace these VNFs with CNFs without forcing you to purchase additional licenses or software. That way, you’re future-proof and won’t end up incurring the external costs of migration twice.
Use Low Code for All New Service Applications
As far as the service applications are concerned, it’s clear that you’ll be looking to provide your existing service subscribers with the key features they’re using on the legacy solution; after all, you don’t want to lose even a small percentage of your current customer base. In addition, you’ll want to ensure optimal, multi-experience user interfaces and be able to add new features, do A/B testing to optimize user satisfaction and individualize services for both market segments and major customers.
None of the above will be possible if you move to yet another hand-coded monolithic application, where at most the original vendor understands. You also won’t be helped by service delivery platforms where services are programmed in outdated and cumbersome Java variants like J2EE.
The only way I know to make this possible is to implement the new services using a low-code application platform. This is the state of the art in the IT world. Don’t settle for anything less.
Look for Experience in Your Vendor
If you are searching for a migration partner, the first thing you need to look for is experience. That may seem obvious, but I have seen situations where little to no attention was given to the fact that a chosen vendor had never done a migration. I remember one case in which a CSP wanted to migrate a televoting system running on bare metal, so it launched a tender process. The winning vendor was unfamiliar with both migrations and televoting. Even after over two years of trying, it couldn't complete the project, slowing down the CSP’s plans and incurring penalties that forced this company into bankruptcy. After winning a second tender, we came in and migrated this highly complex service platform with all the customers and features to a virtualized solution.
Not All Migrations Are the Same
In another example, a CSP had a 20-year-old solution and there was only one employee who really knew how it worked. There was no documentation available. There was no data dictionary. The vendor hired to perform the migration was never able to understand how that old system worked or translate the service into a working application and ultimately abandoned the project.
As this example shows, migrations can differ widely, and your vendor should be prepared to face a range of challenges. It should have processes and in-house experts capable of finding solutions to problems that come up along the way. An expert team can, for instance, analyze database structures and understand the different elements in tables, translating them into the database of the new application. This makes it possible to create improved data structures that support more features. Teams should also be able to write migration scripts to automatically port as much user data as possible from the old system to the new solution — and at the same time, have the ability to migrate manually as required.
Big Bang or Step by Step?
On another front, a vendor should be able to provide you with options regarding how you want your migration to happen. Some years ago, a CSP we worked with decided on a step-by-step approach, allowing each of its customers to choose when their migration to the new solution should happen. For that, we implemented a migration process that was activated with a button. When a customer was ready, the CSP pressed that button, and everything was done automatically.
We have also had customers that go to the opposite end of the spectrum: a big bang migration, in which every customer is migrated to a new solution at once, all in a single day. Obviously, in these situations, you need to be careful not to lose historical data and features. At the same time, you need to be sure that your new solution will work immediately to provide the features from the old app that customers need. The new app should be compatible with all packages and features. It sounds simple enough, but sometimes "simple" requires years and years of experience and a highly skilled team.
Fixed-Price Contracts
Finally, the last detail to consider is the price. There are vendors that offer their services for surprisingly low prices. But once the agreement is signed and the migration is in process, the price will grow unexpectedly because of "unforeseeable conditions," delays or "unspecified details," notwithstanding the previously agreed budget. Thus, CSPs should look for vendors that offer competitive prices that are guaranteed to cover the project end-to-end. Lastly, if the vendor is making an offer based on reoccurring usage licenses, then the costs for setting up the initial platform, the migration as well as the subsequent maintenance and further enhancement should be minimal.
If you are interested in learning more about migration, our website goes deeper into this topic. You can also get in touch with me via our website or connect through my LinkedIn profile.
Metin Sezer is Deputy CEO of European Computer Telecoms AG (ECT), a provider of Telecoms Low Code and agile co-development that is dedicated to better business outcomes for CSPs and their customers. To learn more about ECT, visit ect-telecoms.com.