In today’s technology landscape the need to modernise business systems to ensure best in class service is paramount to our clients to maintain their competitive advantage. Enhanced customer experience, increased functionality, evolving business capabilities and products are all in the forefront of the decision to move platforms. In consumer financial services for example, a robust, agile, multi-channel 24/7 customer banking platform can provide the service level difference between our clients and others in the market place.
Transitioning from one platform to another is often the key technology milestone in the long-term strategy for a business. Once platform selection has been completed, the major challenge is how to transition the customer and business data into the selected architecture. It is essential that the planning and execution of a major platform move is done with a thorough understanding of the risks involved.
There are many publicly reported cases of migration problems which result in customers being dramatically affected. These problems can often cause loss of service and data corruption, financial penalties and customer compensation. Therefore, understanding the fundamental steps in the migration process is critical to a successful migration.
Planning for Success
Here at Sagacity we have extensive experience in large scale migrations across a range of platforms, industries and locations. We don’t leave anything to chance and ensure every step of the process is meticulously planned and executed as small mistakes can have catastrophically large consequences.
Step 1: Understanding the Data
A migration starts with a detailed review of the source data and architecture. This includes working with the business experts to understand what the stored data represents and how to identify the key data components. By profiling the data, a set of measures can be identified to verify post migration. This ensures the data remains complete and accurate e.g. each customer has the same products, pricing, account balances and billing history in the source system as they had on the legacy platform.
Step 2: Understanding the Legacy Platform
Understanding the existing platform architecture will allow the migration architect to appraise all data elements with the system for migration. The key activity here is to catalogue the individual data structures and fully appreciate the logical linkage across the data landscape, enabling the data in the target platform to function cohesively.
Most platforms will have data feeds from other internal systems and external suppliers of data. As part of this process the architect will also analyse the data feeds into the platform and how they are captured in the data architecture. This ensures the extended data architecture around our migrating platform is fully managed.
Step 3: Understanding the Target Architecture
The target platform will undoubtedly have a different data structure to the existing platform. The architect will fully appraise the new data environment to understand the nuances that are required for the system to operate. At this stage it will start to become clear which attributes in the legacy system are aligned to the target architecture and where there are gaps that must be managed.
Again, the data feeds into the new data landscape will have to be considered to ensure the new system is provided with all the feeds it needs to operate. Changes to existing feeds to dovetail into the new system will also be identified at this point.
Step 4: Design the Transformation Process
Design how to transform our existing business data into the shape and form that the target architecture requires.
Each data element in the source system should be evaluated to understand if it is a key data item and is required in the target data model.
The transformation of each data element needs to be planned meticulously to ensure there are no integrity issues as a result of the migration e.g. a customer forename in the source system may allow 30 characters, with the target system allowing for 25 characters resulting in the forename needing to be trimmed to fit into the target forename field.
Step 5: Plugging the Gaps
With the source system data mapped to the target model, the next stage is to identify any data gaps and evaluate if those data elements need to be manufactured to allow the new system to operate.
During this phase data quality issues may be uncovered in the source system legacy platform. This presents an opportunity to correct and enhance the data before carrying the identified issues into the target system. Remember the adage ‘rubbish in rubbish out’. This is an opportune moment to correct core customer data e.g. names, addresses, contact details and product mappings etc.
Step 6: Building the Extract, Transform and Load Routines
With an understanding of the legacy and target platforms and the detailed data landscape, the technical developers can now develop the extract, transform and load (ETL) migration suit of programs.
Step 7: Test Planning & Preparation
Key to the success of every technical migration is a detailed test plan to validate each step of the ETL process and identify data anomalies. Multiple test cycles are planned to test the ETL, roll back capabilities and data migrations.
Rigorous test conditions and success criteria for each data extract are developed to ensure the correct volume and format of data is being extracted.
Validating the accuracy of the data fields being transformed to fit the target system will ensure that each data element is being processed correctly. Loading into the target system confirms that the transformed data is in the expected format with each field undergoing further interrogation to ensure that it has loaded as expected and holds a valid value.
Step 8: Test Execution
Paramount to any system migration is the execution of multiple full end-to-end test cycles, and the in depth interrogation of test results to identify issues with the data mapping, ETL and roll back routines. Successful testing will prove the migration process and identify any data anomalies in the transformed data.
The volume and depth of testing executed is based on the risk appetite of the client but should always be sufficient to prove the main execution and data paths in the migration and target system operation.
Step 9: Business Validation
A key stage to ensure that the target system is business ready is business user testing. During this phase a series of test scenarios are executed on the target system. This encompasses expected user paths through the target system from data entry to administration and reporting tasks. Only once user testing, along with the technical system testing, has been signed off can the migration be readied for rollout.
Step 10: Migration Planning (Minute by Minute)
The delivery of the migration will often mean downtime for the system to end users which puts pressure on the migration team to ensure that the migration progresses as quickly as possible. The timing of the test migrations will give confidence to the expected execution at the time of the live rollout.
Live roll out is always meticulously planned with a minute by minute plan to ensure that all steps are performed in the correct sequence and in a timely manner.
Step 11:Go / No Go
A critical point in any migration project is when the decision is made to proceed with a migration. Are we happy with the new architecture? Has the system software and migration suite been tested and signed off? Are there any last minute business concerns or unexpected events which may delay the move to the target system?
It is at this point that the senior stakeholders agree that the migration can proceed.
Step 12: The Migration
The key business and technical resources perform the migration in accordance with the agreed Minute by Minute Plan which includes a series of checkpoints to ensure that progress is being made as expected.
At the various checkpoints there is a proven process for continuing with or stopping the migration and if necessary rolling back. As several dry runs have already been performed the risk of rolling back is low however; checkpoints are planned in to ensure that all eventualities can be catered for.
The final step of the process is the litmus test to check, “Does the system work as expected?”.
Once the migration has been completed and the new system has been brought online, the migration is at the point of transition. A series of Go-Live checks are performed to ensure the target system is operational before it is exposed to end users.
Step 13: Post Migration Support
The Migration Team remain in place to provide post migration support for any issues that the users may encounter. The team is made up of the migration team members including technical and business subject matter experts to ensure any immediate issues are captured and resolved as quickly as possible to minimise end user experience issues.
In conclusion, many attempted migrations fail due to the misconception that the data migration component is of secondary concern. Underestimating the complexity of a migration to a new system, and how equally important the data migration is in relation to the creation of the new system functionality, can lead to catastrophic failures and loss of service.
If you would like to understand more we would love to hear from you.
Call :+44 (0)1923 437 684