Capstone Part 5 — Operate, Optimize & Modernize

Brambleside Veterinary Group is out of the colo. Every wave has landed, PIMS-Core cut over inside its four-hour Sunday window, and the last clinic stopped noticing weeks ago. And the first full month’s cloud bill is $57,400 against an on-prem run-rate of $42,000 — which is the number the board made the whole project conditional on. This part is where a migration stops being a move and becomes a business: you will work that bill down with six levers you compute yourself, decide which two systems earn modernization in the next twelve months and write down why every other one does not, switch Fort Rusty off without losing a seven-year regulatory obligation, and run the retro. Then you will do the thing that separates an engineer from a spreadsheet — name, in writing, the one line you refuse to optimize.

What this part assumes, and what it produces

☺ Like you’re 10: Everything is already moved. Nothing new gets carried today — today is about the bill, the plan for what to rebuild, and giving back the old keys.

What Parts 1–4 hand you

Part 5 is the only part that assumes all four earlier parts are behind you, because the whole page is arithmetic on their outputs. If you skipped one, you can still work this page from the tables below — every number you need is restated here — but the exercise will feel like bookkeeping rather than consequences. Here is exactly what each part is assumed to have decided:

The four artifacts this page produces

1. A — The cost review. The bill, six levers with a number each, and a steady-state run-rate under $42,000/month — plus the line you refuse to cut.
2. B — The 12-month modernization roadmap. Two systems in, everything else explicitly out, and a strangler-fig outline for the one that earns it.
3. C — The decommissioning plan for Fort Rusty. Power-down order, evidence captured, obligations re-homed, contracts cancelled with their notice periods respected.
4. D — The one-page retro. What surprised us, what slowed us down, what changes next time.

All four fit on five sides of paper. That is deliberate: this is the pack you walk a steering committee through, and a steering committee does not read appendices.

The estate, restated — only the rows this part needs

☺ Like you’re 10: Here are the numbers you’ll be doing sums with, all in one place so you don’t have to go hunting.

The full fact sheet lives on Move Brambleside — Start Here. Part 5 needs four things from it: the baseline, the systems and their post-move shape, the constraints that still bite after the move, and the calendar.

The baseline the board is measuring you against

The condition the board attached to the whole project was simple and unforgiving: the post-migration steady-state run-rate must be no worse than today’s $42,000/month. Not “roughly.” Not “once we’ve optimized.” Steady state, on a normal month, all-in.

The sixteen systems and what happened to each

The constraints that still bite after the move

• Residency. Board policy: client and clinical data stays in-country — including the DR region. This kills several otherwise-cheaper options and is the reason PIMS-Core replatformed rather than repurchased.
• Downtime tolerance. PIMS-Core ≤ 4 h, Sunday 02:00–06:00 only, never a Monday. That tolerance was written for a planned outage. Spending it on an unplanned regional failure is a different conversation, and it is the conversation Lever 5 and the refusal below both turn on.
• Retention. Controlled-drug register 7 years. Finance backups 7 years. Both outlive the data centre and both are Brambleside’s obligation, not a vendor’s.
• Clinical availability. The 24-hour emergency hospital never closes. “Cheap and slow to get back” is a storage tier, not a clinical policy — which is why the archive rules below have a clinical exception baked in.
• The calendar. The project ran July (month 1) to March (month 9). The colo contract ends 31 March. Blackouts: 20 Dec – 3 Jan (emergency cover) and a two-week spring vaccination campaign in mid-March. The team lost a person in month 3 and never replaced them.

Artifact A — the cost review

☺ Like you’re 10: The first bill is a shock. Then you go through it line by line and find six ways it was silly, and fix each one, and show your working.

The bill you get if Part 1 never happened

This is April’s bill: every one of the sixteen systems moved at its on-prem shape — same CPU counts, same storage tier, same 24×7, same licences — into the landing zone Part 2 designed. Two lines are not naivety and should not be treated as fat: the landing zone and the DR line are Part 2’s deliberate design outputs, specced tier by tier against stated RTO/RPO targets. Everything else is what happens when you carry the data centre’s decisions across the wire along with the data.

Anti-Patterns & Pitfalls files this under two names at once — lift-and-shift-everything and ignoring cost → bill shock — and they are the same trap seen from two ends. Nothing in that table is a cloud pricing problem. Every single fat line is an on-prem decision that got a free ride across the wire because nobody was asked to re-justify it. The cloud did not make Brambleside more expensive; it made Brambleside’s existing waste visible and monthly.

