This chapter is about the overall migration strategy: how to go-live with the new system and migrate your data from existing systems. How to go about this is probably the single most important thing to get right. Not getting this right amounts to damage to company image, client loyalty and your bottom line.
Your game plan, or overall migration strategy, must answers these two questions:
- System go live: Are you going live prior to the data migration or simultaneous with the data migration?
- Data migration: In how many slices do you migrate your data? One ‘big bang’ or more slices?
So, what’s your game plan? Maybe your intuition is to go-live with the new system first and then do a step-by-step data migration. In that case, you’re in good company: most of our customers have this idea at first or have an initial approach like this. Interestingly enough, less than 25% end up doing it this way.
Less than 5%
Less than 5% of the migrations ended up implementing a more complex strategy. We are talking about catch-up or delta strategies, pre-loading strategies and incremental strategies. At least 25% of the projects considered these strategies, but only a couple ended up implementing them. The lesson here is that these strategies require due justification because of their inherent complexity. So, if you are considering one of these, try making one of the other simpler strategies fit first!
What is the industry doing?
Answering these questions in a generic way doesn’t add a lot of value. Instead, let’s look at what the industry is doing: What are your colleagues deciding and why?
We’ve compiled data on more than 30 financial data migrations at Tier 1 & 2 European banks and insurance companies. The data migrations themselves vary in size from 50.000 to 5.000.000 clients and from a few hundred thousand transactions to more than 500 million transactions. All kinds of financial products are represented including payments, cards, mortgages, savings, securities, pensions and life & non-life insurance.
Here’s an overview of what these projects ended up doing for system go-live and data migration.
55% of the projects executed a scenario where the system went live before the data migration. They executed the data migration in a big bang after the new system proved stable.
23% of the projects did everything at one moment: going live with the new system and doing a big bang data migration – all in one weekend.
22% of the projects went live with the new system before the data migration, but did a sliced approach for the data migration
Just to note: the quadrant bottom-left is empty: the scenario where the system goes live simultaneous with a sliced data migration does not occur in practice.
Let’s take a closer look at why these projects choose one option over the other.
System go-live: Prior to data migration is preferred
The preferred system go-live strategy was prior to data migration. Over 75% of projects choose going live with the new system before migrating any data in. What are the main reasons this option was chosen and when should you consider it?
The main reason for considering this scenario is that the target system is unstable or not yet proven. Most data migrations take place because new technology is being introduced. However, there is no proof yet that the new system is stable and functions properly in the business context. A proper way to mitigate this is to have the new system run for 1 to 6 months before trusting it to accept all existing data. And let’s be fully clear here – just because you’ve chosen an off-the-shelf solution doesn’t make you immune for this risk. Our experience shows that the many customizations you’ll apply and all the interfaces required for running the new system within your IT environment will leave you just as vulnerable.
The impact of this scenario - going live prior to data migration - is the extra complexity and costs associated with having two systems live at the same time. For example, it involves extra routing of transactions, making additional functionality for the call center to support two systems, operating two systems, constructing extra reporting to consolidate the two administrations just to mention some. Also, two systems are confusing for users (and clients) and may be inducing errors.
System go live: the other 25%
The other 25% of projects opted for going live with the new system at the same time as migrating the data.
This is a viable option when the other option is not feasible or too complex. It is up to the project to mitigate the risk of the new system by rigorously executing tests and verifications.
The impact of this scenario is a multiplication of the test plan and budget by 1½ to 2 times what you would normally plan to build up the necessary confidence.
Note that this option is only viable if a full integration test environment is present or can be constructed. It needs to be proven that the new system functions in the bigger context, including reporting, interfaces etc.
Data migration: Big bang data migration is preferred
The preferred data migration strategy executed (75% of projects) is a so-called big-bang – all data and operations are moved from the source systems to the target platform in one single weekend.
Interesting is that at least half of these projects initially planned to do a data migration with more slices, but ended up migrating everything at once. Why choose a big-bang migration?
- The alternative - migration in steps - means you must have two operational systems – with all the drawbacks we talked about above. If the drawbacks are too big, you should plan for migrating everything at once.
- Migration moments are complex, costly and a heavy burden on the expert staff involved – the fewer the better.
- Extra testing, other validation mechanisms and recovery plans can effectively be used to reduce risk and build confidence along the way.
Data migration: the other 25%
Almost 25% of the projects chose a sliced approach, varying from between 2 to 10 slices. When should you consider it?
- As a risk mitigation strategy in 2 slices – do a small so-called friends and family migration (for example personnel only) and after confirming that all important processes work well – usually within 1 to 2 months – migrate the rest in one weekend. This option does require two operational systems, but only for a limited time.
- As part of a multi-phase release strategy – preparing the target platform for all types of clients or products in one step is too big, so the data migration strategy is adapted to match the release phases of the new system.
- Due to unsurmountable or expected migration performance issues – migrating all clients in one weekend simply doesn’t fit because the target platform can’t process all the data within the available time frame – often an issue with 24/7 services – or manual adjustments are required post-migration.
Conclusion
If your intuition is to do a sliced approach for data migration, you’re in good company. However – judging the heuristics - it often is not the best solution or the approach you end up with. All the more reason to challenge your intuition or re-visit your initial approach. We advise you to research your scenarios thoroughly and analyse them based on impact and risk on customer, systems, processes, reporting and people.