Capstone Part 3 — The Wave Plan

Part 1 decided what moves. Part 2 built the place it moves to. This part decides in what order, in whose hands, and on which weekend — and that is where most migration plans quietly stop being plans. Anybody can list four waves. The craft is in the three checks that come after the list: does any wave move a system before something it depends on; does the work actually fit the people you have, once one of them leaves; and does it fit a calendar with two blackout windows, a licence renewal, and a colo contract that ends on 31 March whether you are ready or not. By the end of this page you will have a wave plan, a nine-month calendar, a risk register with rollback triggers, and — the part that matters most at 4 p.m. on a bad Tuesday — a written, date-stamped answer to “what do we cut?”

What this part assumes, and what it produces

☺ Like you’re 10: You need the list of things and the map of the new house. If you skipped those pages, everything you need is restated right here.

This page is deliberately self-contained. If you have done Part 1 and Part 2, use your own answers and treat the tables below as a cross-check. If you have not, use the tables below as given and start here — nothing later depends on you having produced the earlier artifacts yourself.

What you produce: three artifacts and one list. The wave plan, the nine-month calendar and the risk register are the artifacts a steering committee reads. The descope ladder is the list you will actually use.

The estate, restated — only what a wave plan needs

☺ Like you’re 10: Here are the boxes, where they sit today, and the one awkward fact about each that decides which weekend it moves.

Brambleside Veterinary Group — 22 small-animal clinics plus one 24-hour emergency hospital, one country, about 600 staff. It acquired Ashcombe Vets (3 clinics) in 2023 and never integrated it. Everything below is invented for this exercise.

Two buildings, one deadline — and they are not the same deadline

“Fort Rusty” is not one place. It is a converted server room at the flagship clinic and eight racks in a colo 40 km away, and only one of those has a contract that ends. This distinction does more work in a wave plan than anything else on the page, so establish it first:

Read that table again and notice what it just did to your plan. Eleven things sit under the hard deadline; ten of them move and one of them dies. Everything else — the three retained systems and the two Ashcombe systems — is schedulable at your convenience, which makes them the first things you sacrifice when the calendar tightens. A wave plan that treats all sixteen systems as equally urgent is a wave plan that will run out of March.

The sixteen systems, their R, and the fact that decides their wave

The R column is Part 1’s model answer. If yours differs and you can defend it, use yours — the checks that follow work identically.

The count you carry through the rest of this page: eleven systems move. Five are parked — one Retire (BI-Reports) and four Retain (BackupVault, AD-DC, PrintSrv, Ashcombe PIMS). Every check below is run against those eleven.

The dependencies that constrain order

Eleven edges. Everything authenticates against AD, so that edge is drawn once rather than sixteen times.

The constraints you cannot move

The people, in the only unit that matters

Six names is not six people’s worth of work. Convert to full-time equivalents before you plan anything:

Wave 0 — the wave that isn’t a wave

☺ Like you’re 10: Before you carry anything, you build the new rooms, run the wiring, and post the letters that take other people six weeks to answer.

Wave Planning calls it “foundation first”; the journey calls it Mobilize. Either way, Wave 0 moves nothing. It builds the landing zone from Part 2 — account topology, regions, the non-overlapping address plan, hybrid connectivity, identity, and the four guardrails — and it starts every clock you do not control.

That second job is the one teams skip, and it is the one that decides whether your plan holds. Three items in Wave 0 have lead times measured in other organisations’ working weeks:

Building the four waves

☺ Like you’re 10: Easy things first to practise, awkward things next while there’s still time to be surprised, and the thing the whole business runs on last — but not so last that there’s no weekend left.

You are sorting eleven systems into four batches. The rules you are sorting under, in priority order:

1. Dependencies before dependents, or an explicitly accepted, budgeted inversion. Never an accidental one.
2. Externally-clocked items early. Anything waiting on a third party (the lab, a vendor, a licence notice) moves as early as its lead time allows, because slipping it is not in your gift.
3. Easy → hard. The pilot exists to prove the runbook while a mistake costs nothing.
4. Discover expensive surprises early. FileShare’s million files should surprise you in October, not in the week you needed the data engineer for PIMS-Core.
5. Crown jewels late, but not last. The most critical system moves when the team is most practised — with enough calendar behind it for at least two fallback attempts.

Do the two numbers that make that concrete, because they are the reason the appliance wins:

Sustainable link rate          150 Mbps  =  18.75 MB/s  =  67.5 GB/hour

ImageVault online, continuous  41,000 GB / 67.5 GB/h   = 607 hours  = 25.3 days flat out
ImageVault online, nights only 41,000 GB / 540 GB-night =  76 nights = ~2.5 months
                               (540 GB = 67.5 GB/h x an 8-hour 22:00-06:00 window)
                               ...and that leaves zero nightly capacity for anything else.

