Capstone Part 2 — The Landing Zone

Part 1 decided what moves. This part decides where it lands — and it happens before anything travels, because a landing zone built after the first workload arrives is not a landing zone, it’s a cleanup project. You’ll make six decisions for Brambleside Veterinary Group and write each one down with its reason: the boundaries you carve the cloud into, the region and DR region the board’s residency policy actually allows, an address plan that has to dodge three existing networks and the cloud console’s own default, how the two worlds are wired together while both are alive, what order identity moves in, and the guardrails that turn “we’ll be careful” into something a policy engine enforces. You need a spreadsheet and a text editor. Nothing else — no cloud account, no card.

What this part assumes, and what it produces

☺ Like you’re 10: You already know what’s moving. Now you draw the new house — on paper, with a pencil, before anyone hires a van.

This part assumes two things from Part 1. First, that every system carries a decided R, so you know which ones need a network at all — a Repurchased system lands in someone else’s cloud and needs identity and a contract from you, not a subnet. Second, that you have committed to one cloud. Not evaluated three. Committed to one, in a sentence, because a landing zone is a shape you can only draw once you know whose vocabulary you’re drawing it in. If you skipped that, go and do it now: read your chosen track — Migrating to AWS, Migrating to Azure, or Migrating to Google Cloud — and write one sentence naming the deciding fact about this estate. There is a worked example of that sentence in the answer key.

It produces three artifacts, and they are all documents:

The eleven systems that need somewhere to land

Here is Part 1’s output, restated so this page stands on its own. If your Part 1 answers differ in a row or two, use yours — the method is what carries, not the specific R.

And the five that aren’t moving, which still shape the design: AD-DC01/DC02 (Retain — but read Decision 5 before you assume that means “leave them where they are”), PrintSrv (Retain, latency-bound to the dispensing printers in 22 clinics), BackupVault and the tape library (Retain, holding the seven-year finance retention), AshBook (Ashcombe’s booking app, already in a public cloud — integrate, don’t migrate), and Ashcombe PIMS (vendor-hosted, consolidate at contract renewal, not during the nine months).

The constraints that actually do the work

☺ Like you’re 10: These eight facts are the reason the answer isn’t just “make a cloud account.”

Decision 1 — The boundaries: accounts, subscriptions or projects

☺ Like you’re 10: Rooms, not one enormous hall. But also not forty rooms when there are only four of you to clean them.

Every cloud gives you a top-level container that isolates things from each other — an account on AWS, a subscription on Azure, a project on Google Cloud — and a way to group those containers so a rule set once applies to all of them (Organizations OUs, management groups, folders). The design question is not “how many should we have?” It is: what is each boundary isolating, and from what? A boundary earns its place if it isolates a blast radius, a bill, or a regulatory obligation. If it isolates none of those, it is overhead a four-person team will pay for every week.

Two failure modes bracket the answer, and Brambleside can walk into either. One giant boundary holding everything means a mistake in DevTest can reach clinical data, and the finance director cannot be told what PIMS-Core costs. Twenty boundaries mean six people — five from month 3 — maintaining twenty sets of policies, twenty sets of network peerings, and twenty places for a guardrail to be quietly missing. For an estate of eleven systems and a team of six, the honest answer is a small number, named for what it isolates:

Five boundaries. Notice what the fifth one is for: the migration team has broad rights everywhere else, because they have to, and that is precisely why the record of what they did has to live somewhere they cannot reach. That is not distrust — it is the same reason a shop’s till roll isn’t stored in the till.

Notice also what is absent. PIMS-Core is the most important system in the estate and it has no boundary, because Part 1 marked it Repurchase: it lands in the vendor’s cloud. RotaMaster and VetLearn likewise. Roughly a third of this estate never touches your landing zone — which is a saving, and a trap, and Decision 6 and the shared-responsibility table are where you pay attention to it.

Decision 2 — Region, DR region, and the numbers per tier

