Skip to content

Strategic Transition Map

Planning artifact — instantiates Three-Horizon Transition Mapping

A planning artifact that wires horizon roles into a dependency-ordered sequence of dated, owned commitments — migrate this before retiring that.

The Strategic Transition Map is the document that turns horizon roles into an ordered plan. Its defining move is the dependency edge: it records not just what must happen but what must happen before what — you cannot retire the legacy billing system until the new one handles every edge case; you cannot decommission the old data center until workloads have migrated. It lays those preserve / migrate / retire commitments along a timeline, attaches an owner to each, and makes the critical path of the transition explicit so the system neither exits the present too early nor arrives at the future too late. It is a persistent artifact, not an event: a living plan you consult and update, distinct from the picture that inspired it and the meeting that argued it out.

Example

A retail bank is replacing its 1980s mainframe core banking system. The ambition is clear and the target platform is chosen, but the danger is sequencing: switch off the old ledger before the new one is proven and you lose customers' money; wait for perfect confidence and you pay for two systems forever. The Strategic Transition Map makes the pathway explicit. It plots the current core (Horizon One, preserve-then-retire), the transitional services that sit in front of it — a "strangler" API layer intercepting traffic, dual-write reconciliation (Horizon Two, migrate) — and the new cloud-native platform (Horizon Three, instantiate).

The value is in the edges and owners. Dual-write reconciliation must run clean for two full statement cycles before any account is cut over. The old core cannot be retired until the last product line — mortgages, the hardest — is migrated, owned by the lending platform lead. Cannibalize the legacy reporting warehouse only after the new one is certified. Each commitment has a date window, a predecessor, and a name. The map does not decide whether the re-platform is wise or run the workshop where teams fought over it; it is the artifact that keeps a multi-year migration from cutting a wire in the wrong order.

How it works

  • Take the classified horizon roles as input. Start from which initiatives are H1/H2/H3 — the map connects roles; it does not assign them.
  • Draw the dependency graph. For each commitment, record its predecessors: what must be true or done first. This is the map's core content.
  • Attach timing windows and owners. Give each commitment a date range and a single accountable name, so the pathway is schedulable and answerable.
  • Encode the continuity commitments. Mark each current-system element as preserve, migrate, retire, or cannibalize, positioned so retirement never precedes its replacement's readiness.
  • Version it. Treat the map as living; update dependencies and dates as the transition reveals reality.

Tuning parameters

  • Dependency granularity — coarse milestones versus fine task-level edges. Fine edges catch dangerous orderings but become a project plan no one maintains; coarse ones stay legible but hide traps.
  • Time-window tightness — hard dates versus ranges. Hard dates coordinate but shatter on the first slip; ranges absorb reality but can drift into never.
  • Buffer between migrate and retire — how much proven-parallel-running is required before an old element is cut. Generous buffers are safe but expensive (paying for both systems); thin buffers are cheap but risk a premature cut.
  • Ownership resolution — one accountable owner per commitment versus shared. Single owners answer clearly; shared ownership spreads load but blurs accountability.

When it helps, and when it misleads

Its strength is preventing the two sequencing disasters of any transition — exiting the present before the future is ready, and clinging to the present until the future is too late — by making the order and its dependencies explicit and owned. The staged, intercept-then-replace pattern it encodes is the strangler-fig approach to replacing a system incrementally rather than in one risky cutover.[1]

Its failure mode is false linearity: a crisp Gantt-like artifact implies a smooth, predictable march when real transitions stall, fork, and backtrack, and a map treated as a fixed contract becomes a lie the moment reality diverges. It can also calcify — a beautifully detailed plan that no one updates is worse than a rough one that stays current. The guarding discipline is to version the map against reality and to hold the dependencies as the load-bearing content, letting dates flex around them. The map orders the work; deciding whether a commitment still makes sense is a job for the review and the workshop it feeds.

How it implements the components

Strategic Transition Map realizes the sequencing-and-commitment layer of the archetype:

  • timing_and_dependency_pathway — it is the dependency-ordered, dated, owned pathway itself: what must happen before what, and when.
  • continuity_and_cannibalization_rule — it positions each preserve / migrate / retire / cannibalize commitment on that pathway so continuity is never broken out of order.

As a document it does not run the live human alignment that produces buy-in and settles horizon tensions (stakeholder_expectation_bridge, tension_review_loop — that's Strategic Transition Workshop).

Editorial Notes

Form Classification

Form family: Representation, Specification & Plan

Rationale: Strategic Transition Map operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a planning artifact that wires horizon roles into a dependency-ordered sequence of dated, owned commitments — migrate this before retiring that.

Independent corroboration: The frozen evidence defines Strategic Transition Map as 'A planning artifact that wires horizon roles into a dependency-ordered sequence of dated, owned commitments — migrate this before retiring that', so its operative form is Representation, Specification & Plan.

Nearest alternative: Interface, Display & Cue — Strategic Transition Map includes features of a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.

Review outcome: Independent reviewer agreement; medium confidence.

Origin Attribution

Primary origin: Organizational & Management Science

Origin pattern: Convergent development

Present-day reach: Universal

Rationale: Dated dependency-ordered commitments form a strategy transition roadmap.

Related originating lineages:

  • Futurism & Strategic Foresight — Horizon roles organize transition.
  • Operations Research — Precedence constrains sequence.
  • Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: a planning artifact that wires horizon roles into a dependency-ordered sequence of dated, owned commitments — migrate this before retiring that.

Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; medium confidence.

Notes

The Strategic Transition Map and the Strategic Transition Workshop are the archetype's most confusable pair, and the distinction is simple: this is the artifact, that is the event. The map is the durable dependency-and-commitment plan you can hand to a new hire; the workshop is the live session where people classify, argue tensions, and align expectations. The workshop typically produces and revises the map; the map outlives any single workshop.

References

[1] Fowler, M. "Original Strangler Fig Application". martinfowler.com (2004). Defines the strangler-fig approach as gradually moving functionality to a new system around the old instead of relying on a single cutover. registry