Migration. No carrier really wants to do it, and yet, it’s a critical part of the evolution of their networks. Getting it wrong can lead to painful consequences but, eventually, for one reason or another, every carrier has to face it.

At many carriers, the core network has been modernized continuously while the platforms for value-added services (VAS) are ancient by comparison. Take a look at the platforms you’re currently using for staples, like voicemail, SMSC, IVR, NP, carrier routing, VPN, NTS, RBT, WAP, MMS, etc. Then consider your more sophisticated business services, like network call center, VPBX, UCC, nuisance call prevention, televoting, mass calling, etc. How many different platforms do you have? How old are they and what are they costing you to maintain? Are these platforms at the same technological level as your core network?

At ECT, we are experts on the migration of VAS and know it better than most. In this blog post, we are going to share some of the motivation for migration and discuss what are the crucial things you need to get right. Here are our most important migration tips.

How many different platforms do you have? How old are they and what are they costing you to maintain?

Migration: Here’s why you should do it

When talking about platforms for VAS, ‘legacy’ generally reads as ‘expensive’. An expensive plethora of different proprietary platforms. Expensive maintenance contracts with multiple vendors. Expensive operating costs for many different bare-metal solutions.

One big reason that carriers consider migration is also the most frustrating: The planned obsolescence of most vendor solutions. Vendors declare end-of-life and/or end-of-service, telling you it’s time to wave goodbye to your current platform. If you’re lucky, the very same vendor offers to migrate your service to their new platform. It may be exorbitantly priced, but the vendor leaves you no alternative: no more maintenance for your current platform simply means that you can no longer use it to provide services to your customers. The English word typically used to describe this practice in other contexts is ‘extortion’. Our first tip is to make sure that you opt for a vendor that will commit to a long lifecycle, letting you decide when it is time to upgrade your services. (Such vendors really do exist: In over 20 years of business, ECT has never declared end-of-service for any of its solutions.)

Most carriers have long since identified the benefits of virtualization and NFV and have already virtualized their core networks. Now they need to do the same with their VAS. After all, using the same generic hardware in your datacenter or carrier cloud, means you don’t have to buy dedicated hardware for each VAS solution, reducing your CAPEX. And as you no longer have separate hardware maintenance contracts with all the various vendors of your VAS solutions, you also significantly reduce your OPEX.

Our first tip is to make sure that you opt for a vendor that will commit to a long lifecycle, letting you decide when it is time to upgrade your services.

If you’re considering the virtualization of legacy bare-metal platforms, you should however remember if you have a mess of different legacy bare-metal platforms which you then virtualize one-to-one, you’re likely to end up with a virtualized mess. So here’s our second tip: The most cost-effective migration is one which migrates legacy platforms from all different vendors onto a virtualized solution from a single vendor. (Again we bear witness to the fact that there are such vendors: ECT is often migrating and consolidating all the VAS of leading carriers onto one unified and virtualized solution.)

When you choose a vendor to migrate your VAS to a virtualized solution, don’t forget that virtualization alone is not enough. To really get the full advantages of NFVI architecture, e.g. the ability to scale-in and scale-out the resources used by each service, you’re going to have to integrate the solution with your VNF manager. That brings us to our third tip: Choose a vendor who has the capability of integrating with multiple VNF managers, e.g. from Nokia, Ericsson, Huawei, etc. (At ECT, we’re actually providing certification of our ability to integrate with VNF managers, such as Nokia’s CloudBand Application Manager.)

But maybe we should also point out that VAS migration is not just something you’re forced to do in order to reduce costs. Think about how migration can better serve the future growth and development of your business. Perhaps your customers are looking for more innovative services, making migration first and foremost about customer retention. But, don’t forget, it is also about the customers you have yet to acquire.  This is one of the best reasons to consider migration.

The most cost-effective migration is one which migrates legacy platforms from all different vendors onto a virtualized solution from a single vendor.

Defining the migration strategy

After you decide that you need to migrate your VAS, then comes the next step: Defining the migration strategy. ECT assists with this usually after a discussion about your ambitions for the migration. The strategy you choose will depend as much on your ambitions as on other things, like your budget, the timescale of your project, the physical composition of your network and services. These are the two main migration strategies:

The Gradual Approach

This way, one customer or batch of service numbers at a time is migrated from the old system to the new one. It’s seen as the safer option because it prevents problems impacting the whole of your customer base at once. The main kicker with the gradual approach is that it is more expensive; it requires you to keep two systems running in unison because the new system is live from the moment the first customers are migrated. This is not the case with the Big Bang Approach.

The Big Bang Approach

When the data is ready and the migration test-runs have been made, the ‘red button’ is pressed and the migration is performed in one fell swoop. That’s the Big Bang Approach. There is more at stake for you here because preparation for an overnight transfer is quite an undertaking. When done properly, a lot of time and money is saved; when it isn’t, well… it’s best not to think about that. But, should all else fail, carriers opting for the Big Bang Approach can always retreat to the old system because, unlike with the gradual approach, no data is live until it is transferred to the new system.  You can also make use of a two to four week post-migration safety period where the old system remains online and the success of the migration is verified. Once success is confirmed, it is turned off for good.

Choose a vendor who has the capability of integrating with multiple VNF managers.

Analyzing the data model

So… you’ve chosen your strategy, what now? It depends on whether or not you are sticking with your vendor or twisting. The answer to this question bears on how your data will be migrated from one system to another. If the vendor remains the same, the migration should be relatively simple because that vendor already controls the data and has the complete data dictionary, meaning they should have everything they need for a smooth transition. With the latter, things can get tricky.

“Understanding how the data of the old system is comprised is the hardest part of our job,” says Michel Fontaine, Director of ECT’s Solution Development Department. “If we cannot do this, then we cannot map the old and new systems and decide the best way to migrate the data,” Gavin Fitzsimmons, Senior Project Manager at ECT, adds. “When a carrier moves from one vendor oftentimes the data model of the old system is undocumented, or the old vendor is reluctant to assist us, meaning that some reverse engineering may be required.”

“Once the data is mapped, we can transfer it in two different ways: by shifting the service numbers manually from one system to another, or, by building a software migration tool and automating the process,” explains Michel. ECT’s migration service is collaborative, meaning, that you get a service that is safe and secure as well as one that you can guide. It is also why we advise you to be aware of where the complexity of your data fits into any given migration.

In practice, a mix of manual transfer and automation might also be used. Complex data requires an even more complex data tool which it may make no sense to develop but then, on the other hand, your business clients may be so huge, that moving the data manually is simply not possible. A vendor can only understand what to do by working closely with you. Let’s say you provide VAS to an institution such as a defense or public health provider. When migrating for such clients, manual transfer of the data might be better, as any errors disrupting the service could become front-page political news and, due to that client’s size, end up costing you money. That client may demand compensation from the carrier, or, in the worst scenario, look for another provider. There’s also reputational damage to consider.

This is all part of the reason that migration can prove to be so stressful. At ECT, we discuss with you ahead of time which of your customers requires special care. That way, we can strike the perfect balance between manual transfer and automation.

We hope these tips have helped. You may only go through the migration of your VAS once or twice; ECT goes through it constantly. That is why we can say we are experts who are passionate about this important job. If you are interested in learning more about how we can help you realize some of the many benefits of migration, don’t hesitate to get in touch.

ECT

Author ECT

ECT is Europe’s leading communications software company. With our virtualized INtellECT® Low-Code Application Platform, innovative service applications and our Joint Agile Product Development Program, major communications service providers worldwide realize their products with minimal costs and the shortest possible time-to-market.

More posts by ECT

Leave a Reply