Capability Freeze Window

During coexistence, any capability live on both systems takes every change twice - and not merely twice. It must also be proven equivalent, because the parallel comparison has to keep passing. The equivalence proof is frequently larger than either implementation.

A capability freeze window is the business agreeing, for a named capability and a stated period, that no new functionality will be requested of it while it is mid-migration. It is the only lever that removes the dominating coexistence cost rather than reducing it, and it is granted by the business rather than earned by engineering.

The word "capability" is load-bearing. An estate-wide freeze will be broken inside a quarter and the plan will have assumed it held. A freeze on one capability for eight weeks, with a named person who can grant an exception at a stated cost, survives.

Why it matters

In a typical 18-month coexistence, the retained legacy run cost is large but nearly certain - licences and infrastructure do not taper until decommissioning. Duplicate change is the term that can be wrong by a factor of three, because it depends on business behaviour nobody controls.

The arithmetic for a mid-sized programme: 9 dual-live capabilities at roughly 20% of an engineer each over 18 months is about £0.3M at a £110k loaded rate, and 20% is the optimistic reading. For a capability receiving significant change, the realistic multiplier is nearer 1.8 than 1.2 once equivalence work is counted. Engineering the comparison tooling harder might save 30% of a smaller line; a freeze removes close to 100% of this one for its duration.

The second effect is schedule. Duplicate change extends the coexistence, which increases the duplicate change. A freeze breaks that loop, which is why it shortens the period as well as cheapening it.

Implementation patterns

• Negotiate per capability, with dates. "Claims intake is frozen from 3 March to 28 April." Scope and end date are what make it acceptable to the business.
• Name the exception holder and the price. One accountable person, and an agreed statement of what an exception costs - typically two to three times the normal estimate, plus a comparison re-baseline.
• Sequence so the freeze window and the migration window are the same thing. A freeze that starts before the migration is ready wastes goodwill.
• Publish what is frozen where the business looks, not in the programme plan. A roadmap page the product team reads prevents most of the conflict.
• Exclude mandated change explicitly. Statutory and regulatory changes are not negotiable, so either plan the capability's migration either side of the mandatory deadline, or accept and budget the double implementation for that one change.
• Keep defect fixes in scope. A freeze on fixes is not credible and will be ignored, which destroys the whole agreement.

Industry example

Public-sector programmes show what happens without one. The US Government Accountability Office reported that the IRS, replacing a 60-year-old Individual Master File through the CADE 2 programme begun in 2009, revised cost, schedule and scope goals seven times between 2016 and 2019 and slipped a key milestone nine years, while continuing to deliver every annual filing season on the legacy system. The filing season is a mandated change that cannot be frozen, and the 2030 full-retirement date set in 2021 reflects two decades of that constraint compounding.

Failure scenarios

• The blanket freeze. Declared across the estate for 18 months, broken in week nine by a commercially important request, after which no freeze is believed again.
• Freeze without an exception path. Teams route around it: the change is implemented as a configuration tweak, a report, or a separate small service, and the duplicate-change cost reappears in a less visible place.
• Freeze with no end date. The business stops planning for the capability altogether and starts building a shadow alternative.
• Frozen capability, unfrozen dependency. The capability is frozen and an upstream service changes its schema, so both implementations change anyway.
• Freeze announced by engineering. Without a business sponsor it is a request, not an agreement, and it will be overruled by the first revenue conversation.

Trade-offs

The real cost of a freeze is optionality, and it is paid by whoever owns the capability's roadmap. The real cost of no freeze is paid by the programme, later, which is why the default is no freeze.

When not to use it

Do not seek a freeze where the migration window is long. Beyond roughly three months, the business will not hold it and should not be asked to; shorten the window instead by migrating a smaller slice.

Do not freeze a capability under active competitive pressure - a checkout flow during a pricing war, a product being launched. Move that capability to the end of the sequence and migrate something quiet first.

And where coexistence exists only to de-risk a read path, with the new system not yet authoritative for anything, there is nothing to freeze: changes land once, in the legacy system, and the new path follows.

Interview question

Q: You are 11 months into an 18-month coexistence and the programme is over budget. Engineering proposes optimising the reconciliation tooling. What would you propose instead, and how would you get it agreed?

What a strong answer covers: identifying duplicate change as the dominating term and showing the arithmetic · proposing per-capability freeze windows rather than an estate-wide one · naming the sponsor, the dates, the exception holder and the exception price · excluding mandated change and defect fixes · re-sequencing so quiet capabilities migrate during periods of commercial pressure elsewhere · and the honest cost - the roadmap owner loses optionality, which is a business trade, not an engineering one.

Quick check

Quiz: Which coexistence cost does a feature freeze remove, and why can engineering not remove it instead? Duplicate change - every dual-live capability takes each change twice and must be proven equivalent; tooling improvements reduce a smaller line by about a third, while a freeze removes almost all of this one.

Flashcard: Why must a migration freeze be per capability and time-boxed rather than estate-wide? - An estate-wide freeze will be broken within a quarter while the plan assumes it held; a named capability with dates, a sponsor and a priced exception path survives contact with the business.