skip to content

A team holds a documented plan to leave its cloud platform but has never exercised it, so how would you test whether it is real?

level: seniorimportance: nice to knowfreq 33%

answer

  1. a plan nobody ran is a document
  2. rehearse one real service, real data
  3. follow the written steps, not memory
  4. the output is a clock and a defect list
  5. both artefacts expire, so repeat

basics

~20 s

Rehearse a slice of it end to end: stand one real service up on the second platform from its written description, load a realistic copy of its data, put real traffic on it, and measure the clock. The output is an elapsed time and a defect list, both of which expire.

solid answer

~50 s

A plan nobody has run is a document, not a capability. Test it by rehearsing a slice small enough to finish and real enough to count: one service that matters, provisioned on the second platform from the plan's own instructions, with a realistic volume of data actually copied and real or shadowed traffic served. Then measure two things — **how long it took** and **what the plan did not mention**. The defects are always the same families: an undocumented dependency, an identity or credential path nobody could reproduce, a scheduled job no one owned, and one person who turned out to be the only one who knew a step. The rehearsal produces a dated elapsed time and a defect list; both go stale as the estate changes, so the exercise has to repeat on a cadence rather than being ticked off once.

go deeper

for a junior

Remember the basic test: a plan that has never been executed is a document, not a capability. Ask when it was last run and who ran it before assuming it works.

for a middle

Explain how a rehearsal is scoped — one real stateful service, realistic data volume, the plan's own written steps followed literally — and what the exercise produces: a measured elapsed time and a list of defects.

for a senior

Show that you know which defects the exercise finds: undocumented dependencies, an identity path nobody could reproduce, scheduled work left out, and a step only one person knows. Then say how the result is kept current.

for a principal

Make the plan auditable and repeatable: a named owner, a cadence tied to architecture change, a dependency inventory maintained with the estate, and an explicit trigger and decision-maker so the plan can actually be invoked.

## Why an unexercised plan is not a posture The cheapest multi-cloud posture is a single live platform plus a written way to leave it. Its whole value rests on an assumption nobody has checked: that the document describes the estate as it is today, and that following it would actually produce a working system. Estates change weekly. Documents do not. The gap grows silently and is discovered at the worst possible moment. So the question is not "is the plan well written" but "what evidence exists that it works". Only one kind of evidence counts: somebody ran it. ## Designing a rehearsal that produces evidence A rehearsal is useful when it is small enough to complete and honest enough to count. Four design choices decide that: 1. **Pick one service that genuinely matters** — something with state, dependencies and a real consumer. A rehearsal on a stateless side service proves almost nothing, because the parts that break in a real exit are the data and the dependencies. 2. **Use realistic data volume.** Copy time is not linear with anything you can guess, and a rehearsal against a token dataset hides the cost that dominates the real move. The financial cost of that copy is a separate exercise; the rehearsal's job is to establish that it is possible and how long it takes. 3. **Follow the plan's own instructions**, not the knowledge in the head of whoever wrote them. Every step the rehearsers have to invent is a defect in the plan and should be logged as one. 4. **Serve real traffic**, even a small shadowed share. Correctness under load reveals what a successful deploy does not: timeouts, unnoticed dependencies, and behaviour that differed between the two platforms. ## What a rehearsal reliably finds The defect families barely vary between organisations: - **Undocumented dependencies** — a shared service, an internal endpoint, a certificate, an allowlist entry that only existed because someone added it years ago. - **Identity and credential paths** that cannot be reproduced. On the live platform the workload receives its identity from the platform itself; on the target it needs an equivalent path, and that is often the step nobody had written down. - **Scheduled and background work** — the batch job, the retention sweep, the reconciliation run — routinely missing from a plan that describes only the request-serving path. - **Single points of human knowledge.** One engineer knows the step. The rehearsal is the cheapest way to discover that before the person is on holiday. - **Optimistic timelines.** The plan says a weekend; the rehearsal of one service says the copy alone exceeded it. ## Reading the result honestly A rehearsal produces two artefacts, and both carry a date: | Artefact | What it means | How it expires | |---|---|---| | **Measured elapsed time** for the rehearsed slice | the only defensible input to any claim about how long an exit takes | invalidated by data growth and by new dependencies | | **Defect list** from following the plan | the specific work needed to make the plan true | grows again as the estate changes after the exercise | Two interpretation errors are common. The first is treating a successful rehearsal as proof that the whole move is affordable — a rehearsal establishes feasibility and duration for one slice, while what the full move would cost is a separate calculation. The second is treating the result as permanent. A rehearsal is a measurement of a moving system; a two-year-old result describes an estate that no longer exists. ## Signals the plan was never real Even before a rehearsal, some plans announce themselves: - no named owner, or an owner who has left; - no date, or a date older than the last significant architecture change; - no data volumes, so no basis for any timeline; - no dependency inventory, only the services the authors happened to remember; - a stated timeline nobody can trace to a measurement; - no trigger and no named decision-maker — a plan with no answer to *who decides we are leaving, and on what signal* will not be invoked in time even if it is technically correct. ## What good looks like A plan that has been rehearsed within the last cycle, owned by a named team, carrying a measured elapsed time for at least one real service, a dependency inventory kept alongside the estate, and a decision trigger. That is a genuine posture. Anything else is an intention, and intentions do not survive contact with an outage or a renewal negotiation.

  • Why rehearse with realistic data volume rather than a small sample?
    Because the copy is usually the longest step and its duration cannot be extrapolated confidently from a token dataset — throughput limits, throttling and restart behaviour only appear at size. A rehearsal on a sample validates the sequence of steps but gives no defensible number for how long the real move takes, which is the main figure people want from it.
  • What does a rehearsal not tell you?
    What the full move would cost, and whether the organisation would actually decide to make it. A rehearsal establishes feasibility and a duration for one slice. Pricing the whole migration is a separate exercise, and the decision itself needs a named trigger and a named decision-maker written into the plan, or it will not be taken in time.
  • How often should the exercise repeat?
    On a cadence tied to change rather than to the calendar alone — at minimum annually, and again after any significant architecture change, since both the elapsed time and the defect list describe the estate as it was on the day. A plan whose last rehearsal predates the current architecture has reverted to being a document.

saying these in an interview costs you the question

  • Judging the plan by how well written it is
  • Rehearsing a stateless side service and calling it evidence
  • Rehearsing from memory instead of the plan's written steps
  • Treating a rehearsal as proof the full move is affordable
  • Recording a successful exercise as permanently valid
  • Holding a plan with no trigger and no named decision-maker