Reusing the processes of billing migration

Summary

Reuse of common development and design approaches can be identified through high-level assessments of a billing migration's processes. When multiple legacy systems are consolidated to a common platform, the likelihood of, and return from, reuse will rise. As well, the assessment can determine the appropriate deployment order for new migration capabilities. The order in which capabilities are introduced can reduce the migration system's development peak, allowing new capabilities (and their problems) to be 'bedded down' gradually. Future migrations can then rely on stable processing when new functional or data complexities are introduced.

Actions

Characterise the existing migration process and evaluate whether parts of it can be reused
Evaluate whether the target billing vendor's application has existing templates for loading high-volume, external data
Evaluate the order in which migrations (customer data and functionality) are developed and deployed to avoid building an approach whose success depends on all steps executing correctly the first time (i.e. 'boiling the ocean')
For complex consolidations, describe the high-level migration plan for all migration phases to assist in the identification of reuse opportunities.

Migration and Consolidation

The relocation of core processing (and related data) between billing systems can be characterised as being either from 'one system to another' (migration), or 'many systems into one' (consolidation).

Migration configures or develops capabilities (and supporting data) in a new system to replace existing capabilities in an original system (i.e. new for old). Existing functions may operate slightly differently, due to the new system performing tasks in a different manner, but will deliver the same end result.

By using multiple migration streams, consolidation coalesces multiple billing systems towards one target platform. The target can be an existing billing system deemed strategic, or a new system introduced to replace capability gaps or operational failings in the legacy billing applications.

Billing systems involving transitory data (e.g. rating and invoicing engines) can be migrated from, and consolidated to, through the redirection of their interfaces. Systems that hold persistent customer information will require a more sophisticated approach since the information must be 'physically' shifted between applications rather than being redirected down a different path.

Minimising the number of migration steps performed reduces the cost and impact to the biller's business. The preferred approach consolidates directly to the long-term platform from multiple applications, rather than an interim consolidation to a legacy application that is then migrated to another (new) strategic application. The investigation, development and business impacts (costs) will be increased with the longer path to the strategic billing environment.

Re-using migration development

Opportunities for reusing migration development will vary based on the 'quantity' of migrations within a business' overall plans. For example:

Migrating one billing application to another: Limited opportunity for reuse since only the existing (and soon to be decommissioned) and new application are involved. Without additional migrations to leverage across, the one-time development required is too specific to one migration stream.
Migrating two applications into one: Whilst the legacy data extraction steps of the migration may have limited potential for reuse, the data loading process to the target billing platform is a strong candidate. Similar processing needs to be performed to move the customer and system data into the new billing platform. As well, the end-to-end planning process may also enjoy leverage across the two migration streams.
Consolidating many billing applications into one: Investment in the data loading process can be utilised across multiple migration streams. The planning process will benefit from leveraging common steps across multiple migration streams. With the increased number of data sources, the data extraction process from the legacy billing applications may benefit from using common methods and formats. This costs and benefits of investigating a generalised data extraction process can be leveraged across the multiple legacy applications.

Migration: design and planning

How will migration status be determined? - A point of truth (DBoR) for the customer's migration status will provide transaction flows (e.g. usage, provisioning, payments) with an accurate and deterministic approach to splitting appropriate subsets of their data between the existing and new billing applications. As well, external applications can use the (reliable) DBoR to direct access to billing information from both old and new applications. Inquiries against such a DBoR, especially when performed online, will require prompt processing to minimise impact on external, non-billing functions. Can the same status infrastructure be used across multiple migration streams?

Accurate financial postings (where applicable) must be performed to zero customers from the source billing application and accurately post their entries to the target billing application. Double entry postings must be performed in volume, possibly using reports to verify the accuracy of financial postings. This processing is a strong candidate for reuse across migration streams.

Transferred configurations - Existing configurations must be transferred to the new billing application. The new configurations will either be functionally equivalent (to the existing configurations), though possibly implemented differently, or 'consciously different'. Configurations 'consciously different' must have the differences documented, the impacts of the differences understood, and suitable communications with all impacted parties performed. Customers who will be impacted must understand any changes or their uncertainty will generate additional costs to the business when they query their invoices. The communication channel with stakeholders can be leveraged across migration streams.

How visible will migrations be to external stakeholders? - Will the migration process be hidden (i.e. due to no external changes) from all external parties, applications and customers? Will it be hidden, but its existence publicised? Must it be publicised due to impacts that cannot be concealed or worked around? How will the migration be publicised? How much of the future migration plan will be shared with stakeholders? Publicity may be difficult due to the FUD (fear, uncertainty, doubt) that may be result, and the external (political) resistance that may delay the migration's progression. Not all publicity and impact is bad - migrations can deploy new functions and capabilities desired by those impacted. Can difficult migration streams be represented positively within a broader, beneficial programme of billing consolidation?

Parallel Migration - When multiple migrations streams must be performed (i.e. consolidation), execution of each migration stream sequentially will extend the elapsed time before completion. Interleaving (parallel) migration streams can shorten a consolidation programme's elapsed time. This requires careful planning and coordinated preparation of each migration stream. Changes in one migration stream will need to be assessed for impact against the other, parallel streams.

Consider building capabilities in discrete stages - Rather than developing and deploying all requirements at once, capabilities can be gradually released, their results validated, and any improvements fed back into the migration process. Using such an approach, the development effort can be spread across a staggered delivery timetable, new capabilities can receive more attention when deployed (improving their acceptance process), and capabilities will be developed only as required by the migration plan.

Tags: Migration, Consolidation