What Breaks at the Next Transition

Overview

The previous topic located the organisation in a regime. This one asks a harder question: what is the observed rate of change, and what does that rate make true?

The reason this matters more than it sounds: architectural decisions routinely depend on something finishing. A dependency is tolerated because it is temporary, a workaround is accepted because the real fix is coming, a boundary is drawn in a place that only makes sense until a migration completes. If the thing does not finish on the assumed schedule, every decision that leaned on it quietly becomes a different decision.

Measure the rate, not the intention

The single most useful thing you can do with a long-running structural programme is divide.

Not read the roadmap, not ask how it is going — take the progress actually achieved and the time actually elapsed, and extrapolate. The result is almost always much worse than the stated plan, and the gap is informative rather than accusatory: roadmaps are built from estimates of the work, and observed rates include everything the estimates left out.

Then adjust the extrapolation in the direction it always needs adjusting. The remaining work in a migration is harder than the work already done, for a structural reason: teams extract the tractable slices first. What is left at any point is what was deferred because it was entangled, and that is disproportionately the shared data model and whatever the oldest code touches everywhere.

So a linear extrapolation is the optimistic case, not the pessimistic one. Stating it that way is what makes the number credible to the people who built the roadmap.

What a slipping dependency does to a design

graph TD
  A["A decision tolerates a<br/>dependency as <b>temporary</b>"] --> B{"Does the thing it<br/>waits for finish?"}
  B -->|"On schedule"| C["The trade was<br/>correct as recorded"]
  B -->|"Years late"| D["<b>A different decision</b><br/>the interim became<br/>the architecture"]

  classDef ev fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef q fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef good fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef bad fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A ev
  class B q
  class C good
  class D bad

The same decision, two outcomes, and nobody re-examines it when the schedule slips — because the slip happens to a different team’s programme.

The damage is subtle because the slip happens somewhere else. The migration’s schedule belongs to the migration’s owners; your decision belongs to you; and nobody holds the pair. A design that recorded “the dependency on the legacy system is acceptable because that system is being retired” is never revisited, because the sentence is still technically true. It is the word “soon” that quietly stopped being true, and it was probably never written down.

This is also the clearest practical argument for Module 9’s reversal conditions. A record that states what would have to become true for this to be revisited converts a slipping schedule from an invisible drift into a triggered review.

What to do about it

Re-derive the dependency’s lifetime and write the number down. Not a vibe about things taking longer — a figure with its arithmetic shown, which is what makes it survive contact with the people whose programme it describes.

Then ask the honest question: if this dependency lasts four more years instead of one, is the decision still right? Sometimes yes, and you have gained a defensible record. Sometimes no, and you have found a decision to supersede before it costs anything.

And say it in terms of trajectory, not blame. The migration is not behind because anyone is slow; it is behind because the estimate excluded the entangled remainder, which is a property of migrations rather than of teams.

Two years in, thirty-five per cent moved

The strangler migration is two years in, with about 35% of traffic now reaching the new services. No spare engineering capacity: the migration consumes it.

Divide. Thirty-five points over twenty-four months is about 1.46 points per month. The remaining sixty-five points, at the observed rate, is about forty-five months — nearly four more years.

Then adjust in the right direction. The slices already moved are the tractable ones. What remains is entangled with the 4 TB PostgreSQL database and the oldest parts of the 2016 Rails codebase — the shared data model that everything touches. So forty-five months is the optimistic projection, and the honest statement to leadership is “four or more years at the current rate, and the remainder is harder than the part that is done.”

Now the consequence for your own work. Module 3 drew the AI platform as two services reaching the monolith through its API and never its database, and Module 9 recorded the reasoning. The context section of that record described the monolith as the system of record during the migration. The word doing the quiet work there was “during”.

Four more years means the dependency is not interim; it is the architecture. Specific things change as a result:

• The API the action service depends on was never built for this load profile, and it has to be treated as a long-lived integration contract rather than a temporary bridge — versioned, monitored, and owned.
• Ivan Petrov’s informal veto over the monolith is a four-year fact of life, not a phase to be waited out. Module 8’s work on earning agreement is a standing requirement rather than a one-off.
• Any plan that sequences AI platform work after migration milestones is a plan that ships nothing for years.

This supersedes a record rather than editing one. The original decision was correct against the constraints as understood; the new record states the re-derived dependency lifetime, keeps the two-service split, and changes the integration contract’s status from temporary to permanent. That is the Module 9 discipline doing exactly the job it was introduced for — and it is the first finding to carry into the capstone.

Feeds the workbook

This re-derivation belongs in your legacy strategy and constrains your migration sequence. It should also produce at least one superseding record against your Module 9 ADR set.

Check your understanding

1. Take a long programme you know. Divide progress by elapsed time. What does the extrapolation say, and how does it compare to the plan?
2. Find a decision that tolerates a dependency because it is temporary. What happens to it if the dependency lasts four more years?
3. How would you state a slipping trajectory to the team that owns it without it reading as an accusation?

---

→ Scale and trajectory are properties of the company. The next lens is the kind of work it does. — Engagement types