The Lift and Shift

Migration

Replicating the old environment in the new one, rather than seizing the opportunity to improve

This pattern emerges when the pressure to migrate quickly overrides the opportunity to migrate well. Teams move existing workloads, data, or processes into the new environment with minimal change - carrying across not just the assets themselves, but everything that has accumulated around them: duplicate content and records that were never rationalised, missing or incorrect metadata, taxonomy structures that made sense when they were built but no longer reflect how the business works, and the technical debt of workarounds that became permanent. The rationale is always speed. Getting to the new environment fast demonstrates progress to leadership and avoids the perceived risk of redesigning while migrating.

In practice, it creates a more expensive problem: the same dysfunctional system in a new location, without any of the legacy justifications for why it was built that way - and a leadership team that believes the transformation is done.

The case below illustrates what that cost looks like at scale.

0+

data pipelines migrated as-is

2025 Gartner Application Innovation Summit

0%

overspend on lift-and-shift migrations*

cf. Gartner: 45% of lift-and-shift migrations overspend by 70%+ within 18 months

0mths

months behind board schedule

cf. 70%+ of PMI fail to capture planned synergies (RSM / McKinsey)

A global financial services firm migrated all four hundred pipelines as-is following a major acquisition, deferring data quality and structural work to a subsequent phase. The migration completed on time. Fourteen months later, the remediation programme was budgeted at two and a half times the original cost - consistent with Gartner's finding that 45% of lift-and-shift migrations overspend by 70% or more within their first 18 months. Teams were still hitting the same quality problems, maintaining the same shadow spreadsheets. The acquisition synergies dependent on unified data capability were eighteen months behind the schedule presented to the board - a result seen in more than 70% of post-merger integrations, which consistently fail to capture planned synergies and value (RSM US; McKinsey).

The cause was not the technology. It was a planning decision made in the first month: treat migration as logistics rather than design.

This pattern is especially common in three contexts.

Data migrations, where inconsistently structured data is copied without cleansing. Gartner estimates poor data quality costs the average enterprise $12.9 million per year, a figure that compounds rapidly when issues are not resolved before migration begins.

ERP and system implementations, where broken processes are mapped rather than redesigned, and the new system enforces the old dysfunction at greater speed.

Post-acquisition technology consolidations, where the acquired company's architecture is recreated rather than integrated: EY research finds 41% of integrations suffer from incompatible IT systems, and 32% identify data integration as the single biggest challenge.

The consequences

  • Operating costs remain high or increase: The new environment is optimised for old ways of working. The expected cost efficiencies never materialise.
  • Technical debt gets a second life: The remediation problem is now harder to justify - the migration is declared complete, appetite and budget have both shrunk.
  • Business benefits fail to materialise: Stakeholder confidence erodes. Future investment becomes harder to secure.
  • Teams become demoralised: The new platform behaves identically to the old one. The effort of migration delivered nothing visible.

Watch for this signal

If the migration plan contains the phrases ‘mirror the current state’ or ‘replicate as-is’, this pattern is already embedded. Migration is a design opportunity with a deadline. Organisations that treat it as a logistics exercise consistently find that their remediation bill exceeds their migration budget.

Root error: controlling uncertainty by not changing anything.

NEXT: Pattern 2 - Fragmented Ownership
Visit icpnet.com

Share on social