Daily delta after the seed     900 GB/month / 30 = 30 GB/day
                               30 / 540 = 5.6% of one night's window.  Converges easily.

Twenty-five days flat out on a contractually shared circuit, while the archive must stay readable, is not a plan. Seventy-six nights with nothing left over for FileShare or the databases is worse. The appliance is not a preference; it is the only option the arithmetic leaves standing — and the Size the Data Move drill makes you prove that result three more times on nastier numbers. Part 4 takes the appliance round trip apart step by step.

The wave record — one per wave

Fill this in five times: Wave 0 and Waves 1–4. If a field is blank, that is not a formatting problem, it is an unmade decision.

WAVE <n> — <name>
--------------------------------------------------------------
Calendar slot      : months <n>-<n>   ·  cutover: <day, window, duration>
Systems in scope   : <system> (<R>), <system> (<R>), ...
NOT in scope       : <the thing everyone will assume is in here, and isn't>

Entry criteria     (all true before this wave starts)
  1. ...
  2. ...
Exit criteria      (all true before the next wave starts)
  1. ...
  2. ...

Accepted couplings : <system> still talks to <thing still on-prem>
                     budget: <latency / volume / duration>   monitored by: <who>
Cutover window     : <day, time, length>  ·  window owner: <role>
Go/no-go           : <role> decides, no later than <wall-clock time>
Rollback owner     : <role>  ·  latest call: <wall-clock time>
Descope candidate  : <the first thing you drop from this wave>  ·  costs: <what>

Check 1 — the dependency check

☺ Like you’re 10: Go down your list and ask, for every arrow on the map: does this thing arrive before the thing it needs? If not, say out loud what you’re going to do about it.

Take the eleven edges above and, for each, mark one of three outcomes: satisfied (the dependency lands first), inverted and accepted (it lands second, and here is the budget), or broken (you have not decided, which means it will be decided for you at 03:40 on a Sunday). Nine of Brambleside’s eleven edges come out satisfied by any sensible ordering. Two do not — and those two are the whole exercise.

Inversion 1 — ClaimsFeed moves before PIMS-Core

ClaimsFeed reads a nightly billing extract from PIMS-Core. Dependency order says PIMS-Core first. But ClaimsFeed’s Oracle licence renews in month 7, and the whole point of replatforming it off Oracle is to not pay that renewal — so ClaimsFeed has to be in production before the renewal, and PIMS-Core cannot possibly move that early. The dependency loses to the money. Fine — but then write the coupling down:

Inversion 2 — BramblesideOnline moves before PIMS-Core

The public site writes bookings into PIMS-Core. Same shape, much longer exposure — roughly thirteen weeks from BramblesideOnline’s November cutover to PIMS-Core’s in February. Is that acceptable? Only because of what actually crosses the wire: about 1,400 booking writes a day, each a small API call at human pace, adding perhaps 12–18 ms of VPN round trip. Budget it explicitly — p95 booking confirmation under 800 ms end to end, measured from month 5 — and it holds.

The dependency people forget: the one on the thing being retired

BI-Reports is a Retire, so it is not in any wave. But nine of its forty reports are still used, and those nine read from PIMS-Core, StockCtrl and ClaimsFeed. You cannot rebuild them until all three sources have landed, and you cannot switch off the SSRS server until the rebuilt nine have run clean for at least two report cycles. That drags a Retire all the way to Wave 4’s tail — and it means the evidence work (export the 18-month audit log, get the nine owners to sign, freeze new report development) has to happen back in Wave 1 so nobody is negotiating report ownership in February. A Retire has a lead time and a dependency chain like anything else. It is simply cheaper. Anti-Patterns has the corresponding failure mode: switching a “dead” system off and discovering what it fed.

Check 2 — the capacity check

☺ Like you’re 10: Count how many weeks of people you actually have, then count how many weeks of work you actually planned, then look at which number is bigger. Most plans never do the second count.

This is the check that gets skipped, because it is the one that can tell you the plan is impossible. Do it anyway, in person-weeks, in the open.

Step 1 — what you have

Note what the 15% is not. It is not pessimism; it is the two clinic-rota engineers being pulled to a broken practice-management screen on a Tuesday morning, the December holiday, and the fortnight the migration lead spends on the board pack. If your organisation’s honest figure is 25%, use 25% — but use a figure, and write down which one.

Step 2 — what you planned

Estimate each wave in person-weeks: build, migrate, test, rehearse, cut over, hypercare, document. Then add a line for the work that belongs to no wave — decommissioning, retros, evidence packs, the board reporting. Your own numbers will differ from the model answer’s and that is fine. What is not fine is not producing a number at all.

