Why Most Technical Migrations Fail Before the First Line of Code

Personal content — not employer-related. This article is published in a personal capacity and shares thoughts and experiences based on public industry patterns — not a description of employer or client systems, and not professional instructions. It does not reflect the views, systems, projects, or policies of any current or past employer, client, or financial institution. See the full site disclaimer.

I’ve seen migrations fail in planning docs and committee meetings, long before anyone started writing the actual code. The first problem is almost never the technology.

Context: End of 2023 was still peak migration-program season. Board dates, vendor SOWs, teams told to “be on cloud by Q2”. The ones that struggled almost never failed because of networking or storage. They failed because the hard decisions were never made before engineering started.

These are notes from that side of the table - when leadership says “make the migration happen” without the preconditions that let engineering succeed.

1. Nobody agrees what “done” means

IT says migration is complete. Business says the reports are wrong. Finance says cost went up.

“Done” meant different things to different people: infrastructure lifted, metrics matching within a threshold, legacy switched off, operating model updated. Often only the first one was written down.

What helped: a one-page definition agreed by business, finance, and engineering - which workloads in which wave, parity thresholds (for example revenue within ±0.5% for 30 days), decommission dates, who approves cutover. Without that, teams optimize for go-live theater.

2. Migration is treated as a project, not a product handoff

The SI delivers. The internal team inherits a black box. One hero burns out keeping it alive.

Budget and timeline focused on cutover. Year-two operations were an afterthought.

What helped: staff for run state before kickoff, not only sprint zero. Put runbooks, ownership, and on-call into acceptance. Plan 20–30% capacity for stabilization after go-live in the roadmap you show upward.

Executives hear “we migrated”. Operators live with “nobody knows why this job runs at 3am”.

3. Parallel run with no end date

Double infrastructure for 18 months. Two numbers. Endless arguments about which one is “true”.

People are afraid of cutover. Nobody wants to own decommission risk.

What helped: mandatory decommission milestones with named sponsors. Fund reconciliation during parallel run - do not leave it to volunteer overtime. Escalate when parity is “good enough” but decommission keeps slipping. Parallel run is a bridge, not a home.

4. The wrong people in the room

Vendors or infra-only teams decide the architecture. BI and data consumers find out at UAT.

The charter covered moving. It did not cover using.

What helped: bring consumers, BI, analytics, and security into wave planning from week one. Assign a business owner per domain, not only a technical workstream lead. Do not lock architecture if access patterns are unsigned.

5. Honesty gets punished

Status stays green until go-live week. Then everything is red.

Teams are rewarded for hitting dates and punished for raising risks early. So they hide uncertainty.

What helped: separate status reporting from blame. Use milestone demos on real data, not decks. Protect buffer in the plan you show leadership. The fastest way to miss a date is to pretend the uncertainty is not there.

A short list I used before saying “start”

Migration pre-flight checklist diagram

Question	If no
Is “done” defined and signed?	Do not start wave 1
Are owners named for the run state?	Do not accept vendor handoff
Is decommission scheduled?	Do not approve parallel-run budget
Are consumers in the loop?	Do not lock architecture
Is stabilization capacity funded?	Do not commit a public date

That list saved more programs, in my experience, than another proof-of-concept cluster.

I even kept a one-pager template in markdown for steering packs:

# Wave 1 - definition of done
Workloads: [list]
Parity: revenue_eur within ±0.5% for 30 consecutive days
Owners (run state): business ___ / technical ___
Decommission date: ____  Sponsor: ____
Stabilization capacity reserved: ___% for __ weeks
Consumers signed (BI / analytics / security): [yes/no]

How I learned to talk to executives

Bad: “We need six more months for technical debt.”

Better: “We can go live in April on infrastructure. Business cutover in June if parity holds for 30 days. Otherwise we risk wrong reporting and double cost until legacy is off.”

The job is translating risk and trade-offs. It is not being the best debugger in the room.

Closing

Most migrations fail before the first line of code because success was never agreed, ownership ends at go-live, and incentives hide problems.

Get those leadership pieces right - definition of done, run-state staffing, courage to decommission, consumers in the room, honest status - and engineering has a chance.