LEARN. PRACTICE. GROW.1. Define an observable state
In a fictional fund-instruction service, the sponsor wants to retire an old platform while retaining intake, lookup and exception handling. Installing the new service does not describe all those capabilities. Represent the state through observable elements: where each group submits instructions, who holds the authoritative record, which formats are accepted, how history is retrieved and who responds outside normal hours. Connect those elements to the intended outcome. A team can finish installation while still relying on the legacy system for a required query. It can also list every function while nobody is ready to use one. The future state needs operating, adoption and responsibility conditions. Technical design is part of the explanation; it does not replace a description of how the service will be delivered.
2. Check intermediate states
Consider two formats, V1 and V2. The old sender produces only V1; the new sender produces only V2. The old receiver accepts only V1; a transition version accepts both; the final receiver accepts only V2. The new/new destination is compatible, but that does not establish that every installation order works. Migrating the sender first creates new/old and violates the acceptance rule. An allowed path is old/old, old/transition, new/transition and new/final. Write the matrix before debating phased change. Add actual consumer groups and conditions for each connection. In this example, upgrading the receiver to accept both formats does not automatically change the format senders produce. Compatibility is directional: producing, accepting and transforming are different capabilities.
3. Give temporary capabilities an exit condition
The transition version enables coexistence but creates its own cost and work. Define who maintains it, how it is monitored, which constraints it preserves and what evidence permits removal. If ten consumers were inventoried and nine migrated, a 90% rate does not establish that the tenth may lose service. A low-volume consumer may communicate only at month end. No requests for a week does not by itself establish confirmed retirement. In this exercise, exit requires every consumer in the validated inventory to have migrated or been formally retired, history to remain retrievable through the agreed path and the operational owner to accept the new coverage. These are explicit rules for this case. An actual project must identify its own conditions rather than inherit these numbers or assumptions. Also confirm the billing unit. In a different fictional contract, 900 units for each started four-week block, without proration, means 1,800 for five weeks: week five starts a second block. The result differs from the proportional contract in the final exercise because the contractual rule differs.
4. Define authority during coexistence
The design keeps the old and new platforms connected during transition. That does not answer who may commit an instruction. The fictional contract requires one authority to commit each external effect. A shadow comparison can inspect copies and differences, but should not commit movements in parallel merely to see whether results match. If both platforms may produce the effect, an additional decision about identity, coordination and recovery is needed. The analyst must expose that gap before recommending coexistence. Describe authority transfer: stop new intake at the origin, resolve in-flight work, confirm transfer state and then enable the destination under the agreed procedure. This is an example under those conditions, not a universal algorithm for interruption-free migration.
5. Locate the point where going back changes meaning
Before the destination accepts new work, returning to the old service may involve restoring routing and checking preserved state. After new instructions are accepted, restoring an earlier copy can erase information or leave external effects unmatched. A backup does not establish that reversal retains subsequent work. Separate technical reversal, data reconciliation and compensation of business actions. At each decision point, identify work that may exist, the source confirming it and who can authorize the next action. In the fictional case, simple return is authorized only before first destination intake. Afterward, strategy requires a recovery path with reconciliation. This distinction should not first appear during an incident: it affects path selection and the evidence needed to proceed.
6. Calculate how long an option remains available
The window ends at 02:00. The plan accepts duration bounds of 40 minutes to restore, 20 to validate and another ten of reserve, in that order without overlap. The latest start for this path is 00:50 because 70 minutes are needed before the deadline. Deciding at 00:55 no longer fits, even if installation finished. These values are accepted exercise assumptions, not production measurements. A 40-minute average would not itself establish a 40-minute recovery bound. Record each duration’s basis, dependencies and required decision time. An option exists only while its preconditions and required time remain available. Scheduling a meeting does not change that arithmetic.
7. Look for dependencies shared by alternatives
The team proposes the old environment as contingency for the new one. Both require the same identity service, which will change during the window. Testing recovery of the new server does not establish continuity when that shared dependency fails. Draw both options’ connections and identify the condition each handles. An alternative may protect against a bad installation without protecting against loss of the identity service. That does not make it useless; it bounds its contribution. Risk analysis should distinguish these events and avoid treating copies at different locations as demonstrated independence. Decide with owners whether strategy should separate the common change, add a validated contingency or accept exposure within defined authority. This case provides no probabilities, so it cannot support a combined-availability calculation.
8. Exercise: recommend a conditional path
Prepare a recommendation before reading the solution. There are three sender groups: A and B can change on Saturday; C changes only the following month. All use V1 today. The transition receiver accepts V1 and V2; the final one accepts only V2. The requirement retains service for all three groups. The bridge costs 300 units per week, billed proportionally; in this exercise it remains for exactly four weeks. The proposal removes it on Saturday to save cost. Solution: installing the transition receiver allows A and B to migrate while C retains V1; removing the bridge before C migrates violates compatibility. Four weeks add 1,200 units, which belong in the comparison. Deferring everything can be an alternative, but requires comparing dates, risks and benefits not quantified here. The recommendation should name an exit condition, owner and evidence without inventing approval or a globally optimal option.
Exercise files
Original Python 3.10+ exercise without dependencies: compatibility, block costs, working calendar and international sessions. Includes editable data, instructions and worked results.
A compatible final state can be reached through a sequence that interrupts a consumer. A state matrix exposes that intermediate incompatibility.
Common pitfalls
Checking only the final destination; counting consumers instead of checking dependencies; executing effects during shadow comparison; treating backup as complete reversal; using an average as a bound; assuming independence between environments sharing services.
Related topics: Transition requirements and acceptance · Decision and evidence planning
An executable strategy needs allowed intermediate states, state-change criteria and recovery options whose feasibility remains supportable when the decision is made.
References
- Analyze Current State · Public task card v2.0, copyright2025
- Define Change Strategy · Public task card v2.0, copyright2025
- Assess Risks · Public task card v2.0, copyright2025
- Plan Business Analysis Approach · Public task card v2.0, copyright2025