☺ Like you’re 10: Which country the new house is in isn’t a preference. And the spare house has to be in the same country too.

The board’s policy is one sentence long and it decides most of this: client and clinical data stays in-country, DR region included. So before anything else, go and check a fact most learners assume rather than verify: does your chosen cloud actually have two regions in this country? Many countries have one. Several have none. That single lookup rewrites the DR design, and it is the first thing to put in the doc — with the date you checked it, because provider region maps move.

There are three honest outcomes, and each has a different design:

• Two in-country regions exist. Straightforward. Primary in one, DR in the other, both inside the policy.
• One in-country region exists. Then cross-region DR is not available to you for clinical and client data. The design becomes: multi-availability-zone within the single region for high availability, plus in-region backups with immutability — and a written, board-signed statement that a whole-region loss is an accepted risk with a documented manual recovery path. Do not quietly replicate to a foreign region and hope nobody reads the architecture diagram. That is not a DR strategy, it is a breach with a runbook.
• No in-country region exists. Then the residency policy and the migration are in direct conflict, and that is a board decision, not an engineering one. Escalate it in month 1 with two costed options (a sovereign/partner region, or a policy amendment), not in month 7 with a plea.

Now tier the estate. Four tiers is enough; more than four and nobody remembers which is which.

The row that teaches is Tier 1. PIMS-Core is a Repurchase, so you do not build its DR — but you absolutely still own its numbers. Go and read the vendor’s service description, find the RTO and RPO they actually commit to (as opposed to the uptime percentage they advertise), and copy them into your table with the contract clause reference. If the vendor’s committed RPO is worse than 15 minutes, that is not a vendor problem you discovered — it is a Brambleside risk you accepted, and it belongs in the doc with a name against it. Repurchase moves the work. It does not move the accountability.

ImageVault is the other one worth staring at. Its tolerance is zero: reads must never break. That does not mean it needs the most expensive DR — it means it cannot have a cutover in the usual sense. Its read path has to be made to work from both sides and then quietly re-pointed, which is why Part 3 seeds it in month 2 while PIMS-Core doesn’t flip until Wave 4. Decision 2 is where you first notice that; Part 3 is where it becomes a schedule.

Decision 3 — The address plan, and the trap in the console

☺ Like you’re 10: Two houses with the same street number means the post goes to the wrong one, forever, and nobody can tell why.

This is the decision that is cheapest to get right today and most expensive to get wrong ever. Overlapping private address ranges cannot be routed between. Not “work badly” — cannot be routed. And you don’t find out on the day you allocate them; you find out months later, on the day you try to connect two things that were designed separately, at which point one side has to be renumbered while it is running.

Brambleside’s starting position:

There it is. The default VPC / default VNet / default network that appears the moment a new account, subscription or project is created uses the same range Ashcombe already occupies. Nobody plans this collision — it arrives by default, in a boundary somebody created in a hurry, and it sits there harmlessly until the day you try to peer Ashcombe in and discover that a network you never designed is holding the address space.

The fix is two rules, and both belong in the doc:

1. Delete the default network in every boundary, on day one, as the first action after the boundary exists. If you leave it, someone will use it — not maliciously, just because it is there and their VM needed a subnet on a Friday.
2. Every range comes from one allocation table, and nothing is created outside it. One person owns that table. Addresses are free until they overlap, so reserve generously — reserving a range you never use costs nothing; needing a range you gave away costs a renumbering project.

Here is a worked allocation. Reserve one clean supernet for the entire cloud estate, then carve it:

Then inside the primary production /16, a subnet plan that a colleague can implement without ringing you. Two availability zones, three tiers, and — the part people skip — explicitly reserved space that is not handed out:

