01 · Consolidate the Existing Estate

Milestones of the roadmap items in this theme

As of 2026-10-22 · today

Gantt

Milestones

#	Milestone	Start	Target	Status	Waits for	Team	Epic	Derived
01 · OS Administration Handover to SRE
1.1	Boundary agreed and privileged access inventoried	2026-07-13	2027-01-31	in progress	—	SRE	—	—
1.2	SRE holds privileged OS access on every host	2026-08-24	2027-03-12	in progress	1.1	SRE	—	waiting 1.1
1.3	Hardware team's OS credentials revoked	—	2027-04-23	planned	1.2	Hardware Operations	—	waiting 1.2
1.4	OS images and PXE provisioning owned by SRE	—	2027-05-28	planned	1.1	SRE	—	waiting 1.1
02 · Rebuild Existing Services under IaC
2.1	Service inventory and rebuild order	2026-07-20	2026-08-28	in progress	—	SRE	—	slipped
2.2	First service rebuilt from code and cut over	2026-08-31	2026-10-09	in progress	2.1	SRE	—	waiting 2.1 · slipped
2.3	Remaining services rebuilt in waves	—	2027-01-15	planned	2.2	SRE	—	waiting 2.2
2.4	Sweep complete, clean-slate rebuild rehearsed	—	2027-02-26	planned	2.3	SRE	—	waiting 2.3
03 · Reclaim Wasted Capacity
3.1	Utilisation baseline and reclaim accounting	2026-09-01	2026-10-16	in progress	—	SRE	—	slipped
3.2	Orphans, duplicate environments and idle reservations retired	—	2026-12-18	planned	3.1	SRE	—	waiting 3.1
3.3	Services re-provisioned at measured demand	—	2027-01-29	planned	2.3, 3.1	SRE	—	waiting 2.3, 3.1
3.4	Reclaimed capacity reported and kept visible	—	2027-02-26	planned	3.3	SRE	—	waiting 3.3
3.5	Taichung IDC retired	—	2029-06-01	planned	31.3, 10.4	SRE	—	waiting 31.3, 10.4
31 · Disaster Recovery Automation
31.1	Service tiers, recovery objectives and recovery order recorded	—	2027-07-16	planned	2.4	SRE	—	waiting 2.4
31.2	The rebuild runs from one pipeline, in dependency order	—	2028-01-14	planned	31.1	SRE · Platform Engineering	—	waiting 31.1
31.3	A whole-estate rehearsal against a cold target, timed	—	2028-12-01	planned	31.2, 6.3, 8.4, 12.1	SRE · Platform Engineering	—	waiting 31.2, 6.3, 8.4, 12.1
31.4	The rehearsal is scheduled, unattended, and a regression fails	—	2029-04-06	planned	31.3	SRE	—	waiting 31.3

Details

1.1Boundary agreed and privileged access inventoried2027-01-31in progress · 3/3

• RACI for the hardware/OS split, signed off by both teamsowner · Charles

  Firmware, BMC/Redfish and physical access stay with hardware operations; OS image, PXE, bootloader and everything above go to SRE.
• Host inventory with each host's current admin pathowner · Charles
• Privileged account and key inventoryowner · Charles

  Local accounts, shared root, authorized_keys and sudoers on every host — the baseline the 1.3 sweep is diffed against.

1.2SRE holds privileged OS access on every host2027-03-12in progress · 1/4

• SRE admin path established on every hostowner · Charles
• SSH through the SRE bastion path, per-user identities instead of shared keysowner · TBD

  Static keys now; the target state is short-lived certificates from the dynamic secrets engine (item 12), so nothing here should assume a key that outlives a session.
• sudo policy as code, no shared root passwordowner · TBD
• Session and command audit shipped to the log platformowner · TBDarchitecture →

1.3Hardware team's OS credentials revoked2027-04-23planned · 0/4

• Remove hardware-operations local accounts and keys from every hostowner · TBD
• Confirm BMC/Redfish and physical access stay with hardware operationsowner · TBD

  The out-of-band boundary is what makes the separation work — this task protects it rather than removing it.