Lever 1 — Retire and Repurchase: banking Part 1’s decisions

☺ Like you’re 10: The cheapest thing to run is a thing you don’t run. Part 1 already found five of those — this is just cashing them in.

This lever costs nothing to pull because Part 1 already did the arguing. That is the point of doing Retire and Retain first: by the time you get to a bill, the decisions are made and priced, and this lever is a data-entry exercise rather than a fight.

Note the FileShare line carefully, because it hides the trap Size the Data Move drills into you: moving 440,000 cold files to an archive tier costs a one-off transition charge per object — roughly $1,900 here — which pays back in about two months and would have been invisible if you had reasoned only about terabytes. File count is a cost dimension, not just a transfer-time dimension.

Lever 2 — Rightsizing: stop paying for the 2019 spec sheet

☺ Like you’re 10: You bought a van because one day you might move a sofa. You move a backpack. Get a smaller van.

On-prem, you sized for the peak you might hit over a four-year refresh cycle, because you could not resize a bought machine. In the cloud you can resize on a Tuesday, so sizing from a four-year-old spec sheet is not caution — it is a standing order to overpay. Every provider ships a recommender that reads your own utilization and proposes a size (AWS Compute Optimizer, Azure Advisor, Google Cloud’s Recommender). Use it as an input, never as an authority: it cannot see your seasonality, and Brambleside has a very obvious March.

Lever 3 — Schedule the non-prod estate 12×5 instead of 24×7

☺ Like you’re 10: Turn the lights off in rooms nobody is in at 3 a.m. on a Sunday.

Seven DevTest environments survive Lever 1, at $2,740/month — $2,400 of that compute, $340 storage that keeps billing whether the machine is on or off. A 12-hour weekday window is 60 of the 168 hours in a week, or 35.7%. The compute portion drops to about $860; storage does not move.

DevTest after Lever 1        2,740   ( compute 2,400 + storage 340 )
Scheduled window             12 h x 5 d  =  60 / 168 h  =  35.7%
Compute at 35.7%             2,400 x 0.357  =  857  ->  860
New DevTest total            860 + 340  =  1,200

Lever 3 saving               2,740 - 1,200  =  -1,540

Two things make this lever stick rather than quietly rot. First, the schedule is a property of the environment, expressed as a tag the Part 2 tagging standard already mandates (schedule=weekday-12x5) and enforced by a scheduler, not by a person remembering. Second, an environment that someone needs at 22:00 can opt out — but opting out sets schedule=always-on with an owner and a review date, so the exception is visible in the same report that produced this saving. An exception you cannot see is not an exception; it is a leak.

Lever 4 — Tier ImageVault’s cold 78% to archive

☺ Like you’re 10: Forty years of old X-rays don’t need to sit on the kitchen table. Put the old ones in the attic — but keep a ladder.

This is the biggest lever on the page and the one people skip, because storage is not where engineers look. ImageVault is 41 TB on a premium SMB file service, chosen because PIMS-Core references studies by UNC path and lifting the path was the fastest way to cut over. That decision was right for the cutover and wrong for the steady state. The audit says 78% of studies have not been touched in 24 months.

ImageVault naive        41 TB, all premium SMB           9,200

After tiering
  hot tier              9 TB on the SMB file service     2,020
  archive tier          32 TB on archive object storage     640
  gateway + retrievals  transparent rehydration + budget    380
                                                        -------
                                                          3,040

Lever 4 saving          9,200 - 3,040  =  -6,160

The mechanism is a lifecycle rule — every cloud has one (S3 Lifecycle, Blob lifecycle management, Object Lifecycle Management) — plus a gateway that keeps the UNC path working so PIMS-Core never learns anything changed. That gateway is not optional garnish; it is the reason this lever does not require touching a vendor application you do not own.

One more consequence worth carrying into the roadmap: ImageVault grows 900 GB/month. Without the rule, the hot tier grows about $200/month every year, forever. With the rule, the hot tier stays roughly flat, because studies age into archive at roughly the rate new ones arrive. A lifecycle rule is not a one-off saving; it is a saving that keeps applying itself.

Lever 5 — One-year commitments, on the steady-state base only

☺ Like you’re 10: Promise to rent the same scooter for a whole year and it’s much cheaper. Just don’t promise it for the scooter you’re about to swap for a bike.

