The complexity of data migration means that a chosen methodology can seem like a sea of steps, which can be difficult to get all the stakeholders to buy into.\u00a0 Focus on the most startling element of the migration \u2013 the fact that the legacy system will be turned off \u2013 and the attention of the stakeholders is guaranteed. If you\u2019re going to turn a large system off, you need a plan.\u00a0 Best practice requires careful planning for all these elements:<\/p>\n The data migration team needs to develop a thorough understanding of the system that\u2019s to be turned off.\u00a0 The first step is to model the legacy system in its entirety.\u00a0 Even an organisation with an apparently simple legacy system may be hiding, for instance, departments running data in Excel or in an Access database.\u00a0 There may be satellite locations with their own separate systems.\u00a0 As you start to talk to stakeholders across the organisation, you\u2019ll discover more connections which need to be brought into the new system.\u00a0 You\u2019ll also discover parts of the legacy system which are no longer used \u2013 often there is no need to migrate these to the new system.<\/p>\n Data migration best practice helps to generate confidence across the organisation.\u00a0 To create the best chance of the organisation running smoothly during and after the migration, consider these steps:<\/p>\n Project scoping and dry runs sometimes indicate that a big bang approach to the migration will not run smoothly.\u00a0 This is where changing to an incremental approach can be the best course of action.\u00a0 With an incremental approach, the old and new systems run in parallel, with a data highway keeping both up-to-date.\u00a0 The migration occurs piece by piece, and the legacy system is turned off once all data and processes have been migrated. Testing will always be required, so gain users\u2019 buy-in by involving them early on in the project.\u00a0 Ask if the providers of the new system have tools that will help give users confidence, such as repeatable tests of their system.\u00a0 Tests should ideally be configured so that expert users are not required to input too much detail.<\/p>\n Data migration usually involves a host of different teams, often competing: users; new system providers; old system experts; migration experts and project managers.\u00a0 \u00a0\u00a0Encourage teams to communicate as they find issues, and create a central repository for data quality and system issues so that they are recorded somewhere that everyone can see. This improves visibility and avoids a silo mentality.<\/p>\n You need people to agree to turn the old system off, so identify these people and bring them with you.\u00a0 Decide what documents they will sign off and ensure that these are neither too large nor hard to understand.<\/p>\n Using tools is a recognised best practice.\u00a0 It is far more efficient than trying to carry out tasks such as migration scripts by hand.\u00a0 Tools can be used throughout the migration, for instance for data profiling, discovery and quality, for core migration and for testing.\u00a0 But your team will require skills in using the toolsets.<\/p>\n In summary, start the data migration project early in the programme and review all the options available to you.\u00a0 Incorporate tools and a methodology into your planning to minimise risk.\u00a0 The project is primarily concerned with continuity, so adopting best practices ensures that the new system operates as smoothly as possible.<\/p>\n Find out more about data migration planning in our article on essential planning components<\/a>.<\/p>\n <\/p>
\n![\"Data-migration-eGuide\"](\"https:\/\/etlsolutions.com\/wp-content\/uploads\/2016\/07\/Data-migration-eGuide-read-more.jpg\")
<\/a><\/p>\nDevelop a system retirement plan<\/h4>\n
\n
Understand the legacy landscape<\/h4>\n
Build confidence with incremental migration<\/h4>\n
\n
\n<\/a><\/p>\nTesting, testing<\/h4>\n
Communicate widely<\/h4>\n
A full set of tools<\/h4>\n
Further reading<\/h3>\n\n
<\/ul><\/div>\n