One-to-one: Data migration without disaster

AT: Tell me about Celona Technologies.

CA: Celona Technologies was set up ten years ago as a consultancy and started to focus on data migration four years ago. We recognised that our carrier customers faced common problems concerning data migration, although every operator typically had an in-house team that wrote its own scripts for the process. The company's founder and CTO Tony Sceales realised it would be far more efficient if they used the tools and processes we'd developed already instead of keep reinventing the wheel.

It is our aim to remove risk and change the cost profile of data migration. These are big issues for carriers, as our research, published last summer showed. It found:

  • 93% of telecoms IT managers said they are fearful of undertaking complex application level migrations
  • 59% said they have been discouraged to the extent they have decided not to go ahead with some migrations
  • 60% of respondents said the main cause of failed migrations is that data complexity and cleanliness are poorly understood
  • 89% said data complexity is getting worse
  • 47% said their data migrations are not on schedule
  • 36% said they worry that they will not be able to get some or all of their data across
  • 33% said they fear they will never finish the project.

These findings are backed up by independent research too, such as that recently published by the Bloor Group which found 80% of data migrations fail and only 16% achieve what they were meant to.

Our belief is data migration should be driven by business needs, not technology. IT should underpin business processes, whether it's billing, CRM, provisioning or anything else. Applications should be about business rules and customers, and their value to the business - not about data and bits of data. We enable the migration of that business logic from legacy systems to new target architectures, new OSS/BSS.

AT: Why is data migration so difficult‾

CA: Telcos are very complex and their transformation even more so. We have Deutsche Telekom, BT, Telecom Italia, France Telecom and Telstra all looking to transform their businesses. Some have between 2,000 and 3,000 systems to consolidate to reduce costs. At the IT level, managing far fewer systems is cheaper, but the value to the business is that they can launch new services faster and with less cost because fewer elements are involved.

AT: How does that help with revenue leakage‾

CA: If we migrate perhaps 20 systems into a single one, it is much simpler to identify and prevent revenue leakage.

AT: How do you fit in with existing practices‾

CA: There are five ways of approaching application data migration.

The first is big bang in which data is extracted from repositories, cleaned up and reloaded into a new system and this typically takes place at the end of deployment of a new billing system.

The second is to have a new and old system running in parallel.

 

The third is to migrate data based around an event whereby we map an old system using our control management framework. This allows the separate migration of data from business processes: once the old system has been mapped, the business can decide when to move away from the old processes, rather than do it automatically at the end of a project. The event that prompts such a move might be a wholesale customer moving to a new tariff or wanting to offer a range of new tariffs. We'd just the move the necessary data to the new system and leave the rest.

The fourth is an incremental migration, whereby it is completed in manageable stages, not triggered by events.

The fifth is a bulk load, shifting a lot at a time in a planned way.

The point is we can do all of these, as appropriate to the needs of our customers' business.

AT: What's your modus operandi‾

CA: The old technology used for application data migration is to write scripts, to put programmes in place to map data from the old systems onto new target architectures. There are a variety of ways of doing this.

We've captured the  process and the method, building a management control centre so that we can analyse, map and migrate the data in any of the five ways outlined above.

The real point is that we avoid custom writing every time, there is no point every customer reinventing the wheel, which is what happens at the moment. Instead 80% of what our customers need is off-the-shelf and only the remaining 20% has to be customised to accommodate idiosyncratic business practices.

AT: Who are your customers‾ Do you work with standards‾

CA: We are working closely with the TeleManagement Forum and with BT. We are also involved in 27 customer trials across Europe, Australia and New Zealand. We expect to be making more announcements in the coming months.