Security, Cost & Resilience lays out the three pricing models — on-demand, committed (reserved instances / savings plans / committed-use discounts), and spot. The art is layering them, and the single rule that keeps a commitment from becoming a liability is this: commit only to a shape you are certain will still exist in twelve months. Applied to Brambleside, that draws a hard line through the estate.

One year, not three. Three-year commitments are cheaper per month and would look better on this page — and they would lock a nine-month-old estate into decisions made before anyone had seen a full seasonal cycle, including a spring vaccination campaign that has never once run on this infrastructure. Take the smaller discount and keep the option. Revisit at the twelve-month mark, when you have real seasonality data and Artifact B has told you which shapes are about to change.

Lever 6 — Drop the Oracle licence when ClaimsFeed replatforms

☺ Like you’re 10: You were renting an expensive engine to do a small job. Swap it for a normal one and stop renting.

ClaimsFeed is a nightly SFTP job against a 280 GB Oracle Database 12c SE instance, and its licence renewal falls in month 7 — January, two months before the colo dies. That date is not a coincidence in this exercise; it is the whole lever. Renewing means paying $2,600/month for another year on a database you are about to replace. Not renewing means the replatform has a hard deadline with a real number attached, which is the most useful kind of deadline there is.

ClaimsFeed on Oracle 12c SE     compute + storage  1,100
                                Oracle licence     2,600
                                                   -----
                                                   3,700

ClaimsFeed on managed PostgreSQL                     800

Lever 6 saving                  3,700 - 800  =    -2,900

Do not let the number make this look easy. It is a schema migration, an application change, and a re-test of a nightly feed the insurer depends on — Data Migration & Data Gravity is the page to re-read before you scope it. What makes it tractable here is that ClaimsFeed may miss one night: it is the one system in the estate whose downtime tolerance is measured in a whole night rather than in hours, which is why Part 3 could put it where it did. Money and risk lined up on the same system. Take that when it happens; it is rare.

The subtraction, in one place

☺ Like you’re 10: Here’s all six sums stacked up so you can see the big number turn into a small one.

Naive cloud bill                                     57,400

  L1  Retire & Repurchase (Part 1, banked)           -5,980
  L2  Rightsizing to observed peak utilization       -4,120
  L3  Non-prod scheduled 12x5 instead of 24x7        -1,540
  L4  ImageVault cold 78% tiered to archive          -6,160
  L5  1-year commitments, steady-state base only     -2,760
  L6  Oracle licence dropped at ClaimsFeed replatform-2,900
                                                    -------
  Total levers                                      -23,460

Cloud subtotal                57,400 - 23,460  =     33,940
Residual on-prem (PrintSrv host, 22 clinic print
  appliances, flagship comms rack)                  + 1,150
                                                    -------
STEADY-STATE RUN-RATE                                35,090

Board ceiling                                        42,000
Headroom                                              6,910   (16.5% under)

Three things about that block are worth more than the total. First, the ceiling is crossed at L4 — storage tiering, the lever that lives furthest from where engineers instinctively look. Second, L1 is free: it is Part 1’s homework, cashed. A team that skipped the Retire/Retain pass arrives here needing to find $5,980 from somewhere else, under pressure, with the board already unhappy. Third, the residual on-prem line goes up, and that is correct — PrintSrv was always going to stay, and a cost review that quietly forgets the kit still humming in 22 clinics is not a cost review, it is a sales pitch.

The one thing you would not optimize

☺ Like you’re 10: You saved lots of money. Now someone asks for a bit more — and the only bits left are the seatbelts.

You are $6,910/month under the ceiling. This is the moment the CFO says “excellent, find me one more” — and it is the moment the exercise is actually testing. Two seventh levers are sitting right there, both real, both easy, both wrong:

Write both refusals down, in the pack, with the numbers attached — because an undocumented refusal gets re-litigated every quarter by someone who has only seen the saving. The sentence that works in the room is short: “Both of those are available. Both convert a cost win into an outage risk, and we are already 16% under the number the board set. I will bring you a seventh lever from Artifact B’s roadmap instead.” That is the whole skill. Anyone can find savings; the job is knowing which savings are actually deferred incidents with a discount attached.

Artifact B — the 12-month modernization roadmap

☺ Like you’re 10: Now pick just two old things worth rebuilding properly — and write down why you’re leaving all the others exactly as they are.

