Skip to content

Consolidation Migration Plan

Migration workflow — instantiates Internal Capacity Deepening

Stages the move of users, data, processes, contracts, staffing, and tooling out of dispersed arrangements into one shared capability — and retires what's left behind so the savings actually land.

Deciding to pool scattered capacity is the easy part; moving onto the shared capability without dropping service, and actually shutting the old arrangements down, is where consolidations succeed or quietly fail. Consolidation Migration Plan is the sequenced execution workflow for that move: it orders the waves in which users, data, processes, contracts, and tooling shift from many dispersed instances into one, keeps a ledger of the transition costs that never appear on the headline business case, and enforces a rule that decommissions each old arrangement once its load runs clean on the shared capability. Its defining discipline is that a migration is not done when things are moved — it is done when the dispersed capacity is retired, because a consolidation that leaves the old systems running pays for both.

Example

A university has six departmental compute clusters and wants one central HPC service. The plan sequences the move rather than flipping a switch: a willing pilot department first, migrating its data and job scripts and cutting its scheduler over to the central service, with the old cluster kept warm as a fallback. A transition-cost account books what the headline "consolidation saves money" case omitted — the term of parallel running, retraining researchers on the new scheduler, and a temporary dip in throughput while jobs are re-tuned. A retirement rule sets the trigger: a department's rack is decommissioned only after thirty days of its jobs running clean centrally. Wave by wave the six clusters empty and go dark; the savings arrive only as each is actually switched off, not when its users are merely pointed elsewhere.

How it works

  • Sequence in waves. Users, data, and tooling move in ordered increments — pilot first, riskiest last — so service stays continuous and each wave's lessons feed the next.
  • Keep a transition ledger. Parallel-run time, retraining, data cleanup, and the throughput dip are booked explicitly, because these are the costs that hide off the consolidation's headline case.
  • Retire on a trigger. Each dispersed arrangement is decommissioned only once its load runs clean on the shared capability — and it is decommissioned, so the organization stops paying for both.

Tuning parameters

  • Wave size and order — pilot-first and incremental, or big-bang. Small waves de-risk and teach but stretch the migration and its parallel-run cost; big-bang is fast and brittle.
  • Parallel-run duration — how long old and new run side by side. Longer is safer but doubles cost for that window; shorter banks savings sooner at higher cutover risk.
  • Cutover style — phased trickle or hard flip per unit. Phased limits blast radius; a flip is cleaner when rollback is cheap.
  • Retirement-trigger strictness — how clean, for how long, before the old arrangement is shut. Loose triggers strand duplicate cost; strict ones delay the savings.
  • Rollback provision — how far back a failed wave can be reversed, and for how long that safety net is kept.

When it helps, and when it misleads

Its strength is realizing the pooling gains while keeping service up, and forcing two things into the open that consolidations routinely ignore: the real transition cost, and the discipline of actually turning the old capacity off.

Its failure modes are well worn. A big-bang cutover underestimates the transition — the friction of migration is exactly the part that never shows up in a plan — and stalls mid-move. Teams forget to decommission, so the promised savings never materialize while both estates run. And consolidation trades dispersion's built-in redundancy for a single point of failure. The discipline is incremental cutover that strangles the old system gradually rather than replacing it in one leap,[1] a retirement rule that is enforced, and a resilience check before the last fallback is removed.

How it implements the components

  • migration_pathway — sequences the waves that move users, data, and tooling into the shared capability without dropping service.
  • transition_cost_account — books the parallel-run, retraining, and throughput-dip costs that never appear on the headline consolidation case.
  • retirement_or_consolidation_rule — the trigger that decommissions each dispersed arrangement once its load runs clean centrally, so the savings actually land.

It does not appraise whether to consolidate in the first place (capacity_yield_model, fixed_cost_map) — that's Capacity Investment Analysis; nor enforce the post-consolidation resilience invariant (resilience_and_redundancy_guardrail) — that's checked at the Footprint-Expansion Decision Gate.

Notes

Consolidation deliberately removes duplicated capacity — which also removes the redundancy that dispersion provided for free. A plan that hits its efficiency target while quietly creating a single point of failure has not actually succeeded; it should be paired with the resilience-and-redundancy invariant enforced at the decision gate, and the last fallback kept until that invariant is satisfied on the shared capability.

References

[1] The strangler fig pattern — migrate incrementally, routing slices of load onto the new system and shrinking the old one until it can be removed, rather than a single big-bang replacement. Named for the fig that grows around a host tree and gradually supplants it. ↩