A transition plan is on the table. You’re dealing with an acquisition, merger, insourcing, outsourcing or IT renewal. The fact that data needs to be moved from A to B is clear. Our IT department simply prepares an interface and you’re ready to transfer. That’s it, right? It can’t be that hard. We set aside a provisional budget. Or is it more complex and riskier than anticipated? What’s the impact of a loss of information, operational backlogs, subsequent patchwork, gaps in the reports or worse, reputation damage and customer loss? We don’t really know, which makes it a risk, both in terms of the feasibility of the transition programme and the production thereafter.
To reduce this risk, you need a preliminary data migration study: look both ways before crossing! This article discusses specific parts of this preliminary study and is intended for (prospective) project or programme managers of a transition programme or data migration project. A preliminary data migration study is the foundation for successful data migration!
A data migration preliminary study defines the scope, determines the strategy and contains the control plan for the data migration. Finally, the preliminary study substantiates the budget and provides realistic integrated planning. These parts are discussed below, in the stated order.
Data migration scope
The scope defines what is going to be migrated, but particularly also what is not. We do this by asking several questions from the following perspectives:
What is the transition about? When a portfolio is taken over, do we understand its diversity? Are products harmonised? Is there sufficient insight into the history of the portfolio to be migrated? Do we recognise inherent transition complexity, such as a shift from a product-oriented to a customer-oriented operation?
Based on the new systems & processes, an inventory is made of what information is required in a ‘broad sense’. This will soon determine what data and what history will actually be migrated. Customers, products, agreements, transactions, conditions, authorisations, compensations, credits, etc. Are there any additional requirements regarding reports? What is not available in the sources? Where does it have to come from? What is migration and what is configuration? What can be done manually and what needs to be done automatically? Which history should be transferred or will there be an archive? What underlying systems are affected? Thorough business knowledge is decisive for the quality and completeness of the scope.
What target systems are fed what data? Note! That need not be limited to the primary, obvious systems. References between applications, for example, must be guaranteed. Parallel change processes are often running simultaneously. Are these interdependencies clear? Next, we determine which information flows from which source to which target. All of this forms the migration landscape.
Current business processes are cut at the time of migration. The impact of cut-over issues is mapped out. After all, any process that cannot be completed beforehand or that cannot be postponed until after migration creates extra complexity. It is important to recognise the impact early on, for example for customers.
From this perspective, it is important to assess the topicality and quality of the description of the data. It is determined what information is contained in which tables, both on the target side and on the source side. Based on this inventory, it is determined to what extent the source data covers the information requirements (FIT-GAP) and how many tables and attributes must be filled on the target side. This largely determines the number of transformations. Actually having the source data available at this stage is often not feasible. Data analyses and an ‘initial’ assessment of the data quality are then postponed to a subsequent phase of the project.
Data migration strategy
The data migration strategy describes how the actual data migration is ultimately performed. Is all data transferred at once, like a ‘Big-bang’, or is it transferred in parts, for example per product, organisation or customer group? What are the timelines within which it must be completed? A strategy in which the ‘shop remains open’ during the data migration looks fundamentally different from a migration during which the shop is closed from, say, Friday evening to Monday morning. Sometimes a data migration involves more, with parallel transitions occurring at the same time. Everything has to be arranged like clockwork. The data migration strategy determines the conditions, frameworks and dependencies.
When is the migration a success and what should be avoided at all costs? A control plan includes the quality requirements and countermeasures to achieve this. This includes dynamic checks, testing the new system and reports with migrated data, as well as the measures demonstrating the completeness, correctness and reliability of the migrated data. This results in an integrated control plan, together with specific additional measures, if need be.
Planning and Calculation
A realistic calculation (time & money) is made for the development and implementation of the data migration. This calculation is based on the scope, strategy and control plan. Data eXcellence uses benchmarks for this. These benchmarks are based on dozens of successfully executed projects. In addition, indications are given for related activities such as data cleaning. A realistic timeline is drawn up based on a reliable estimate and milestones, including the associated risks and measures.
Conducting a data migration preliminary study requires data migration know-how and a proven track record, but above all knowledge of the industry and business operations. Data migration is not just a technical exercise.
The depth and duration of the preliminary study are correlated. The general guideline is a lead time of six weeks during which a series of workshops and interviews are held. The result of the preliminary study is a report, which forms the foundation for the realisation. In addition, this report, in the form of a Schedule of Requirements, can serve as a basis when calling for tenders for the data migration.
Once the data migration playing field has been mapped out from these perspectives, you can cross safely and with confidence.