Modernization makes the distinction this artifact rests on: migration changes where an app runs; modernization changes how it is built. Nine months of Brambleside’s project was entirely the former. This roadmap is the first time the latter is on the table — and the discipline is not choosing what to modernize, it is choosing what to leave alone and being able to say why in one sentence each.

The four tests a system has to pass to earn a slot

1. Does the business want something it currently cannot have? Not “would it be nicer” — is there a request, from a named person, that the current design blocks?
2. Do you own the code? If it is a vendor product, modernization means changing vendors, which is a procurement decision wearing an engineering costume.
3. Is there a seam? Can you carve off one slice, run it alongside the old path, and switch back in an afternoon? If not, the first piece of work is creating a seam, and that is a separate project.
4. Would a regulator have to be consulted? If yes, the timeline is theirs, not yours, and it is not a twelve-month item.

The roadmap on a page

The strangler fig, slice by slice

Architecture Patterns describes the Strangler Fig as replacing one route at a time behind a facade, with the old system live the whole way. Here is what that means concretely for BramblesideOnline. Note the seam is a routing layer keyed on URL path, sitting in front of both the old app and the new service, with an anti-corruption layer translating between the new service’s model and PIMS-Core’s booking API — so the new code never inherits the old app’s data shapes.

# Strangler fig — one-page slice template

Slice name:
Seam:                 (where the routing decision is made, and on what key)
Anti-corruption layer:(what it translates, in which direction)
Traffic share today:  __%
Shift schedule:       __% -> __% -> 100%, over __ weeks
Success measure:      (a number, with the baseline it is compared to)
Rollback:             (how traffic goes back, and in how many minutes)
Blackout conflicts:   (which windows this schedule must not cross)
Old path off:         (date, and the evidence required before that date)
Owner:                (named person, not a team)

Why nothing was refactored before 31 March — and why that was right

Not one system on Brambleside’s estate was refactored during the nine-month migration. Say that out loud in the steering committee, because someone will otherwise present it as a failure. Three reasons, in order of weight:

1. The binding constraint was a date, not an architecture. The colo contract ended 31 March with no renewal beyond a punitive month-to-month. A refactor that slipped would not have produced a worse app; it would have produced a $33,120 month-to-month bill and an estate half in and half out.
2. Changing two things at once destroys your diagnosis. Modernization states the rule plainly: never modernize and migrate the crown jewels at the same time. If PIMS-Core had been re-architected and relocated in the same Sunday window, the 04:12 question in Part 4 would have had no answerable form.
3. The team lost a person in month 3 and never replaced them. Six became five, two of whom were also on clinic support rota. Capacity was the second binding constraint, and a roadmap that ignores it is fiction.

What makes the deferral honest rather than an excuse is this artifact existing. A refactor postponed with a dated roadmap and named owners is a plan; a refactor postponed with “we’ll look at it later” is how an organization ends up running a lifted-and-shifted 2016 estate in the cloud in 2031, paying cloud prices for data-centre architecture. Anti-Patterns calls that one lift-and-shift and forget, and Artifact B is the specific document that prevents it.

Artifact C — decommissioning Fort Rusty

☺ Like you’re 10: A move isn’t finished until you hand back the old keys and stop paying rent on two houses. And you check the attic first.

Until Fort Rusty is off, Brambleside is paying for both estates and the $42,000 baseline has not gone anywhere — it has been added to. Decommissioning is not the epilogue of a migration; it is the step that realizes every saving the previous four parts earned. It is also the step that is skipped most often, because by this point everyone is tired and nothing about switching off an old server is exciting.

The power-down order

Reverse dependency order, with a gate before each block. Nothing on this list happens until the last wave’s hypercare window has closed — the old estate is your rollback right up to that moment, and The Journey is blunt about it: turning off Fort Rusty too early is a favourite gremlin trick.

The evidence you capture before anything is wiped

You will be asked for something on this list in two years, by an auditor, a regulator, or an insurer, and Fort Rusty will not exist. Capture it while the systems are still running:

• Asset register with serial numbers for every host, drive and tape — the document the destruction certificates get matched against.
• A final verified backup of every system — taken and restored into a scratch instance, with the restore evidenced.
• Configuration exports: firewall rule set, switch configs, VPN configuration, load-balancer config, vSphere inventory and host configs.
• Directory state: AD object export, GPO backup, the FSMO role holders as they stood, DNS zone exports.
• Licence keys and entitlement documents for everything being cancelled — audits happen after cancellation, not before.
• Application-level exports: PIMS-Core final database backup plus schema; StockCtrl’s controlled-drug register in a signed, immutable, regulator-readable export; ClaimsFeed’s final Oracle export.
• The address plan from Part 2, with the retired on-prem ranges marked retired rather than deleted — so nobody re-uses 10.30.0.0/16 next year and rediscovers the Ashcombe collision the hard way.
• Photographs of the racks before hand-back, plus the colo’s own inspection sheet, signed.
• A decommission certificate per system naming who authorised it and on what date.

