Time and again we are called into strategy conversations to help an organization plan a system implementation, consolidation, or conversion. The question that needs to be answered is what is the primary driver behind the project? If the goal is to achieve some operational efficiency, improve performance, or realize some capabilities not achievable in the old system then the data migration project must be treated as a business process, not a technical exercise. A technical exercise will simply move your data from the old system, apply some minimal transformation, and load it to the new system. We like to refer to this as a “bug for bug copy”. Every issue from the old system is now resident in your new system, including duplicate customers, materials, products, and vendors, incorrect payment terms, wrong or missing tax information, incorrect banking details, and more. The data migration is the best time to clean all of your data and filter out any old data you’re not going to use again. Also, it is a great time to cleanse and harmonize relevant data and collect missing data. Plans to make these corrections after you have loaded it to the new system are flawed. It is very difficult to make mass corrections to data already loaded into the new system, and the majority of the time it is mere impossible.
Treating Your Data Migration as a Business Process
Migration projects treated as a business process will naturally lead to an earlier realization of value in the target system, thus speeding the ROI. Having the business work with the data throughout the engagement, including defining the data rules and definitions, and testing with real data, will identify gaps in the data and in the target design before the cut-over event. Be sure to perform user acceptance testing with real data. This will dramatically increase confidence in the target system. Also, plan the testing cycles to use real data throughout, always leaving time for proper defect management in the testing cycles. The combined effect of engaging with the business subject matter experts to identify the rules, perform data cleansing, map source systems to the new target, and testing with real data will lead to a more successful go-live.
3 Types of Analysis for Successful Data Migrations
A consistently successful strategy for data migration follows three types of analysis: Business Relevance, Business-Readiness, and Target-Readiness.
Business Relevance dictates that only required data is migrated. As stated above, it is of little value to migrate data no longer needed. The project must define rules to properly filter data and identify what is active and what is not. That isn’t to say old data is not of value for historical reporting. If that is the case then push the old information to a proper reporting platform. In properly identifying the set of active data you will reduce the cleansing effort dramatically. Not only is the amount of cleansing reduced, the value of cleansing is increased because you will be correcting data that is being used most often.
Business-Readiness is what ensures the source data will actually perform in the new system. You can expect your new system will have different requirements on the data than the source. This is especially true when a driving factor for the new system is to realize capabilities not previously supported. Business-Readiness means closing the gaps to ensure you get the expected results. Often new data needs to be collected or existing data needs to be altered. When it is not possible to create the new data in the old system you need a reliable and manageable strategy. Employing spreadsheets for this task is a common fallacy because it is near impossible to manage the quality and completeness of work being performed in spreadsheets. Once you have put source data into a spreadsheet and distributed it to the business user you have lost control. Follow a process that allows you to collect and validate data in a controlled environment. Our data migration platform supports precisely this requirement allowing the migration team to manage and measure the data construction process.
Target-Readiness is the final analysis is to ensure the data will actually load to the new target. By comparing the data to the target requirements prior to attempting a data load, the project will have more time to make corrections and will experience a more successful load at each testing cycle. Error conditions can be remediated earlier in the process. This also negates the need for a load cycle in the project plan simply to catch the error.
The combination of loading Business-Relevant, Business-Ready, and Target-Ready data will intuitively produce a better result. Follow this strategy throughout the implementation, for each testing cycle and your next go-live is sure to be a success, you may even call it Boring.
About the AuthorFollow on Twitter More Content by Mick Collins