Data migrations arise from rationalising existing systems or moving to new ones that address deficiencies in legacy solutions. It is a critical component in the overall migration programme to start realising benefits, and delays will have a direct impact on bottom-line expectations. Digiata has been assisting various corporates for over a decade with their migration challenges. This article offers insights gleaned from that experience that can help businesses meet their migration goals on time.
The golden rule of any migration is that the projects be business lead. Although data migration is a technical challenge, the business must own and drive the process. The business needs to know how the new system should work, what it should be capable of, and what will be expected from data and processes.
Expert knowledge from within the business as to how existing systems operate needs to be harnessed to ensure that new systems are able to drive new and old functionality, and it’s also necessary to ensure that new features are capable of offering the products, tools or services the business requires of them.
The larger the data set, the more complex it is to migrate from an old system to a new one. Thus, it pays to avoid migrating any data you don’t need to. Typically, businesses feel compelled to migrate all of their data, including historical data, but often this isn’t necessary.
At the same time, one of the biggest challenges for data migrations is data cleanliness. If you’re struggling to get data from system A to system B, it’s often because the data isn’t clean in A. Data can be cleansed during the migration process but requires a business data owner who can make calls on precisely what needs to be moved, and how it needs to look. Often data migrations are planned without understanding the true state of current data.
Whether you decide to use an off-the-shelf data migration solution or a bespoke one, the key should be agility, and comprehensiveness. You don’t want a tool that does integration but not reconciliation, for example. It usually pays to defer to your migration provider’s expertise when choosing a solution – trust their expertise rather than trying to force them to use a solution that you are accustomed to. This may create more challenges, or require additional solutions for the processes it is not able to complete.
New structures or processes might require companies to re-visit their user-allocated roles and tasks. Companies often leave this until last, but that failure to provide the correct mapping of user roles upfront can result in enormous problems down the line, and can see one job function turn into two, or other way around. It’s essential that a company defines from the outset who is going to need access to what, which roles they have, and what they’ll be able to do on the new system.
Data will follow process and functionality. As such, it’s essential that functionally from old to new is mapped so any gaps are identified at the outset. As for data migration, these gaps need rules for governing the conversion between the old system and the new one. Mapping will require involvement from SMEs between the old and new. These might be challenging, as typically business SMEs won’t yet be completely familiar with how the new system works. Try and resolve this from the outset to avoid downstream delays.
A key challenge to ensuring migration projects run smoothly is getting the necessary line of business staff seconded to a project. These projects create a spike in critical business resource demands. Practically a business must still run while migration projects are executed. Failure to recognise these challenges upfront may result in the lack of critical resources when you need them most.
Given the critical IP required to deliver a project from start to finish, it pays wherever possible to ensure that those staff members working on the project will be available for its full duration. Changes to key project members during a programme necessitates handovers, where IP typically gets lost and the project suffers accordingly.
A successful migration requires a proper test environment and frequent test runs. In an ideal scenario, a test run should be undertaken any time a change is made. That’s often not feasible, but wherever possible you should undertake to do as many test runs as possible, as often as possible, and from as early in the migration process as possible. You don’t know what you don’t know. The sooner you start the more likely you are to identify and alleviate problems or blind spots, resulting in a smoother process down the line and less chance something serious needs fixing towards the end of the programme.
The new system to which you migrate still has to work with all of the peripheral ones essential to your business. Those peripheral systems are seldom all under your control and could involve other institutions or third parties. You will need to test or conduct dry runs with these parties, which may not have the same respect or pressure for your deadlines. You need to be pro-active in understanding which systems are involved at the get-go, and making sure the necessary people are in a position to cooperate timeously.
Despite being absolutely essential, reconciliations often only get attention late in the migration process, with companies focusing more on moving data than on comparing it to ensure its accurateness between the old system and the new. Best practice means reconciling from the start by checking data as soon as its loaded, and by deciding upfront how you’re going to reconcile data, and what the key parts are. Ensuring completeness, validity and accuracy of data from old to new is a critical deliverable. You will need the checks and controls in place not only to ensure the objectives are met, but also to provide evidence after the fact.
While it may be a technical task, data migration is a critical component of a bigger programme aimed at delivering benefits to your bottom-line. Lack of pro-active action on the considerations outlined above could result in projects running over budget, and will delay the realisation of the business benefits that initially motivated the project.