“We can migrate later” describes a possibility. It does not describe an exit path.

A credible exit needs a trigger, an owner, intermediate states, completion evidence, and a visible cost. Without those elements, a replaceable component can become a durable organizational commitment after consumers, data, controls, and operating procedures form around it.

Public engineering guidance makes this constraint concrete.

A migration is a sequence, not a switch

In an AWS Builder Center article on rollback safety, Sandeep Pokkunuri describes why distributed deployments need compatibility across versions. A rolling deployment creates a period when old and new software run together. They may exchange remote procedure calls or read shared persistent state. Either version can fail if it cannot understand what the other writes.

The article's two-phase example separates preparation from activation. The preparation version learns to read both the old and new data formats while continuing to write the old format. The activation version starts writing the new format only after the fleet can read it.

Each immediate transition can roll back safely. The complete change cannot always return to the original state. Once the new format is written, the original software cannot read it. The old read path must remain until every object has been backfilled. That may require extra tooling and a period when both formats remain part of the operating system.

The important architecture is not only the new component. It is the compatibility window, the backfill, the evidence that backfill is complete, and the decision to remove the old reader.

Durable state changes the exit

The Kubernetes deprecation policy shows the same issue at API and storage boundaries.

The policy requires supported API representations to round-trip across versions without losing information, subject to a stated resource exception. It also prevents the preferred and storage versions from advancing until a release supports both the new and previous versions. Users must be able to upgrade and then roll back to the previous release unless they used features available only in the newer one.

Persisted state creates a longer obligation. An old API endpoint may stop being served while the API server still needs to decode or convert data stored in that version. Kubernetes also emits warnings, audit data, and a metric for deprecated API requests. Those signals help identify use that remains before an interface is removed.

This is one project's policy, not a template every organization should copy. It demonstrates a general constraint: removing the visible old path and completing the underlying migration are different events.

Rollout signals belong in the path

Google's Site Reliability Engineering workbook defines a canary as a partial, time-limited deployment whose evaluation determines whether rollout should continue. The process needs a bounded population, an evaluation method, and a connection between that evaluation and release control.

In its worked example, a metric comparison between the release candidate and control tells the system whether to continue, pause, or roll back. The chapter also notes that without a rollback option, teams may have to patch forward during an outage, which can extend user impact.

A rollback control without a decision signal is incomplete. Someone still needs to decide which measure matters, what threshold stops exposure, and who can act on it.

Write the leaving sequence before adoption

For a consequential shared capability, record five things before calling it replaceable:

  1. Trigger. Which observed condition would force a change in direction? Name the signal and the decision threshold.
  2. Owner. Who can start the exit, fund the work, coordinate affected consumers, and decide when the old path can retire?
  3. Intermediate states. Which versions, interfaces, data representations, and operating procedures must coexist? State what can and cannot roll back at each stage.
  4. Completion evidence. What proves that consumers and durable state have moved? A deployment completing is not evidence that every dependency has left the old path.
  5. Leaving cost. Estimate the capacity required for compatibility, migration tooling, backfill, validation, dual operation, consumer work, and retirement. Keep uncertainty visible instead of turning the estimate into a promise.

These fields expose the actual commitment. They also make the business cost legible. A path that requires several teams to synchronize roadmaps, operate two systems, and preserve old data readers consumes capacity even when the replacement software is easy to build.

Keep the requirement proportional

Not every choice needs a detailed migration program. A local, reversible, contained change may need only a recoverable artifact, a tested rollback action, and a short observation window.

The exit record becomes more important as adoption, durable state, external consumers, or blast radius grows. Its purpose is to reveal the work already implied by the decision, not to add ceremony to cheap experiments.

Ask a team to write the plausible leaving sequence. If the sequence has no owner, no observable trigger, or no safe intermediate state, the decision is more durable than its label suggests. Reduce the first commitment or improve the boundary before adoption makes the missing exit expensive.

Sources

The exit-path record is an application of Reversibility and Blast Radius to the cited public engineering sources. This field note does not report an employer implementation, customer migration, advisory delivery, or measured commercial result.