• Break-glass procedure for OS access, sealed and auditedowner · TBD
• Verification sweep: no OS credential outside SREowner · TBD

  Re-run the 1.1 inventory and diff it; the sweep is the evidence the handover is complete.

1.4OS images and PXE provisioning owned by SRE2027-05-28planned · 0/4

• SRE-owned base OS images, built from codeowner · TBD
• PXE / provisioning service moved to SREowner · TBD
• Patching and OS lifecycle ownership recorded, on-call updatedowner · TBD
• Handover runbook published on the portalowner · TBD

2.1Service inventory and rebuild order2026-08-28in progress · 3/3

• Inventory of services predating the declarative framework, with owner and dependenciesowner · Charles
• Rebuild order by risk and blast radiusowner · Charles

  Lowest blast radius first, so the template is proven on something recoverable; the services everything else depends on go last.
• Cutover and rollback criteria agreed per serviceowner · Charles

  What "equivalent to the original" means, and the point at which the original is retired rather than kept warm.

2.2First service rebuilt from code and cut over2026-10-09in progress · 1/4

• Rebuild the first service from code beside the running instanceowner · Charles
• Equivalence check against the original before cutoverowner · TBD

  Same configuration surface, same data, same integrations — verified while both are running, which is the point of build before break.
• Cut traffic over and retire the originalowner · TBD
• Extract the reusable rebuild template from what it tookowner · TBD

  The deliverable of the first service is the template; without it every wave repeats the same discovery.

2.3Remaining services rebuilt in waves2027-01-15planned · 0/4

• Wave 1 rebuilt and cut overowner · TBD
• Wave 2 rebuilt and cut overowner · TBD
• Wave 3 — the services others depend on — rebuilt and cut overowner · TBD

  Last by design — highest blast radius, and by now the template has been exercised on everything else.
• Originals retired, not left runningowner · TBD

  A rebuild that leaves the original running has moved nothing; the capacity it frees is what item 03 measures.

2.4Sweep complete, clean-slate rebuild rehearsed2027-02-26planned · 0/4

• Verification sweep against the 2.1 inventory: no service left outside IaCowner · TBD
• Clean-slate rebuild rehearsal in an isolated environmentowner · TBD

  Rebuild a representative slice from code alone, with no access to the running estate — this is what makes the sweep a DR capability rather than a tidy-up.
• Recovery time and the gaps the rehearsal found recordedowner · TBD
• Rebuild runbook published on the portalowner · TBD

3.1Utilisation baseline and reclaim accounting2026-10-16in progress · 0/4

• Reconcile the VM inventory against what actually reports to Mimir; close the gap or record each exclusionowner · Charles

  Most VMs report today, not all. A host missing from Mimir is missing from the baseline, and those hosts are the orphan candidates 3.2 goes looking for — so this list is an input to 3.2, not just a data-quality chore.
• Utilisation measured per VM and per volume over a full cycle, from Mimirowner · Charles

  A week of peaks, not an instantaneous reading — an inherited size is usually defended by a peak nobody has re-measured.
• Definition of "reclaimed" agreedowner · TBD

  Capacity counts as reclaimed when it is back in the pool and available to another workload — not when a VM is merely powered off.
• Baseline recorded as the reference every later number is measured againstowner · TBD

3.2Orphans, duplicate environments and idle reservations retired2026-12-18planned · 0/4

• Orphaned VMs identified — including the hosts 3.1 found missing from Mimir — with a claim window for ownersowner · TBD

  Nothing is deleted on silence alone — an unclaimed VM is powered off first and removed after a stated quarantine, so a wrong call stays recoverable.
• Duplicate and stale environments retiredowner · TBD
• Idle reservations releasedowner · TBD
• Orphaned volumes, snapshots and backup retention reviewedowner · TBD

3.3Services re-provisioned at measured demand2027-01-29planned · 0/3

• Size from the 3.1 measurements at rebuild, not from the inherited specowner · TBD
• Sizing recorded in the IaC definition, not applied by handowner · TBD

  A hand-tuned size is lost at the next rebuild; doing this during item 02's waves is what makes the new size code.
• Headroom and scaling policy stated per serviceowner · TBD

3.4Reclaimed capacity reported and kept visible2027-02-26planned · 0/3

