How migration outages change over time

Summary

During a business system's migration, early outages are longer and impact the legacy (source) application the hardest (the target system suffering less impact). Later migration stages will impact the target system more as most customers now reside there (along with the new systems' increased business benefits).

As migration processing is improved, the factors influencing the data migrated 'per outage' can change as increased numbers of customers become located on the target system, and the technical migration processing itself is optimised. Over time the limiting factors on the rate of migration can change from technical performance to revolve more around the outages' business-impact and any required staff training.

In the beginning, the target system is empty...

Business system transitions can be performed in one event (big-bang) or as a managed series of migration events that each move a specific sub-set of the business system's customer base (and related processing) from a legacy source system to its replacement target system.

For smaller, isolated systems with minimal customer data and little cross-system interaction, the transition of data and related processing can be managed with little complexity.

Migrations involving high-volume, integrated systems that are 'always on' will necessarily involve outages or processing restrictions as and when migrations are performed. Complex system transitions are often performed as a series of partial data migrations that gradually move customer data and related processing from the legacy system to the target system whilst maintaining continuity of business processing with the least amount of impact or restriction.

If the system transition includes a move to 'always-on', real-time processing, an outage to the target system creates a more visible system 'absence' than previously on the source system. Early in the migration process this is less visible since few customers are on the target system, but outages' visibility will increase with each migration event.

Early migration events can take longer to perform due to factors such as:

Initial migration outages will be longer as defects are worked out: No matter how studious the testing, "Production is a 'condition-rich' environment" (Stephen Jones).
Based on older infrastructure, the legacy system may be slower: The infrastructure of the target system has the advantage of contemporary design and investment.
Back-ups on the legacy system must back up all the customer data: Older (dormant) customer data is often not moved to the target system, but must be included in the legacy system's pre-migration backups.
Initial performance tuning removes only the obvious bottlenecks: Multiple partial migrations allow the migration suite's software to be optimised as real-world processing reveals where improvements are required.
Outages on the source system are better understood than the target system: Operational processes on the source system have stabilised over time, but must be created, optimised and stabilised on the newer target system.

If a migration is backed-out, the recovery time for the target system will be smaller at this stage due to its smaller number of customers and related data, and to the correspondingly shorter execution times of its business processing . The source system will take longer due to the volume of data that must be reset/reloaded, and the longer execution times of any business processing that must be performed.

In the middle, customer data is about equally distributed...

By this time, the data migration software will have had opportunity to be both improved and tuned to improve its performance. Any early issues regarding the quality of migrated data will have been fixed.

The customer and transaction mix may change as the business transitions beyond the first (or pilot) customer segments and/or product offerings. This transition may impact the performance characteristics of the migration process. For example, migrating a smaller number of larger corporate customers with complex products may transition to a very high number of simpler mass market customers and their less complex products (vice versa).

For larger systems, the retraining of staff can become a limiting factor as the improved migration performance allows more customers to be moved at once. Since staff are often associated with specific customer segments, this increased migration performance can generate the need to retrain increasing numbers of existing staff in how the target application operates. This increased training pace can exceed the training team's ability to instruct, and the operational staff's ability to absent from their day-to-day workload. During a system migration, additional staff can be required to address the absence of staff performing training and the short-term decrease in productivity that may occur as staff operate the less familiar target system.

A series of data migrations occurring over an extended period will be impacted by new functionality on the source and/or target applications. Businesses may mandate a period of 'no further development' on the source application (since it is being replaced by the target application and will soon be decommissioned), but external forces (customers, regulators, governments) can override the enforcement of this approach.

Towards the end, the target system contains almost all the data...

The target application now holds the majority of customers and their migrated data, and migration outages now impact the target system more, and this is where the major business impact will be felt. Since the target system commonly delivers increased business benefit over the legacy system, any outage will cause an correspondingly higher business impact.

During migration events performed at this time, the backup and back-out restore times will be longer on the target system since its databases now include a substantial quantity of data.

The last customers to be migrated were selected (or deselected) into that position for a reason including:

Billing complexity: The customer's products may be more complex and involve additional data relationships and complex rating/pricing products. Since these products have been deferred and are different to the previously migrated products, their migration processing can be different (new) to that performed to date.
Data errors: The customer data of the last customers may have been 'deselected' from previous migration events due its data flaws. The last migration may be forced to transition these customers regardless allowing the source system to be decommissioned, with any flaws fixed after the fact on the target system.
End-of-life products: Products that were expected to be finished / terminated / finalised and no longer billing must be migrated unexpectedly. Configuration for these products may not have received the attention of the other migrated products, or the target system may not adequately support their existing billing approach, necessitating non-standard migration processing (e.g. establishment of manual processes, alternative rating/pricing platforms).

Due to the reasons listed above, additional time and care can be required to ensure that the last few migrations are successful (especially the designated 'last' migration), to enable the source (legacy) system to be decommissioned.

Tags: Migration, outage, Conversion, Data