Capstone Part 1 — Discovery & the Disposition Matrix

This is the first of five parts that plan and run one whole migration: getting Brambleside Veterinary Group — 22 clinics, one emergency hospital, 16 systems, and a colo contract that expires in nine months — out of Fort Rusty and into Cloudville. Part 1 is the part everybody wants to skip, and it is the part that decides whether the other four are calm or frightening. You will count the estate, draw what depends on what, decide what doesn’t move before you argue about anything else, and then give all 16 systems exactly one of the 7 R’s — each with a one-sentence reason and, crucially, the one fact that would flip it. Nothing here needs a cloud account. It needs a spreadsheet and about two focused hours.

What this part assumes, and what it produces

☺ Like you’re 10: A spreadsheet, a pen, and two hours. Nothing that costs money.

Tools you need: a spreadsheet and a text editor. That is the whole list. This is a planning-and-decision lab, and disposition is genuinely done in a spreadsheet — in real programmes it is done in a spreadsheet even when a six-figure discovery tool is also running, because the tool produces data and the spreadsheet is where the argument happens. You do not need a cloud account, a credit card, or any provisioned infrastructure for any part of this capstone.

Tools you may reach for, but must not depend on: if you happen to have a free-tier or read-only look at AWS Application Discovery Service, Azure Migrate, or Google Cloud Migration Center, open one and look at the shape of its inventory and dependency output — the column headings alone are instructive, because they are the columns a real assessment produces. See The Tools Landscape for what each one does. Nothing below requires them.

Theory this part is built on — skim any of these you haven’t read, or keep them open in a tab:

What you produce: three artifacts, in this order — a dependency edge list, a 16-row disposition matrix, and a rationalization tally. Part 2 cannot start without the matrix, and Part 3’s wave plan is checked directly against the edge list, so these are not throwaway exercises.

The estate you’re moving — Brambleside Veterinary Group

☺ Like you’re 10: Twenty-two animal hospitals, one big computer room that’s closing, and sixteen computer systems that all need somewhere to go.

The canonical fact sheet lives on the hub, Move Brambleside — Start Here. Part 1 is the discovery part, so the whole of it is repeated here — every later part will only restate the three or four rows it needs.

The company

Brambleside Veterinary Group runs 22 small-animal clinics plus one 24-hour emergency hospital, all in a single country. Around 600 staff. Founded 1987. In 2023 it acquired Ashcombe Vets (3 clinics), which was never integrated — Ashcombe still runs its own booking site and its own tenant of the same practice-management software. IT is five people. The migration team is six, and one of the six leaves at month 3.

Fort Rusty

VMware vSphere 7 across 8 hosts, split between a converted server room at the flagship clinic and 8 racks in a colocation facility 40 km away. The flagship server room’s air conditioning has failed twice this year. This matters more than it looks: anything you decide to Retain has to be able to live at the flagship, because the colo is what’s closing.

The clock, the blackouts, and the money

The inventory — 14 Brambleside systems and 2 Ashcombe systems

This is what the outgoing infrastructure lead typed up before he went on leave. It has not been verified. It is the honest starting point of most real migrations.

Add it up and the estate holds roughly 50 TB of data, of which 41 TB is one archive. Hold that number; Part 4 does arithmetic with it.

Step 1 — Draw the dependency map before you touch the R column

☺ Like you’re 10: Before you decide which box goes where, find out which boxes have wires running between them. The wire you don’t know about is the one that snaps.

An inventory is a list. A dependency map is a list plus the edges between the items, and it is the edges that constrain everything downstream. Wave Planning puts it bluntly: you can’t batch what you haven’t mapped. Do this before you assign a single R, because half the R decisions are made for you by an edge you hadn’t noticed.

Write it as a flat edge list, not a diagram. Diagrams are for the steering committee; edge lists are what you can actually check a wave plan against, row by row, in Part 3.

# dependency-map.txt  —  one edge per line
# FROM -> TO | kind | frequency | what breaks if the edge stretches

PIMS-Core        -> ImageVault      | SMB/UNC path    | every study opened | consults get slow, then fail
PIMS-Core        -> AD-DC           | Kerberos auth   | constant           | nobody can log in
PIMS-Core        -> PrintSrv        | print queue     | every dispense     | no dispensing labels
BramblesideOnline-> PIMS-Core       | booking API     | constant           | online booking stops
BramblesideOnline-> MySQL 5.7 (own) | database        | constant           | site down
LabBridge        -> external lab    | IPsec, ONE allow-listed public IP | 15 min poll | results stop arriving
LabBridge        -> PIMS-Core       | writes results into the record    | 15 min      | results arrive nowhere
ClaimsFeed       -> PIMS-Core       | nightly billing extract           | 1x/night    | claims batch is empty
ClaimsFeed       -> insurer SFTP    | outbound batch                    | 1x/night    | claims not submitted
StockCtrl        -> AD-DC           | auth            | constant           | no stock system
StockCtrl        -> PrintSrv        | dispensing labels                 | every dispense | as above
RotaMaster       -> AD-DC           | auth            | constant           | no rota
VetLearn         -> AD-DC           | auth            | daily              | no CPD portal
FileShare        -> AD-DC           | share ACLs      | constant           | permissions collapse
BI-Reports       -> PIMS-Core (SQL) | scheduled read  | nightly            | 9 real reports go stale
BI-Reports       -> StockCtrl (SQL) | scheduled read  | nightly            | as above
BackupVault      -> (everything)    | backup agents   | nightly            | no recovery point
DevTest          -> AD-DC           | auth            | constant           | dev logins fail
AshBook          -> Ashcombe PIMS   | booking API     | constant           | Ashcombe booking stops
AshBook          -> (nothing at Brambleside)          | —           | — | this is a finding, not an omission