One consequence worth stating plainly: because the cloud lives in 10.40.0.0/14, Ashcombe’s 10.0.0.0/16 does not collide with it, and AshBook can be integrated later without a renumbering project. That is not luck — it is the payoff for spending twenty minutes on this table instead of accepting the default. Ashcombe’s range is still accepted debt (it collides with every future default network anyone accidentally creates), so record it as such, with the trigger that forces the fix: “renumber Ashcombe before it is connected to the hub, or before the next acquisition, whichever comes first.”

Decision 4 — How the two worlds are wired, and LabBridge’s one address

☺ Like you’re 10: While you live in both houses you need a phone line between them. And one of your friends will only ring one specific number — so that number has to move with you, and you have to tell them weeks ahead.

Two shapes of link, and you will use both, in this order. A site-to-site VPN — an encrypted tunnel over the ordinary internet — goes up in week one. It is cheap, it has no lead time, and it is enough for management traffic, directory replication and the trickle of application chatter during the hybrid period. Build it with two tunnels to two gateways, not one; a single tunnel is a single point of failure you designed in on purpose. A dedicated circuit (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) is ordered in month one, because the lead time is weeks to months and it is not yours to compress, and it carries the steady-state hybrid traffic and the parallel-run period once it lands. Architecture Patterns covers the trade-off in general; the Brambleside-specific part is the sequencing.

The clinic path — the thing that disappears with the colo

Today, 22 clinics reach PIMS-Core by routing to the colo. After 31 March there is no colo. So somewhere in Wave 0 there has to be a new path from every clinic to the cloud — per-clinic internet plus a VPN or SD-WAN edge, or a re-homed hub — and it has to be built and tested before the last thing leaves the colo, not after. This is a genuinely easy item to miss, because it is not on the inventory: it isn’t a system, it’s a route. Write it into the doc as a named deliverable with an owner, or Part 3 will discover it in month 8.

LabBridge: one allow-listed IP, and the lead time you don’t control

LabBridge polls the external reference lab over IPsec, and the lab allow-lists exactly one fixed public IP address. In a cloud, outbound traffic from a VM normally leaves through a NAT gateway using a provider-assigned address which is not guaranteed to be stable. So there are two halves to this answer, and only one of them is technical:

1. The technical half. Allocate a static, reserved public address (an Elastic IP, a Standard static Public IP, a reserved external IP — the names differ, the concept doesn’t), attach it to the NAT gateway or gateway endpoint that LabBridge egresses through, and put LabBridge in its own egress subnet (10.40.56.0/22 in the plan above) so you know precisely what else shares that address — ideally, nothing. Then check your account’s default quota for reserved public addresses, because a quota increase is itself a request with a turnaround time.
2. The half that isn’t yours. The lab has to add the new address to their allow-list, and external labs run change control on a schedule measured in weeks, sometimes with a named window. Raise that change request in month 1. Ask for both addresses to be allow-listed simultaneously for an overlap period, so the new tunnel can be stood up and tested in parallel with the old one while the old one still works. Then cut over, watch a full nightly cycle succeed, and only then ask them to remove the old one — after the colo is gone, not before.

DNS, which is a platform service and not an app problem

PIMS-Core references ImageVault by UNC path — which is to say, by a name that has to resolve identically on both sides of the link, for the entire hybrid period, or a vet in a consulting room gets an error instead of an X-ray. Hybrid name resolution therefore belongs in the platform boundary, built once: inbound and outbound resolvers (or conditional forwarders) so on-premises clients can resolve cloud names and cloud workloads can resolve on-premises names, with the forwarding rules written down. Solve it as plumbing, in Wave 0. Solve it per-application and you will solve it eleven times, differently, and debug it at 04:00.

Decision 5 — Identity: extend the domain first, federate second

☺ Like you’re 10: Don’t change the locks and move the furniture on the same day. If a key stops working you won’t know which change broke it.

