How to Move Legacy SDH Customers to IP Services

Moving users from legacy SDH services to new IP-delivered networks is a change, and as with any change, those subject to it will ask "what's in it for me?" Getting clear answers to this question is the first of several essential steps to undertaking a successful network migration.

For the network operator, the incentive to migrate customers is obvious: close down expensive legacy networks and consolidate services onto an IP platform.
For customers however, moving to IP is not all good news.

For a start, existing network topologies have embedded addressing and performance characteristics which must either be replicated or replaced.

The cost of change can range from trivial - a single router configuration - to substantial - replacement of CPE across many sites, reconfiguring networks and applications, installing security appropriate to IP and testing end-to-end performance.
In the light of all this work, a change driven by the sunset date on a network operator's SDH services can seem like an imposition if the customer's happy with his current setup.
As well as the operator and the customer, there's another party to consider: the sales channel.

Gaining the channel's engagement in communicating the need for and benefit of migration is essential to motivate customer action. This can be challenging enough with a direct sales force, which is unlikely to take much time over what can look like an engineering matter that generates no commission.
For an indirect sales channel of resellers and agents, there is the risk of embarrassment in front of the customer in explaining why the customer needs to change, and mixed incentives in understanding how the channel partner makes their money.

For some, it's the recurring margin on the network service, whilst for others it's consultancy or hardware sales.

Each of the participants in the change needs an incentive for change. It's usually the network operator who initiates the change because the business case needs legacy networks to be shut down completely. Customers receive the benefit of faster, more reliable and more flexible IP-based services.

And to oil the wheels, the operator will likely need to share some of their economic gains with the sales channel in the form of commissions and with the customer - a "better" network is interesting, but "better and cheaper" is compelling. Having recognised the need for incentives for customers and the channel to act, there are two other considerations for a successful migration programme - education and process.
That IP networks are superior to SDH ones may be self-evident to network engineers, but this may be less obvious to customers faced with certain hassle for uncertain benefits.
Education is therefore essential, first of the sales channel and then of the customer. Since customers gain much of their intelligence about what's happening at suppliers from sales personnel, front-line contact people must be well-informed and able to articulate the technical and commercial benefits of migrating to IP. This is a classic product training situation in which the salesperson needs to be able to develop the customer's need for change and address the objections and barriers to action as they arise.

The good news about a migration programme is that it addresses those customers with the oldest technology, and most likely those that have been long-neglected by the network operator. This transforms the customer conversation from engineering and administrative matters to needs and aspirations - exactly the topics needed to create a positive situation for an up-sell. For the operator it's a technical project management matter to close down a network.

However, each network supports a multitude of users who don't all respond when asked, and for whom the quality of CRM data can be variable. That's why process is important in managing the customer-side of the migration.

Each individual customer relationship needs to be managed as part of the project plan with the same thoroughness and attention to detail that changes to node sites, racks, routers and links are controlled.
At the top level, this means having an overview of how many customers are affected and what their "traffic light" status is, for example, "contacted and agreed to migrate", "contacted and in discussion" and "not contacted".
At the tactical level, there can be a lot of grubbing around to find the right contact at customers with whom there's been little contact for years.

Ultimately, the operator may need to resort to using recorded delivery to "The IT Manager" to advise formally of an impending change which will mean loss of service if no action is taken. In summary, migrating customers to Ethernet services is more than just a technical project or a matter of presenting improved features to gain customer co-operation. Overcoming inertia requires customer and channel education and incentives to act, whilst tight control of process is needed to ensure that no customer is missed or under a misapprehension on the impact of forced migrations.