logo_header
  • Topics
  • Research & Analysis
  • Features & Opinion
  • Webinars & Podcasts
  • Videos
  • Event videos

What can CSPs learn from sub-brands about transformation?

Sub-brand projects are often conceived to kickstart digital transformation, and migrate products and customers onto the new systems used by the sub-brand.

31 Oct 2019
What can CSPs learn from sub-brands about transformation?

What can CSPs learn from sub-brands about transformation?

Barry Graham is the author of a new TM Forum report on how communications service providers (CSPs) are using sub-brands not only to target new customers, but also to kickstart digital and cultural transformation. Download the report and read on to find out what the biggest challenges are.

If only people were as simple as software.
I have had the honor of being involved in many TM Forum workshops and leadership summits discussing the transformation of IT systems, whether it be the transformation of legacy fixed networks to virtualized ones, or the transformation of business platforms to support new, innovative business models and new forms of customer engagement. The single biggest question that comes up during these workshops is how to achieve migration.

Migration is a challenge


In TM Forum’s new report Taking on the greenfield operators with digital sub-brands, we look at how CSPs are setting up digital sub-brands often to attract younger customers. A good example of this is TM Forum Excellence Award winner Vidéotron which created the Fizz sub-brand based on a completely new, cloud-based business platform rather than the legacy operational and business support system (OSS/BSS) stack that supports the rest of their business.

Often, one of the long-term goals of similar sub-brand projects is to kickstart digital transformation, and potentially begin to migrate products and customers onto the new systems used by the sub-brand. There are three basic approaches:

  • Traditional system migration – in this case all the data about products and customers is migrated to the new system, but one of the huge problems is the shear complexity of the systems that have evolved over time. Testing every possible scenario becomes almost impossible, and we have heard about cases where operators have been faced with migrating hundreds of legacy products, some with only dozens of customers. The cost of designing and testing the migration far outweighs the value of those customers to the business.

  • The “strangler pattern” – this is an approach that BT have described in several case studies, most recently in simplifying their inventory system. The idea is typically to consolidate and replace a key component of a system, and inventory is a good example. All interfaces to legacy components and the new component are routed through the same application program interfaces (APIs), and migration is achieved by routing processing to the new component in logical blocks. The other parts of the system see no change; they are still interacting with the same APIs. Migration continues until no processing is being done by the legacy components, which can then be retired.

  • New parallel system – this is the approach Videotron is taking, developing a new parallel system and moving customers across one by one. No attempt is made to migrate all the legacy products. New products and services will be created only on the new system, and when customers sign up for them, they will be moved across and any existing products will be matched to near equivalent products on the new system.


Get training


TM Forum’s Open Digital Architecture (ODA), part of the Open Digital Framework, can help CSPs with IT migration, no matter which path they choose. We are offering an ODA training course in November, during which we will look at the three migration strategies in detail, along with other pressing challenges.

Most CSPs will be successful with one or a combination of the approaches to IT migration. People, however, seem to present a more complex challenge.

Many of the sub brands in the report were started by teams set up in deliberate isolation, working in innovative, Agile ways. Should they be left isolated to innovate, or should they be merged back into the core organization and with hope that they can influence the established teams?
No clear answers have emerged yet, other than it is hard and requires more careful planning and management than even the most complex IT project.