Everything in this estate authenticates against AD-DC01/DC02: PIMS-Core, FileShare, StockCtrl, PrintSrv, every domain-joined Windows server. Part 1 marked AD Retain, and Part 2 is where you discover that Retain has an address. Retaining the domain means the directory survives unchanged — same forest, same accounts, same group memberships, nobody re-learns a password. It does not mean the domain controllers stay in a building whose lease expires on 31 March, or in a server room whose HVAC has failed twice this year.

So the order is:

1. Extend the domain into the cloud. Stand up two domain controllers in the platform boundary, one per availability zone, joined to the existing forest, replicating over the VPN. Now the same domain exists on both sides. Every server that moves can domain-join locally instead of authenticating across a WAN link that is about to be switched off — which matters enormously for FileShare, whose managed file service has to be domain-joined before a single one of its 1.1 million files is useful.
2. Keep one controller near the printers. PrintSrv is Retain and latency-bound to the dispensing-label printers in 22 clinics, so clinic-side authentication has to survive a WAN blip. A domain controller at the flagship covers that. The colo controllers are the ones that go.
3. Then federate console access. Point the cloud’s identity service (IAM Identity Center, Microsoft Entra ID, Cloud Identity) at the directory, so humans reach the cloud console with their existing account and MFA, and no long-lived access keys exist for any person. Machines get roles, never keys — the same least-privilege habit Provisions describes, applied to identities that don’t have hands.
4. Write down break-glass. Two emergency accounts, MFA, credentials sealed and stored physically, not federated — because the day federation breaks is precisely the day you need to log in and fix federation. Name who may open them, and what gets logged when they do.
5. Retire the on-prem footprint last, and only after 31 March. AD is the last thing to leave Fort Rusty. But “Retain” has an expiry date, and writing that date down is Part 2’s job, not a problem to rediscover in Part 5.

Doing it in the other order — federate first, extend later — is the classic mistake, and its cost is diagnostic rather than technical: when a login fails during a wave, you cannot tell whether the app moved badly or the identity plumbing changed underneath it, because you changed both. Extend first and identity becomes the one thing that is the same on both sides of every cutover. That is what makes it a control variable instead of another suspect.

Decision 6 — Four guardrails minimum, and two this estate makes non-optional

☺ Like you’re 10: A fence at the top of the cliff, not an ambulance at the bottom — and a fence somebody actually built, not one we agreed would be nice.

A guardrail is a rule the platform enforces, so nobody has to remember it on a busy Tuesday. Provisions splits them into preventive (refuses the bad thing) and detective (spots it and shouts). Mature setups run both. Brambleside needs at least these, and each one needs an owner and a way to prove it is on:

Six is not a lot. The discipline is not the count — it is that every row has a name in the owner column and a testable “how you know”. A guardrail you have never tried to violate is a belief, not a control.

The line you still own: shared responsibility, written out

☺ Like you’re 10: The landlord fixes the roof. You still lock your own front door — and you still own everything inside.

Every one of Part 1’s R’s moves the line in the shared responsibility model to a different place, which means Brambleside ends the migration owning a different set of jobs than it started with — not fewer jobs, differently shaped ones. This table is the one that stops a team from cheerfully assuming somebody else is patching something. Fill it in for your chosen cloud; the shape is identical across all three.

The artifact: your one-page landing-zone design doc

☺ Like you’re 10: All six decisions, on one page, so somebody else could build it while you’re on holiday.

Fill this in. Keep it to one page — the discipline of a page is what forces a decision instead of a discussion. Every blank is a decision somebody has to make eventually; leaving it blank now just means making it at 04:00 later, badly.

# Brambleside Veterinary Group — landing zone, v1
Owner: __________   Date: __________   Review date: __________
Cloud: __________   Why (one sentence, naming the deciding fact about THIS estate): __________

## 1. Boundaries
| Boundary | What it isolates | What lands here | Who may change it |
|---|---|---|---|
|  |  |  |  |
Default network deleted in every boundary? Y / N — evidence: __________