• CPU, memory and storage reclaimed, reported against the 3.1 baselineowner · TBD
• Utilisation dashboard published in Grafana, refreshed from the same Mimir source as the baselineowner · TBDarchitecture →

  Same source as 3.1, so the report and the baseline cannot drift apart into two different numbers.
• A re-check scheduled so inherited sizing does not creep backowner · TBD

  The sweep is worth little if sizes drift back next quarter; the scheduled check is what makes the reclaim durable.

3.5Taichung IDC retired2029-06-01planned · 0/4

• Gated on a passed whole-estate rehearsal, not on a dateowner · TBD

  Card 03 retires the site because the rebuild capability is what restores service, not the standing hardware. 31.3 is where that stops being a claim. Naming the gate here puts the reason for the date on the page rather than only in the dependency arrow.
• Workloads and names moved or retired, with 10.4 done firstowner · TBD

  Zone B answers the same FQDNs as A and C. Pulling the site before the names are repointed takes out services that were never in it.
• Hardware decommissioned and the reclaim counted against 3.1's baselineowner · TBD

  Retiring a whole site is the largest reclaim in item 03, and it is only visible as a reclaim if it lands in the same accounting as the rest.
• The two-site end state recordedowner · TBD

31.1Service tiers, recovery objectives and recovery order recorded2027-07-16planned · 0/4

• Services sorted into tiers by what the business cannot run withoutowner · TBD
• An RTO and an RPO per tier, derived from 2.4's measured recovery time and provisional until the business confirms themowner · TBD

  Neither appears anywhere in the roadmap today. Without them "recovered" has no definition and an automated rehearsal has no pass or fail. Deriving beats inventing: 2.4 already records recovery time and the gaps its rehearsal found.
• Recovery order taken from 2.1's rebuild order, not re-derivedowner · TBD
• What is explicitly not covered by the objective, namedowner · TBD

  An objective that silently covers everything is one nobody can meet. Naming the exclusions is what makes the rest of it credible.

31.2The rebuild runs from one pipeline, in dependency order2028-01-14planned · 0/4

• One pipeline rebuilds the estate in dependency orderowner · TBD
• No step depends on a person reading a runbookowner · TBD

  A runbook is a recovery plan that assumes the person who wrote it is available, awake, and right — three assumptions the event tends to break at once.
• Secrets and credentials reach the rebuild with no human in the pathowner · TBD

  The most common way a rehearsed recovery stalls in the real event: the automation works and nobody can give it the credential it needs.
• The same pipeline runs in the rehearsal and in the real eventowner · TBD

  A separate "real" procedure is a second thing to keep correct, and the one that has never been run is the one that will be.

31.3A whole-estate rehearsal against a cold target, timed2028-12-01planned · 0/4

• The whole estate rebuilt against a cold target, in one runowner · TBD

  Seven component rehearsals exist — 8.4, 12.1, 2.4, 27.3, 6.3, 14.4, 28.8 — and none of them has ever been run together. The event they stand in for is none of those things.
• Timed against 31.1's objectives, with the result recordedowner · TBD

  The done-criterion is a measured result, not that the rehearsal was held. A rehearsal whose outcome is never compared against a target is an exercise, not a test.
• Gaps recorded as work, not as observationsowner · TBD
• No dependency drawn on 14.4, 27.3 or 28.8owner · TBD

  28.8 lands 2029-02-22, after this milestone. Waiting for it would hold the first whole-estate rehearsal back by a quarter for one component. What is rehearsed here is the estate that exists by then; the later component rehearsals join the scheduled run at 31.4.

31.4The rehearsal is scheduled, unattended, and a regression fails2029-04-06planned · 0/4

• The rehearsal runs on a schedule, unattendedowner · TBD
• A regression fails like a build does, with an ownerowner · TBD

  6.3's line one level up — a backup nobody has restored is a hope with a cron entry, and a recovery capability exercised once is a fact about one afternoon.
• Each run's time compared against the objective, and the trend visibleowner · TBD

  Recovery time drifts upward as the estate grows, and the run that first exceeds the objective should be a failure rather than a surprise during an incident.
• Component rehearsals from 14.4, 27.3 and 28.8 folded in as they landowner · TBD

Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.