Most technical decisions are about as expensive to change later as they were to make. You pick a library, it turns out badly, and you swap it. That costs a sprint, not a programme.
A small set of decisions don’t work that way. They cost almost nothing at design time and a great deal to change afterwards, sometimes more than the original build. I call this retrofit cost asymmetry, and the annoying part is that these are not the decisions that feel important while you’re making them. They’re quick, they look reversible, and they get made by whoever happens to be setting things up that week.
What they have in common
When I list the decisions that hurt to retrofit, they all share one property:
The decision becomes a dependency of everything built after it.
That property is what makes the class predictable, instead of a list of war stories to memorise.
| Decision | Why it sticks |
|---|---|
| IP address plan (CIDR ranges) | Every peering, hybrid link and future acquisition inherits it. Overlapping or too-small ranges block growth, and fixing them means re-addressing live systems. |
| Account / subscription structure | It’s the isolation boundary everything else is organised inside. Moving it moves everything. |
| Identity model | Every access decision, audit trail and integration is wired to it. |
| What data you collect, and why | Once collected, data spreads into stores, backups, lakes, models and third parties. There’s no “un-collect” operation, only deletion, and only where you can find it. |
| Whether policy enforcement is on the golden path | Adding it later means reconciling an estate that grew up without it, one exception at a time. |
| Where a secret has been | The purest case. Git history is immutable, so the fix isn’t “remove the secret”. It’s rotating the credential and accepting that the old value is out there forever. |
The last one is the one people underestimate most. “We removed the secret” is not remediation while the history survives.
The common failure isn’t ignorance of any one row. It’s that all of these get decided early, informally, when the project is small and nothing feels like an architecture decision yet.
What I do about it
Name the irreversibles, early and in writing. At the start of a programme, write a short list (address plan, account structure, identity, data scope, policy on the golden path) and give each one a decision record. These are exactly the decisions most likely to be made without an ADR. It takes about half a day, and I don’t know a better use of half a day.
Spend disproportionate time on them. An extra week on the address plan is cheap next to re-addressing a live estate.
Prefer the reversible option when the cost is similar. A bigger CIDR block, a slightly finer account boundary, collecting less data. Optionality is worth paying a small premium for here, and almost nowhere else.
The trap on the other side
This is easy to abuse as an argument for big design up front. Every architect has a favourite decision they’d like to front-load. Over-building a foundation for an estate that doesn’t exist yet is its own well-known anti-pattern.
So use a simple test for whether something belongs on the list:
If we change this in 18 months, does it cost about the same as deciding it now, or an order of magnitude more?
If it costs about the same, it’s not on the list. Keep the list short: front-load the few decisions that really are asymmetric, and keep everything else iterative.
And if you inherit an estate where nobody front-loaded anything, it’s not doomed. It has a known, expensive, plannable remediation. Naming that cost honestly is more useful than lamenting the sequencing, and it’s often the real substance of a modernisation business case.
This also connects to the routed-around control. Enforcement added after the fact runs into an estate full of legitimate non-conforming work, which is exactly what produces bypasses. Retrofits and over-restriction together are how shadow estates form.