## 2. Region & resilience
Primary region: __________   In-country? Y / N   Verified on (date): __________
DR region:      __________   In-country? Y / N   If no second in-country region exists, the accepted risk is: __________
Signed off by: __________ (board / DPO)

| Tier | Systems | Planned cutover window | RTO | RPO | DR pattern | Owner |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

For every Repurchased system, the VENDOR's committed RTO / RPO and the contract clause it comes from:
| System | Vendor RTO | Vendor RPO | Clause ref | Acceptable? Who accepted it |
|---|---|---|---|---|

## 3. Address plan
| Range | Purpose | Region | Allocated by | Checked against (list every network) |
|---|---|---|---|---|
|  |  |  |  |  |
Reserved-but-unallocated (do not hand out): __________
Known overlaps accepted as debt, with the trigger that forces the fix: __________

## 4. Connectivity
Day one:  __________            Later: __________  (ordered on ______, lead time ______)
Clinic path after the colo exits, owner and date: __________
LabBridge static egress address: __________
  Lab change request raised on: ______   Both addresses allow-listed from ______ to ______
  Old address removed only after: __________
Hybrid DNS design (resolvers / forwarders, who owns them): __________

## 5. Identity
Domain: ______  Cloud DCs: ______ (how many, which zones)  On-prem DC retained at: ______
Console federation: ______   MFA enforced: Y / N
Break-glass accounts: ______ (how many, who may open them, what is logged)
Machine identity: roles / keys — and if keys, why: __________
SSO owner for each Repurchased system: __________

## 6. Guardrails
| # | Guardrail | Preventive / detective | Enforced by | Owner | How we know it is on (the test) |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 7. Shared responsibility
| Layer | Brambleside owns | Provider / vendor owns | Evidence we keep, and where |
|---|---|---|---|
|  |  |  |  |

## 8. Open questions and accepted risk
| # | Item | Owner | Decide by | Consequence if we don't |
|---|---|---|---|---|
|  |  |  |  |  |

Give yourself 90 minutes for the first pass and do not polish. A filled-in page with three arguable answers beats a beautiful half page, because Part 3 can schedule around an arguable answer and can do nothing at all with a blank.

Milestones

☺ Like you’re 10: Tick a box when the answer is actually written down somewhere, not when you’ve thought about it.

Work these in order — several depend on the one before. Progress saves in this browser.

Done when

☺ Like you’re 10: Four things you can check with your own eyes, not four things you feel good about.

Part 2 is finished — objectively, checkably — when all four of these are true:

1. No two CIDRs overlap. Every range in the address table has a “checked against” cell naming clinics, colo, Ashcombe and the console default, and a reader can verify every pair in ninety seconds without asking you anything.
2. The residency policy is satisfied by both regions — or, if a second in-country region does not exist, the alternative design is written down and the residual risk carries a named person who accepted it.
3. LabBridge has a documented answer with dates — a static address, a dedicated egress subnet, a change request raised in month 1, an overlap period, and a removal date that falls after the colo exit.
4. Someone who wasn’t in the room could build it from your page. Hand them the doc, say nothing, and see whether they come back with questions. Questions are the finding; go and fill in the blank they found.

Part 2 gave you a destination: five boundaries that each isolate something real, a region pair the residency policy actually permits, an address plan that dodges three existing networks and the console’s own default, a connectivity answer with the lead-time items already in month 1, an identity order that keeps one variable still during every cutover, and six guardrails with owners and tests. Continue to Capstone Part 3 — The Wave Plan, which sequences the 11 systems into waves that land here, against a nine-month calendar with two blackout windows and a hard stop. Or step back to Part 1 if a row in the tier table made you want to revisit an R, or to Move Brambleside — Start Here for how the five parts fit together. For the theory behind today: Architecture Patterns (the foundation and the bridge), Security, Cost & Resilience (shared responsibility, residency, guardrails, DR, networking) and Best Practices (land in a secure, well-designed home).