Now read the list back and answer three questions from it. These are the questions the edge list exists to answer, and every one of them changes an R:

Step 2 — Criticality and downtime tolerance, before opinions

☺ Like you’re 10: For each thing, ask “if this broke right now, how long before somebody is really upset?” Write down the answer in hours, not adjectives.

Everyone will tell you their system is critical. The way through that is to stop asking for adjectives and start asking for two numbers: how long may it be down, and when is it allowed to be down. Those two, and not the word “critical,” are what constrain the plan — and they are the RTO conversation from Best Practices arriving early, where it’s cheap.

Step 3 — Retire and Retain, before any other R

☺ Like you’re 10: Fill the bin bags and the “leave it in the garage” pile first. Every box you don’t carry is a box you never have to carry, unpack, or pay rent on.

This is the discipline you will resist, and it is the single highest-return half hour on this page. The 7 R’s makes the point in one line: the cheapest migration is the one you skip. So before anybody argues about whether PIMS-Core should be Rehosted or Repurchased — which is a genuinely hard argument that will eat an afternoon — do two fast, evidence-led passes that shrink the problem.

The Retire pass — what should simply stop existing?

Retire needs evidence, never intuition, because Retire is the only irreversible R. For each candidate, name the artefact that proves nobody needs it:

• BI-Reports’ 31 dead reports — the SSRS execution log. Not “I think nobody runs these.” The log, exported, dated, and attached to the matrix.
• FileShare’s cold 40% — last-access timestamps across 1.1 million files. That’s ~2.5 TB that stops travelling.
• 4 of the 11 DevTest VMs — no interactive login in 12 months, per the domain controller’s logon audit.
• BackupVault, the product — the cloud has native backup. What you are retiring is a backup server; what you are absolutely not retiring is the seven-year obligation it holds. Those are two different things and conflating them is how organisations discover in year four that they can no longer read their own tapes.

The Retain pass — what deliberately stays put, and where?

Retain is not “we didn’t get to it.” It is a decision with a stated reason and a stated review date, and in this estate it carries an extra condition most estates don’t have: anything Retained must be able to live at the flagship server room, because the colo is what’s closing. Retain is therefore a small, finite budget, spent in a room whose air conditioning has failed twice this year. Spend it on:

• PrintSrv — physically tied to label printers in 22 buildings, and latency-sensitive. Print is an edge workload; putting it 40 km further away in the name of “cloud” is a decision you would spend the next year regretting.
• AD-DC01 / DC02 — retained at the flagship for this round. Note carefully what that means: Part 2 will stand up new domain controllers in the landing zone, which is extending the directory, not migrating these two machines. The existing pair is retained until the last on-prem workload leaves, then decommissioned with Fort Rusty in Part 5.
• The tapes — the seven-year finance retention. Re-homed as a contract and a custody question, not a migration.
• AshBook and Ashcombe PIMS — both already outside Fort Rusty, neither on the colo clock. Doing a cloud-to-cloud move and a clinical-records consolidation during a data-centre exit is how you get all three wrong.

Done honestly, those two passes take the estate from 16 systems to 11 before a single R has been argued about — and the eleven that remain are a fundamentally more tractable problem than the sixteen you started with.

Step 4 — The Relocate temptation, costed rather than dismissed

☺ Like you’re 10: There’s a way to move the whole house in one go without unpacking anything. It’s real, it works, and it’s usually the wrong answer here — but you have to prove that, not just say it.

Relocate is the R that moves an entire VMware estate into a cloud-hosted VMware environment without changing the machines inside it — AWS, Azure and Google Cloud all sell one. Somebody in the steering committee will propose it, roughly like this: “We have vSphere. They sell vSphere-in-the-cloud. Why are we spending nine months arguing about sixteen spreadsheet rows when we could lift the lot by Christmas?”

That is a serious question and it deserves a costed answer, not a sigh. Work it as a sub-exercise before you finish the matrix, because if Relocate is right, most of the matrix becomes irrelevant and you should find that out now.

Step 5 — Assign the remaining eleven R’s

☺ Like you’re 10: Now, finally, decide how each leftover thing travels: carry it as-is, buy a new one, tweak it to fit, or rebuild it. And write down why, in one sentence, before you forget.

Eleven systems, one R each, forty minutes. Don’t polish — the fast path is explicit about this, and a rough matrix you can argue against beats a perfect one that arrives in month 3. Four working rules keep the pass honest:

1. One R per system. Two R’s on one row means you haven’t decided, and Part 3 can’t schedule an undecided row.
2. Except where evidence draws the line for you. A split is legitimate when a log, not your discomfort, says where the boundary is. In this estate that happens exactly three times — FileShare (access timestamps), BI-Reports (execution log), DevTest (logon audit) — and every one of them is Retire-then-something, never “a bit of both.”
3. The support matrix beats your preference. If the vendor supports a product on IaaS only, then the R is Rehost regardless of how much you’d enjoy a managed database. Check the vendor’s support statement before you write the row, not after the migration weekend.
4. Refactor is off the table before 31 March. Not because refactoring is bad — Modernization exists for a reason — but because refactoring during a forced data-centre exit means doing your two hardest projects simultaneously with the same six people, one of whom leaves at month 3. Park it; Part 5 picks it up as a 12-month roadmap, which is where it belongs.

The artifact — your disposition matrix

☺ Like you’re 10: One row per thing, ten things written down about each. That’s the whole deliverable.

Ten columns, sixteen rows. Build it in a spreadsheet; the template below is the header row plus one worked example so you can see the shape and the tone of a good rationale.

System,Owner,Criticality,Downtime tolerance,Depends on,Data size,Licence/support state,Chosen R,Rationale (one sentence),What would change this answer

ClaimsFeed,Finance (M. Okafor),Tier 2,May miss one night,PIMS-Core billing extract; insurer SFTP,280 GB,Oracle 12c SE — licence renews month 7,Replatform,"The month-7 Oracle renewal is a forcing function we should use rather than pay through: a 280 GB batch workload with no vendor lock is the cheapest database in the estate to move off Oracle.","A schema conversion assessment showing heavy PL/SQL and >4 weeks of manual rework — then renew Oracle for one year, Rehost, and carry the licence cost openly into Part 5's run-rate."

A few notes on filling it in. Owner must be a person, not a department: a department cannot approve a cutover at 04:12 on a Sunday. Depends on is copied from your edge list, not re-derived from memory. Rationale is one sentence — if it needs two, you have two decisions hiding in one row. And What would change this answer is a testable fact with somewhere to check it, not a mood.

The rationalization tally

Under the matrix, add the count. It is four lines and it is what the board remembers:

Estate at start:            16 systems, ~50 TB
Retire:                      1 system  (+ 31 of 40 reports, 2.5 TB of cold files, 4 of 11 DevTest VMs)
Retain:                      4 systems (2 at the flagship, 2 already outside Fort Rusty)
--------------------------------------------------------------------
Systems actually moving:    11
Data actually moving:       ~47.5 TB   <-- the Retire pass barely dented it. See Part 4.
Refactored before 31 March:  0         <-- deliberate, and correct

Note the third-from-last line, and be honest about it in the meeting: the Retire pass removed five systems and about 2.5 TB. It did not touch the 41 TB imaging archive, because that archive is genuinely needed and genuinely enormous. Rationalization makes the schedule tractable; it does not make the physics go away. Part 4 is where the physics gets dealt with, and Drill — Size the Data Move is where you practise the arithmetic in isolation first.

What “done” looks like for Part 1, and where Part 2 picks up

☺ Like you’re 10: Every row filled in, nothing contradicting anything else, and you can defend the two hardest ones out loud.

Part 1 is done when all four of these are objectively true — check them, don’t feel them:

1. All 16 rows carry an R. No blanks, no “TBD”, no row with two R’s that isn’t one of the three evidence-led splits.
2. Every R is justified in one sentence, and every row’s last column names a specific, checkable fact that would flip it — with somewhere to go and check it.
3. No row’s R contradicts the dependency map. Walk the edge list line by line against the matrix: nothing is Retired that something still points at, nothing is Retained whose only consumer is moving, and nothing sits alone in the cloud reading a UNC path 40 km away without that being an explicit, costed decision.
4. You can defend the two you found hardest without saying “it depends.” Say what you decided, say what fact you’d check to change your mind, and say when you’ll check it. That sentence shape is the entire skill.

Everything you just built gets used:

Want isolated practice on the hardest skill on this page before you commit to your matrix? Drill — Pick the Right R gives you ten system cards from ten unrelated organisations, three minutes each, each one hiding the fact that flips the obvious answer.

Milestones

☺ Like you’re 10: Tick a box only when the thing is actually written down somewhere you could hand to somebody else — not because you thought about it.

Work these in order; each one uses the output of the one before. Progress saves in this browser.

Part 1 gave you the thing every later part is checked against: sixteen decisions, each with a reason and a tripwire, and an estate that shrank by five systems before anybody carried a box. Continue to Capstone Part 2 — The Landing Zone, which designs the place all eleven survivors are going to land in — and springs the 10.0.0.0/16 trap Ashcombe left for you. Or step back to Move Brambleside — Start Here for how the five parts and three drills fit together, and revisit The 7 R’s and Stop 1 — Assess for the theory behind what you just did.