The hidden risk in data migration

Data migration is a business decision, not a technical task

The question that organisations fail to ask at programme initiation is simple: what is good data in the new system? Not technically. Operationally. What does an HRIS require to run payroll correctly? What does an ERP require to manage financial close? What training data does an AI model need to produce reliable outputs? These are business questions answered by finance leaders, HR business partners, and data scientists. Not by technical teams.

When data migration is treated as a technical task, the business fails to define these standards, and IT proceeds based on assumptions. In an HRIS programme, this means employee records with incomplete or conflicting historical data, leave balances that cannot be reconciled, and payroll history that does not match statutory records. In an ERP programme, it means vendor records without credit terms, chart of accounts without cost centre allocation rules, and inventory without accurate opening balances. In an AI programme, it means training datasets with inherent bias, missing attributes that correlate with outcomes, and historical records that do not represent the future distribution of the data.

The consequence is that cutover proceeds with known data quality issues, operations cannot be performed reliably, and months of forensic work follow to fix problems that should have been resolved before go-live. This is a governance failure, not a technical failure.

Data quality is always worse than assumed

Most organisations have no systematic record of data quality in legacy systems. They have estimates. Assumptions. Hopes. When a data audit is conducted, the findings are usually worse than expected. Fields that were assumed to be complete are sparsely populated. Data entered in different formats across different regions. References to entities that have since been deleted. Calculations that do not reconcile to their source. Records that should have a single owner but have been updated by multiple systems with conflicting information.

The cost of discovering this too late is severe. In an HRIS programme with five thousand employees, discovering that leave balance history is incomplete two weeks before go-live means either delaying go-live by six weeks, or accepting that leave balances will be manually adjusted in the new system after cutover. Neither is acceptable. In an ERP programme, discovering that cost centre allocation is inconsistent across the general ledger means either spending months on data remediation, or accepting that cost centre reporting will be unreliable after go-live. In an AI programme, discovering that training data contains systematic bias means retraining the model, which requires data curation, which requires subject matter expertise, which is scarce and expensive.

The organisations that manage this risk do not assume. They audit. They document findings early. They build remediation into the programme schedule. And they hold the business accountable for the quality decisions.

The cost of getting it wrong extends beyond cutover

Failed data migration does not just delay go-live. It creates downstream operational and compliance risk that organisations often do not quantify until after the event. A payroll system that operates on unreliable leave balance data creates liability if employees are paid incorrectly. An ERP system that operates on incomplete vendor data creates procurement risk and prevents cost analysis. An AI system trained on biased data produces biased outputs, which can expose the organisation to discrimination claims if those outputs inform hiring, lending, or resource allocation decisions.

The financial impact is also underestimated. The cost of operating with unreliable data includes manual reconciliation work, delayed financial reporting, increased audit findings, and reduced management confidence in the system. These costs persist long after go-live. Many organisations find that the operational drag from poor data quality lasts for years, and the cost of fixing it retroactively is substantially higher than the cost of getting it right upfront.

Compliance is another layer. In regulated industries, data migration failures that result in inaccurate financial records, incorrect employee payments, or data integrity breaches become audit findings. In the worst cases, they trigger regulatory investigations. The cost of remediating these issues after discovery is orders of magnitude higher than the cost of preventing them.

Data migration is scoped too late and resourced too lightly

The typical programme timeline allocates data migration to the final quarter, after business processes have been designed, architecture has been finalised, and technical solution has been selected. By this point, the largest data quality decisions have already been made. The organisation has committed to a chart of accounts structure that cannot easily accommodate legacy cost centre codes. It has selected an HRIS that requires different employee record structures than the legacy system. It has chosen an AI algorithm that requires different input features than the training data contains. And it is now too late to change these decisions without derailing the programme.

The typical resource allocation is worse. Data migration is staffed after the core programme team is established. There is usually one data migration lead, often part-time, sometimes borrowed from IT operations. There are no dedicated business subject matter experts. There is no data quality team. The assumption is that existing IT staff can manage data extraction and technical transformation, and that business staff can dedicate time to validation whilst executing their day jobs. None of these assumptions is realistic.

The solution is not easier. It requires data migration governance to be established at programme initiation. A data governance board. A data quality baseline. A cleansing plan. Resources allocated for the full duration of the programme, not just the final phase. And most importantly, it requires business accountability for data quality decisions, not technical accountability for data extraction.

What good data migration governance looks like

Organisations that execute data migration successfully share several characteristics. First, they establish data governance at programme initiation, not in the cutover phase. A data governance board is formed, with representation from finance, operations, IT, and the business. This board owns the data quality standards that define what good data means in the new system. These standards are documented before technical solution design begins.

Second, they conduct an early data audit. Before architecture is finalised, the quality of source data is assessed. The audit answers specific questions: what fields are complete? What is the format consistency? What historical depth is available? What reconciliation can be performed to validate accuracy? This information is then used to inform solution design decisions. If legacy data does not match the target system structure, the solution is adapted to accommodate it, or the legacy data is remediated before migration begins.

Third, they assign business ownership for data quality decisions. A CFO approves the chart of accounts migration. An HR business partner approves the employee record structure. A data scientist reviews training data for bias. These decisions are made early and documented. When technical teams encounter legacy data that does not fit the target structure, there is a clear business process for making the decision: remediate the source data, adapt the target system, or accept the risk. Business leaders, not IT, make this decision.

Fourth, they resource data migration adequately. This includes dedicated data quality analysts, business subject matter experts assigned for the full programme duration, and often a data migration lead who reports to the programme director, not to IT. The data migration team participates in solution design, not just implementation.

The reconciliation problem nobody plans for

Even with good data migration governance, there is a phase that most organisations do not plan for adequately: reconciliation. After cutover, the legacy system and the new system must run in parallel, sometimes for weeks, sometimes for months. The purpose is to validate that transactions have migrated correctly, that data balances match, and that the new system is operating reliably. This phase is often estimated at two weeks and then extended repeatedly as unexpected discrepancies emerge.

The reconciliation period requires dedicated resources from every area of the business: finance reconciling the general ledger and balance sheet, operations reconciling inventory and transaction history, HR reconciling headcount and payroll. It requires the legacy system to remain operational and staffed, even though the organisation is trying to move away from it. It creates operational drag at a time when the organisation is attempting to transition to new processes. And it exposes data quality issues that should have been discovered during testing but were not.

Good programmes plan for reconciliation upfront. They establish reconciliation protocols before cutover. They identify which transactions must reconcile and which are expected to differ. They assign responsible parties for each reconciliation activity. They allocate budget for the legacy system to continue operating during the reconciliation period. And they plan contingency time for data remediation if discrepancies emerge. Most importantly, they do not attempt to transition to business-as-usual until reconciliation is complete and validated.