A UK CIO we spoke to last month runs technology for a £200m financial services business. His board had signed off a £600k modernisation programme to replace a 15-year-old client-facing platform with a modern cloud-first architecture. The application rewrite was on time and on budget. Two weeks into the data migration, his team discovered that 8 percent of legacy client records had duplicate primary keys tolerated by the old system, 15 percent had date formats that varied by user who created them, and the historical transaction log contained events that violated the new schema. The migration was paused for 3 months for reconciliation. Total programme cost hit £1.1m before the platform went live.
That is the data migration during modernisation conversation across UK and US CIOs in 2026. The application rewrite is the visible half of any modernisation. The data migration is the invisible half that determines whether the programme lands on budget. Every failed programme we have audited shared the same shape: data quality assessment postponed, failure modes surfaced late, reconciliation cost booked as overrun rather than scope.
This article is a candid guide for CIOs, Heads of Platform, and data leads scoping a modernisation programme. Why data migration fails more than any other step. The four failure modes that break most migrations. The pattern that ships. Real 2026 cost bands. What we learned migrating a UK property developer out of spreadsheets, email, shared drives, and WhatsApp groups.
Why Data Migration Fails More Than Any Other Modernisation Step
Application code has explicit requirements. A user story is either delivered or not; a bug is either present or fixed. Data has no such clarity. A migrated row can appear correct in the target while being wrong in ways that only surface when a business user runs a specific query weeks later.
Per Gartner data migration research, the majority of enterprise data migration projects run over budget or over timeline, and the single biggest driver is source-data quality issues discovered mid-migration. The specific pattern is consistent: teams assume the source is roughly clean, discover 2-4 weeks in that it is not, and spend the next 2-6 months reconciling. Per the IBM data migration methodology, organisations that assess source-data quality in the first two weeks of a modernisation programme are dramatically more likely to complete migration on the original timeline than those that assess later.
Every migration we have audited that overran budget had the same root cause: postponed data quality assessment. The four failure modes below are what postponed assessment inevitably surfaces late.
The Four Data Migration Failure Modes
1. Primary key collisions and tolerated duplicates. Legacy systems often tolerate duplicate rows, near-duplicate rows, or primary keys that were reused across time. The modern schema does not. Migration surfaces the duplicates. Reconciliation requires business rules to decide which record wins, which is expensive to design and expensive to run.
2. Encoding drift. Character sets (Latin-1 vs UTF-8), date formats (DD-MM-YYYY vs MM-DD-YYYY vs ISO 8601), currency (implicit vs explicit), and null handling (empty string vs NULL vs zero) that varied across users, time periods, or source-system versions. Only surfaces when the target system enforces a single format.
3. Schema evolution during migration. Enterprise source systems are rarely frozen during migration. New fields get added, workflow changes create new record types, business rules evolve. If the migration takes 4-8 months, the source has moved before the target is ready. Reconciliation now has to handle drift between the source at migration start and the source at cutover.
4. Historical anomalies. Records created 10 years ago under different business rules, discontinued product SKUs, retired customer types, deleted-but-not-removed records with orphan foreign keys. Valid in their original context, violate current schema constraints. Deciding what to migrate, what to archive, and what to discard is a business decision, not a technical one, and takes weeks of stakeholder time.
The teams that finish on budget surface all four in week one, price them in, and design the migration around them. The teams that overrun surface them mid-migration and treat them as surprises.
The Migration Pattern That Ships in 2026
Staged parallel-run with reconciliation gates. Not "big bang" cutover; that fails on any migration above 5-10 million rows. Not "lift and shift"; that just moves the failure modes to a new platform.
Stage 1: Data quality assessment (weeks 1-3). Read every source, sample-profile the data, identify all four failure modes, document business rules that resolve them, price the reconciliation work explicitly. This is where migrations are won or lost.
Stage 2: Extract-transform-load pipeline build (parallel to app build). Idempotent per row (safe to re-run any batch). Reconciliation checkpoint after each stage. Full audit log of every transformation.
Stage 3: Reconciliation gate. Before any batch advances to the next stage, three-way match: primary key count matches source, row count matches expected, business-rule invariants hold (client-total-balance in target equals sum-of-transactions in source, for example). Failed batches route to a human for review with the specific violated invariant shown.
Stage 4: Parallel run. Both systems live, dual-write for a defined period (typically 4-12 weeks depending on scale). Business users transact in the target; systems reconcile continuously. Cutover happens only after reconciliation is stable for 2+ consecutive weeks.
Stage 5: Cutover with rollback path. Source system frozen but retained. Any post-cutover data-integrity issue can be reconciled against the source. Source retired only after 60-90 days of clean operation.
Skip any stage and the migration will surface a failure mode you did not price in.
Real 2026 Cost Bands for Data Migration During Modernisation
The bands below are pragmatic for a UK or US mid-market data migration.
Migration tier | Migration cost | Reconciliation and validation | Timeline |
Small (single source, under 5m rows, standard schema) | £30k-£120k | £15k-£40k | 3-5 months |
Mid-market (2-5 sources, 5-50m rows) | £120k-£450k | £40k-£150k | 6-12 months |
Enterprise (5+ sources, 50m+ rows, complex schema) | £450k-£1.8m | £150k-£600k | 9-24 months |
Add specialist reconciliation (financial services, healthcare, regulated) | £50k-£300k additional | Add £30k-£150k | Add 2-6 months |
Add archival strategy for historical anomalies | £30k-£150k additional | Included | Add 1-3 months |
Two rules that hold at every tier. Reconciliation and validation is 20-35 percent of migration cost when scoped in week one and 60-80 percent when discovered late. And parallel-run period is worth budgeting explicitly; teams that skip parallel-run to save 6-12 weeks routinely spend 6-12 months on post-cutover data-integrity fixes.
For data migration cost 2026 planning, budget the reconciliation number as a mandatory line item, not a contingency; the maths says reconciliation always happens, only whether it is priced in or not.
What We Learned Migrating a UK Property Developer Out of Spreadsheets
WhiteStone built the SiteFlow platform for a UK property developer running large construction projects across London. Before we started, their "system" was actually four systems on four clocks: a shared Google Sheet for project tracking, an email chain for progress updates, a shared drive for drawings, and a WhatsApp group per site for daily updates and photos. The data migration was harder than the platform build.
The four failure modes showed up immediately. The Google Sheet had duplicate project names (same site under two variants). Dates ranged across three formats depending on who entered them. Emails referenced projects by nicknames that did not match the Sheet. WhatsApp photos were the only record of many field decisions and had no timestamps beyond WhatsApp's own.
The pattern we used was staged reconciliation. Week 1-3 we profiled every source and documented the reconciliation rules with the client's project managers (they knew "Building 7 East" and "B7E" were the same site; nobody else did). Weeks 4-16 we built the migration pipeline with reconciliation gates. Weeks 17-24 parallel-run: teams recorded new field data in the new platform while continuing WhatsApp for backup. Cutover at week 25 with the WhatsApp archive retained as a searchable evidence source for 12 months post-cutover.
Six months later the platform was live across five active sites with 100 percent of new field data captured natively and the historical archive searchable. The data migration was 40 percent of total programme effort, priced in from week one. If we had treated it as "the last step", the programme would have overrun by a factor we do not want to think about.
See our portfolio of shipped work for other data migration case studies. For a scoped modernisation and data migration conversation, book a data migration audit with WhiteStone.
Common Failure Modes
Treating data migration as the last step of modernisation. Team scopes the application build carefully, treats data migration as "we will figure that out when the app is ready". Discovers all four failure modes 2-4 weeks into migration with the timeline already committed. Fix: data quality assessment in weeks 1-3 of the whole programme, not weeks 20-24.
Skipping the parallel-run period. Team cuts over "big bang" to save 6-12 weeks. Business users hit data integrity issues in weeks 1-4 post-cutover. Rollback impossible because source system is decommissioned. 6-12 months of firefighting. Fix: parallel-run is mandatory above a few million rows or above a few source systems.
Under-scoping reconciliation. Team prices migration at £300k, does not price reconciliation. Reconciliation comes in at £180k as overrun. Board conversation ugly. Fix: reconciliation and validation is a mandatory line item at 20-35 percent of migration cost.
Frequently Asked Questions
What breaks most often in data migration during modernisation?
Four failure modes surface in nearly every migration. Primary key collisions from legacy tolerance of duplicates. Encoding drift across character sets, date formats, currency, null handling. Schema evolution when the source keeps changing during the 4-8 month migration. Historical anomalies that were valid at creation but violate current schema. Teams that price all four in week one finish on budget; teams that discover them mid-migration overrun.
How much does data migration during modernisation cost in 2026?
Small migration (single source, under 5m rows) £30k-£120k plus £15k-£40k reconciliation. Mid-market (2-5 sources, 5-50m rows) £120k-£450k plus £40k-£150k reconciliation. Enterprise (5+ sources, 50m+ rows) £450k-£1.8m plus £150k-£600k reconciliation. Add £50k-£300k for regulated-industry specialist reconciliation. Reconciliation is 20-35 percent of total migration cost when priced correctly.
What is the difference between lift-and-shift and data migration?
Lift-and-shift moves an application to new infrastructure without changing the data model or schema. Data migration moves data from one system or schema to another, requiring extraction, transformation, reconciliation, and validation. Lift-and-shift is 2-4 months and £30k-£100k per workload. Data migration is 3-24 months and £30k-£1.8m depending on scale.
How long does data migration during modernisation take?
Small migration 3-5 months. Mid-market 6-12 months. Enterprise 9-24 months. Add 2-6 months for regulated-industry reconciliation. These timelines include the mandatory parallel-run period (4-12 weeks depending on scale) plus 60-90 days of post-cutover reconciliation before the source system is retired.
What are the biggest data migration failure modes?
Primary key collisions and duplicates that legacy systems tolerated. Encoding drift across character sets, date formats, currency, and null handling. Schema evolution during a 4-8 month migration. Historical anomalies that violate current schema constraints. All four surface predictably; the question is whether they are priced in at week one or discovered mid-migration.
Can you migrate data without downtime during modernisation?
Yes, using parallel-run with dual-write. Both systems live during a defined period (4-12 weeks). Business users transact in the target while the source stays available for reconciliation. Cutover happens only after reconciliation is stable for 2+ consecutive weeks. Adds 4-12 weeks to the timeline and 15-25 percent to the budget; saves the post-cutover firefighting cost, which is nearly always higher.
Why choose WhiteStone Infotech for data migration?
We built the SiteFlow platform migrating a UK property developer out of spreadsheets, email, shared drives, and WhatsApp groups into a structured platform, where the data migration was 40 percent of total programme effort priced in from week one. We ship 50+ custom software and platform migrations across the UK, US, and Europe. Every migration engagement starts with weeks 1-3 data quality assessment, reconciliation-cost pricing, and parallel-run planning before any pipeline is built. Contact WhiteStone Infotech at whitestoneinfotech.com/contact.
The One Thing to Remember
Data migration during modernisation succeeds when three things are true: data quality assessment happens in weeks 1-3, reconciliation is priced explicitly as 20-35 percent of migration cost, and parallel-run is scoped as mandatory. Get any of these wrong and a £400k migration becomes a £900k one. The maths on doing it right the first time is unambiguous.
.webp)