When a modernisation programme goes wrong, the failure is far more often in the data than in the code. A new application can be rebuilt; trust in the numbers, once broken, is extraordinarily hard to recover. Customers notice missing records, finance notices balances that no longer reconcile, and regulators notice gaps in the audit trail. Yet data migration is frequently treated as a late-stage technical task rather than the central risk it usually is. This article sets out how to move data off legacy systems while preserving its integrity, and how to prove to the business that nothing was lost.

Why legacy data is harder than it looks

The data in a long-lived system is rarely as clean as the schema suggests. Decades of changing requirements, workarounds and informal conventions leave their mark, and these surprises are what derail migrations.

• Undocumented meaning. Fields are reused for purposes never intended, and the real rules live in the heads of long-serving staff or in application code rather than the database.
• Quality decay. Duplicates, orphaned records, inconsistent formats and missing values accumulate quietly over years.
• Hidden dependencies. Downstream reports, integrations and reconciliations depend on quirks of the current structure that no one has catalogued.
• Volume and history. Years of historical data must often be preserved for legal and analytical reasons, even when it is no longer actively used.

None of this is a reason to delay modernisation. It is a reason to treat data as a first-class workstream from the very start.

Profile before you plan

The single most valuable early activity is data profiling: examining the actual data, not the documentation, to understand its true shape and quality. Profiling answers the questions that determine whether a migration plan is realistic.

• How many records are there, and how are they distributed across the values that matter?
• Where are the duplicates, the orphans and the records that violate the rules the system supposedly enforces?
• Which fields are reliably populated, and which are inconsistent or effectively abandoned?
• What does the data tell you about business rules that were never written down?

AI-assisted profiling can accelerate this dramatically on a large estate, surfacing anomalies and likely relationships far faster than manual inspection, so that the team spends its time interpreting findings rather than hunting for them.

Decide what to fix, move and leave behind

A migration is a rare chance to improve data, but trying to perfect everything is how programmes overrun. The discipline is to make deliberate decisions about each category of data.

• Cleanse what must be correct. Fix the data that the business genuinely depends on, and define the rules for doing so explicitly.
• Transform where the model changes. Map old structures to new ones with documented, testable transformation logic rather than ad hoc scripts.
• Archive what is needed only for reference. Move dormant history to lower-cost storage instead of carrying it into the active system.
• Retire what no longer serves a purpose. With appropriate sign-off, leave behind data that has no business, legal or analytical value.

Proving correctness: reconciliation and cutover

Migrating the data is only half the task. The harder half is demonstrating, to people who were not in the room, that the migration preserved everything it should have. This is where reconciliation earns its keep.

Reconcile at every level

Compare source and target not only by record counts but by control totals, checksums and business-meaningful aggregates such as financial balances. Discrepancies should be explained and signed off, not waved through. Automated reconciliation lets you repeat these checks cheaply on every trial run.

Rehearse the cutover

Run the full migration repeatedly against realistic data before the real event. Each rehearsal refines the runbook, exposes timing problems and builds the confidence that the final cutover is routine rather than heroic.

Choose a cutover strategy that fits the risk

For lower-risk systems, a single well-rehearsed cutover may be appropriate. For critical data, running old and new in parallel and reconciling outputs for a period provides a safety net and an evidence trail before the legacy system is retired.

Where combined capability matters

Safe data migration draws on several disciplines at once: software engineering to build robust, repeatable pipelines; AI-assisted profiling to understand a complex estate quickly; structured programme management to sequence the work and coordinate the cutover across teams; and an understanding of the business outcomes that decide what correctness actually means. Glaricx brings software engineering, AI, project and programme management, and digital transformation experience together, so data is treated as the central risk it is and the migration can be proven correct rather than merely declared complete.

Key takeaways

• Modernisation programmes fail in the data more often than in the code, and lost trust in the numbers is hard to recover.
• Legacy data hides undocumented meaning, quality decay and dependencies, so treat data as a first-class workstream from day one.
• Profile the real data before planning, using AI assistance to move quickly across a large estate.
• Make deliberate decisions to cleanse, transform, archive or retire each category of data rather than perfecting everything.
• Prove correctness with multi-level reconciliation, rehearsed cutovers and, for critical data, parallel running.

If a modernisation programme on your horizon depends on moving data you cannot afford to lose, Glaricx’s System Modernization service can help you profile, migrate and reconcile that data with confidence. We would be glad to discuss how to keep your data trustworthy through the transition.