The obligations that outlive the data centre

☺ Like you’re 10: Some papers you have to keep for seven years even after you knock the old house down. Find them a new attic, then check you can still read them.

These are Brambleside’s obligations, not a vendor’s. Handing the tapes to someone does not transfer the duty; it only transfers the box.

The contracts, their notice periods, and the deadline behind the deadline

Every one of these has a notice period, and a notice period is a date you have to hit months before the date you were watching. Miss one and the saving simply does not arrive — you keep paying for a thing you already switched off, which is the most annoying possible way to blow a cost review.

Artifact D — the one-page retro

☺ Like you’re 10: Write down what surprised you, what slowed you down, and what you’d change — honestly, including the bit where you looked silly.

Wave Planning closes every wave with a short retrospective and folds the answers straight back into the tooling and the runbook — that is what makes each wave cheaper than the last. This is the same document at project scale: one page, three columns, no blame, and at least one entry that makes you look bad. A retro with no uncomfortable line in it was written for an audience rather than for the next migration.

# Brambleside migration — retro
Date:            Attendees:            Facilitator:

## What surprised us
- (the thing nobody had on the risk register)

## What slowed us down
- (with the number: how many days, and what it cost)

## What we would change
- (a specific change to a document, a template, or an order of operations
   — not "communicate better")

## What we would keep
- (the thing that worked, so it survives the next reorganisation)

## Actions
| # | Action | Owner | By when | Where it lands |
|---|--------|-------|---------|----------------|
| 1 |        |       |         | (runbook / template / wave plan / checklist) |

Milestones

☺ Like you’re 10: Tick each box only when the thing is actually written down and the sums actually add up — not because it “sounds right.”

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

What “done” looks like for Part 5

☺ Like you’re 10: Here’s the checklist you can mark yourself against without asking anyone.

1. Your steady-state run-rate is below $42,000/month, and your before-column, saving-column and after-column each reconcile to the same three totals.
2. All six levers have a number you computed from the estate data, and no line has two levers double-counted on it.
3. You can name the thing you refuse to optimize, the exact monthly number that refusing it costs, and the one sentence you say when the CFO asks for a seventh lever.
4. Exactly two systems are named for modernization in the next twelve months, each with a first slice and a numeric success measure; every other system has a written one-sentence reason it is being left alone.
5. The strangler fig’s first slice has a seam, a traffic-shift schedule, a rollback measured in minutes, and a switch-off date that was written when the slice was planned — not afterwards.
6. Fort Rusty has a switch-off date, a power-down order in reverse dependency order with a gate before each step, and no domain controller on that list is “powered off” rather than demoted.
7. Every retention obligation has a new home, a duration, and a test that proves the data is still readable in an accepted format by someone who is not you.
8. Every contract has a notice period and a latest-notice date on a real calendar, and the earliest of those dates falls before the nearest blackout window.
9. Your retro contains at least one entry that makes you look bad, and at least one action that lands in a template or a runbook rather than in someone’s memory.
10. You can walk all five documents of the migration pack — disposition matrix, landing-zone one-pager, wave plan, cutover runbook with rollback, and this optimization-and-decommission plan — end to end, without looking anything up.

That is the capstone. Over five parts you took sixteen systems belonging to an organisation that had never done this before, decided what each one deserved, built somewhere for them to land, sequenced them across nine months with two blackouts and a hard stop, moved fifty terabytes and cut over the system every clinic touches every minute — and then, today, made it pay, chose what to rebuild, and gave back the keys. The five documents in your pack are the ones a real steering committee actually reads. Step back to Move Brambleside — Start Here to see how the parts fit together, or sharpen the individual muscles in the drills: Pick the Right R, Size the Data Move, and Write a Rollback Plan. For the theory behind this page, re-read Modernization, the cost, FinOps and DR sections of Security, Cost & Resilience, Stop 4 of The Journey, and Best Practices on watching the money — and when you run this for real, take the printable Migration Checklist with you.