Migration's functional triage (in four parts)

Summary

Businesses migrating from an existing system to its replacement must consider what to do with each function (and its related data). An existing system's functionality will be either:

migrated with little or no change,
require substantial modification before its data can fit within the new system, or
the existing function will be retired and not carried forward.

Once the migration preparation and processing has begun, any new functionality identified by the business will need to be considered as a separate stream of work. A decision process, on when and where new functionality is implemented, will be required until the migration process is complete.

Triage existing functionality into three groups

All systems, whether billing or not, will one day be replaced. When migrating an existing system's functions to its replacement(s), existing functionality can be divided into three groups:

No functional change - These functions will operate as they do today before and after their migration. These functions occur when migrating between different releases of a vendor's software package, or when industry functionality is standard between vendor packages. Custom-built systems can contain such functions when they use a standardised interface to interact with other businesses' systems.

Whilst format changes may be required in migrated data (e.g. addresses), a user trained in the old system will understand how the function works in the new system, and require less retraining.

Functional modifications and exceptions - These functions are implemented differently in the new system, but the basic business function is the same. For example, billing disputes may be functionally common to both existing and replacement billing systems. However, the existing system might resolve disputes (i.e. in the customer's favour) by giving cash credits not tied to specific charges, but the new system might tie credits to specific (billed) charges to avoid double-dipping.

Migrating this functionality group has two problems. The first problem is that related data may need to be transformed into a form that is meaningful to the new system. In the example above, a solution must be found for existing unassociated dispute credits to 'associated' them with specific charges.

The second problem is that the new system will assume that its data is uniform and was populated using the new system's software. Migrated data from other systems may not 'fit in' perfectly, generating processing exceptions that must be allowed for. For example, disputes resolved prior to a certain date may use unassociated credits, but 'all' disputes raised after the migration is complete will be tied to charges. During the migration period (assuming a phased migration), disputes may be tied to charges (if performed in the new system) or remain unassociated (if migrated across from the old system) depending on when they are raised.

Migration processing may also contain exceptions for processing still 'in-progress' when a customer is migrated to the new system. For example, a dispute raised on the old system, but resolved (after migration) on the new system may appear differently to those raised and resolved (completely) in either system.

Whilst the migration process may defer a customer's selection for migration for some 'in-progress' functions (e.g. in-flight billing), other functions may be minor or so common that the migration process will be restricted too severely. For example, unpaid bills are likely to be too common and so an interim migration function that routes payments to the correct system will allow more customers to be eligible for migration.

Functions not migrated - Some functions may be 'left behind' and not migrated to the new system. These can be functions that were carried across from the old system's predecessor, products no longer offered, or products about to be retired or replaced.

The new system's complexity and maintenance costs will benefit from the retirement of such functionality, and the migration process will be simpler. The process of agreeing which functions are no longer needed may be difficult. A process of documenting what is performed / required in both new and old systems will identify candidate functions, but these must still be reviewed.

Some functions common to both old and new systems may still be candidates for non-migration if their ongoing benefits are outweighed by the costs of their migration. A migration may the opportunity to 'clean house' and initiate a forced 'end of life' process.

The removal of functions (interfaces, products, data) used by minor products can be tricky when these products are used by 'difficult to persuade' customers. Your largest customer may be the last user of an old product, or your own company' CEO and leadership team may use a favourite product that generates little revenue and is used by few other customers.

Unmigrated functions may generate larger archive processing because the related customer data will not be migrated and available on the new system. The costs of the archiving process can be tempered by retaining the information in its current format without the need to transform or map it into the new system's data model.

Good business rule, functional and technical documentation is required for this archived information since once the old system is decommissioned, the knowledge of what the data means and how it operates will quickly degrade. This is important if customer, legal or accounting needs require access to, and interpretation of, the old data at some future date. The future period of access may be measured in years if financial data is involved.

New functionality - the fourth functional group of migration

A new system may be implemented for a range of good reasons (e.g. retirement of an old hardware platform, capacity constraints, software obsolescence), but a core reason is new functionality. The new system may contain functionality that cannot be built in, or cheaply retrofitted to, the business' existing system. This is an acceptable condition when only migrated customers use the new functions.

The difficulty comes when new functionality must be applied to the customers of both the existing and new systems during migration impacting the entire migration process. The old system must be changed to include the new function; the migration process will probably need to migrate data from the new function to the new system; the new system will have its own implementation of the function; the function's migrated data may differ slightly generating additional processing exceptions.

Ideally new functions are applied only to the new system (since the existing system is about to be retired). However external organisations (suppliers, governments, customers) may not care about such niceties. For example, a government's taxation department may require the implementation of new tax rules affecting both migrated and unmigrated customers. In such circumstances the best approach is to design and implement the change in the new system with the long term in mind (ongoing maintenance and processing costs, system complexity), the migration process with ease / speed of processing in mind, and a cheap implementation in the old system (given its impending retirement).

Tags: System Migration, Interface