Step 3 — subtract, and believe the answer

Available minus demanded. If the result is negative, you have three honest responses and one dishonest one. The honest ones: cut scope, buy capacity, or buy calendar. The dishonest one is to assume everyone works faster under pressure, which is how a migration ends up cutting over its crown jewel on the last available Sunday with no fallback. The model answer below runs a shortfall on the first draft — deliberately, because that is what a first draft does.

Check 3 — the calendar check

☺ Like you’re 10: Draw nine months. Cross out the two weeks at Christmas and the two weeks in March. Now put the moves in what’s left — and notice how much less there is than you thought.

Draw the nine months, then subtract before you add. These dates are given, not negotiable:

Now count the Sundays. Between the New Year and the March blackout there are only about nine of them, and the ones in the first half of January are spoken for by ClaimsFeed’s cutover and PIMS-Core’s rehearsals. You are choosing a crown-jewel cutover date from a shortlist of four or five specific Sundays, and you need at least two of them left over as fallbacks. Work backwards from that and the rest of the calendar arranges itself.

The risk register

☺ Like you’re 10: For each thing that could go wrong: how likely, how bad, what you’ll do about it, who’s in charge, and — the important one — what you’d actually see that tells you to press the undo button.

Six columns. Five of them are the usual ones. The sixth is the one that makes the register useful at three in the morning:

That last column is the one Best Practices and 🐢 Timmy both refuse to sign a wave without, and it is the reason the Write a Rollback Plan drill exists. A trigger written at 4 p.m. on a Wednesday is a decision. A trigger “decided” at 03:40 on a Sunday, by tired people who have already invested six hours, is 👺 Gizmo leaning over your shoulder saying we’re nearly there, just push through. Two worked rows, so the shape is unambiguous:

Write six to ten of these, at least one per wave. The full model register is in the answer key below.

The descope ladder — what you cut, and when the option expires

☺ Like you’re 10: Write down, now, which boxes you’d leave behind — because when you’re out of time you won’t be thinking clearly, and some of those choices stop being available months before you need them.

Every constrained plan needs a written answer to “we are three weeks late — what goes?”, and it needs it in month 1. Rank your cuts cheapest-first, and — this is the part almost nobody does — put an expiry date on each rung, because several of them stop being available long before you would think to use them.

The rungs come in four flavours: cut scope (free, costs capability), buy capacity (costs money, needs lead time), buy calendar (costs money, only helps if the date is the binding constraint rather than the people), and break glass. Brambleside’s break-glass rung is the standing temptation from the 7 R’s: Relocate — move the remaining colo VMs wholesale into a cloud VMware service in one bulk operation, no per-application runbooks, and migrate out of it app-by-app over the following year. It beats the date and it is the only rung that can absorb a two-month slip. It also raises the steady-state run-rate that Part 5 has to get back under $42,000/month, which is precisely why it is the last rung and not the default.

What “done” looks like for Part 3, and where Part 4 picks up

☺ Like you’re 10: Four things you can point at and check yourself, without anybody marking it.

Part 3 is done when all four of these are objectively true of your plan, not the model’s:

1. Every one of the eleven moving systems appears in exactly one wave. Not zero, not two. Count them.
2. No dependency is violated. Every edge is either satisfied by the ordering, or inverted and accepted with a written budget — a volume, a latency, a duration, and who watches it.
3. The plan fits the calendar with the blackouts removed. No cutover falls in 20 December – 3 January or 9–22 March, PIMS-Core has a Sunday 02:00–06:00 slot with at least two fallbacks before the March blackout, and the last colo system is out before 31 March.
4. You have written down what you would cut first if you were three weeks late in month 7 — with an expiry date on each rung, and knowing which rungs your own earlier decisions have already removed.

Milestones

☺ Like you’re 10: Tick each box only when the thing is actually written down in your own sheet — not when you’ve decided it in your head.

Work these in order — each check is run against the plan the one before it produced. Progress saves in this browser.

Part 3 turned a disposition matrix and a landing zone into something with dates, owners and triggers on it — and, more usefully, into a written answer for the week it starts going wrong. Continue to Capstone Part 4 — The Data Move & the Cutover Runbook, which takes Wave 4 and writes the hardest four hours of this plan minute by minute. Step back to Part 2 — The Landing Zone if Wave 0’s exit criteria felt thin, or to Move Brambleside — Start Here for how the five parts fit together. For the theory underneath this page: Wave Planning for the grouping craft, The Journey for where Mobilize sits, Anti-Patterns for big bang and the missing rollback, and Best Practices for piloting small and always keeping a way back.