A Migration Is a Trust Problem

In a migration you can measure almost everything — except the one thing that matters in the end: whether you really thought of everything. This story is about that gap. It is deliberately kept general — no clients, no providers, no point in time.

Situation

A large infrastructure was to be moved: multiple servers, databases, backups, plus a change of provider. Each individual piece was understood and manageable on its own. The task wasn't to invent anything new, but to bring what existed to a new place completely and intact.

Initial assumptions

The obvious assumption was that a migration is a technical task: you copy, switch over, check that it runs. Every step was known, none particularly hard. Under that assumption, success seemed to be a matter of careful execution.

Problem

The real difficulty lay elsewhere. Moving a server wasn't hard — being sure you had captured all the servers, all the databases, all the backups, all the silent dependencies was. Over time, an organically grown infrastructure accumulates things nobody fully keeps in their head anymore: a rarely used service, a backup in an unexpected location, a dependency that only becomes visible once a month. The question wasn't "does it run in the new place?" but "did everything really come along?" — and that question can't be answered just by moving.

Root cause

The root cause of this difficulty was that completeness can't be proven by looking at what's there — you only see what you know, not what you've forgotten. A migration is therefore, by its very nature, not a technical problem but a trust problem: success depends on whether you can truly believe the statement "everything is there." And belief without evidence is hope.

Decision

The decision was not to hope for trust but to establish it — to design the migration so that its completeness could be proven rather than asserted. The focus wasn't the switchover itself, but the ability to say with certainty at the end: nothing is missing.

Implementation

That meant making the old and new states comparable and keeping the move reversible. Before anything was shut down, we verified that the new matched the old — inventory against inventory, not spot check against gut feeling. The old stayed reachable until the new had demonstrably proven itself, so that a mistake allowed a way back instead of an outage. Every step was built so that its success was provable, not merely probable.

Trade-offs

This thoroughness costs time and patience: proving is slower than moving, and keeping the old state running in parallel ties up resources you seemingly no longer need. The price buys insurance against the one forgotten piece that only surfaces weeks later, long after the old has been shut down. We would only handle it differently for a small, manageable environment whose completeness one person can still reliably oversee — there, the full effort of proof is overkill.

What we learned

A migration is a trust problem before it is a technical one. Moving is something you can master; the certainty of having forgotten nothing has to be actively earned. That is why the central work isn't shifting things but proving — making the new state verifiable against the old and keeping the way back open until the proof is in. Anyone who just moves and hopes hasn't done the actual job.

How this changed Batunet

Since then, we treat migrations first as a question of trust: how do we prove that everything came along? We build in the proof of completeness instead of trusting it at the end, and keep the old state reachable until the new one has demonstrably proven itself. "Everything should be there" has become "we can show that everything is there."

Further reading

• Guide: Zero-downtime database migrations — the same discipline of reversibility and verification, applied to databases.
• Guide: Observability is architecture — why you can only judge what you make measurable.
• Guide: Software that still runs in ten years — why operability determines lifespan.
• Service: Cloud software and software maintenance — building infrastructure and operating it reliably.

It is grounded in the Batunet Engineering Method: design for failure, work in reversible steps, prove completeness instead of hoping for it.

In a migration, the hardest question isn't whether the new runs, but whether you can believe the sentence "everything is there." Trust comes from evidence, not from hope.