As history has shown, platform transformation programmes that require large-scale migration of customers and their data from one technology to another are extremely complex to deliver. Migrations are often the area where most issues arise.
From our experiences, we have formed a view on best practice approaches to delivering a successful migration event. We are also observing a shift in the traditional approaches to migration as cutting-edge technologies from the cloud era mature and are increasingly being utilised.
In this article, we explore key parts to get right in platform migration events and initiate discussion on new approaches that aim to also address inherent weakness in traditional migrations.
The migration approach forms the backbone of every migration and is one of the most critical project decisions. Deciding on a ‘big bang’ versus a phased approach and the scope of transactional data to migrate are just a couple of the key decisions that aggregate to form the ‘migration approach’.
The best migration approach is one that balances risk, cost and complexity based on the different implications that the approaches entail (for example, the total number of migration events run, degree of risk based on the migration segment size and any parallel running required).
A key mistake some firms make is considering the migration approach in isolation. There are interdependencies between build, testing, migration and business readiness which all need to be considered. By creating an approach in isolation, you risk finding out too late that the approach does not sync with the rest of the delivery. For example, adviser data not migrating in time or migration testing being squeezed at the end of the programme.
It is also important to plan for failure. Most migrations will have issues, but this does not have to translate into programme failure. A good migration approach should anticipate failures and plan accordingly through rollback approaches, failure detectors, contingencies, and so on.
Given the nature of migrations, there is an inherent focus on data, and those involved must be sufficiently skilled to carry out the data migration. Ideally, the migration should follow a proven methodology to de-risk the event as far as possible.
For a long time, the process of extracting, transforming, loading and migrating data has been dominated by macro-based tools operated by an army of technicians. New technologies and techniques, most from the rapidly maturing cloud industry, are becoming prevalent and convenient enough to be applied to general transformation programmes.
New tools such as Apache Spark, Talend, Informix, Rocket, and techniques such as machine learning and data-driven testing promise more reliable data manipulation and migration. Companies should explore these new methods and evaluate whether this would reduce their migration risk profile as well as the associated cost.
Regardless of the tool utilised, successful data migration will continue to require a contextual understanding of the current and future data model; clear articulation of what is core versus non-core and, most importantly, lots and lots of testing.
Finally, the whole operating model and activities required to underpin the migration need to be thought through in the lead up to the migration event, interim states and post-migration. The focus should not only be isolated to those areas directly supporting intermediaries and customers.
For production support, ensure there is a process for how defects will be logged, triaged, prioritised and fixed. Clear communication strategies need to be in place so that systemic issues are identified and escalated quickly.
Any training or upskilling required for operational teams where processes have changed needs to be scheduled well in advance of the migration, with regular top-ups to ensure knowledge remains fresh. Ideally, operational staff should be embedded in delivery teams to ensure any process changes are identified in advance and incorporated into procedures.
Lastly, forecasting likely volumes of communications out, enquiries and transactions are critical for resourcing. It may be useful to employ third parties as part of the migration process to increase the availability of front-facing teams (for example, use of a third-party call handling service for simpler queries). Communications for front line teams and customers on what to expect post-migration need to be carefully prepared, and regularly updated, as issues are identified and resolved.
The considerations discussed in this article should provide a level of assurance to those organisations undertaking migrations. We don’t believe that migrations are something to be feared, as with the right preparations, migrations are something that can enable the business to complete the goals of the transformation programme.