The landing zone shipped. The pilot worked. Nobody clapped. This is the series about what happens next.
The moment the programme ends
There is a specific week in every landing zone programme that nobody writes about. It is not go-live. It is not the first production workload. It is the week the programme formally ends — steering committee wound down, delivery leads reassigned, the sponsor’s update now a quarterly bullet in someone else’s pack — and the platform team looks up from their backlog and realises:
Nobody is coming to help anymore.
The landing zone is live. The guardrails work. Onboarding takes days instead of weeks. And the organisation has done what organisations do: moved its attention to the next programme. The migration that justified the whole thing is now someone else’s problem. The platform, which spent two years as the centre of gravity for a well-funded initiative, is now an internal service with a cost, a small team, and no obvious owner above it.
This series is about those years. The operating years — two, three, sometimes four — after the build. Because that is where landing zones actually succeed or die, and almost nothing is written about it.
If the first series (Before You Deploy) was about the mistakes that show up before anything is deployed, and the second (Success Patterns) was about the messy middle of the programme itself at fakey.xyz, this is the third act. The one where the platform outlives its mandate.
Three numbers that changed everything in year two
When I review platforms in their operating years, I ask three questions before anything else. Not about architecture — about the numbers that decide whether the platform survives contact with “business as usual.”
1. Run cost, and whether anyone thinks it is theirs.
During the programme, platform costs were programme costs. Central, justified by the business case, invisible. Year two is when finance discovers the run rate and asks the question: whose budget is this now?
This sounds like an accounting formality. It is not. It is the moment the platform stops being infrastructure and becomes a cost centre with a name attached — usually the platform team’s manager, who now has to justify their team’s existence against a cloud bill in a way they never signed up for. We will spend a full part on this (Part 2), because showback-to-chargeback is where more platform teams get mortally wounded than in any outage.
2. Tenant count, and what “tenant” actually means.
Most platform teams cannot answer this precisely, and that is diagnostic. Is it subscriptions? Workload teams? Business units? The number matters because it is the denominator for every conversation that follows: cost per tenant, onboarding time, support load, the ROI slide nobody has had to produce yet.
But the definition matters more than the number. If “tenant” means “everyone who ever touched a subscription,” you will overstate your reach and understate your support burden. If it means “teams who would riot if the platform disappeared tomorrow,” you will probably get a much smaller number — and a much more honest starting point. The gap between those two definitions is where a lot of year-two anxiety lives.
3. Platform team attrition, and what walked out the door.
You will hear this theme again in Part 7, but it belongs here because it starts early. Landing zone teams are small — often fractional, often assembled for the programme, often holding knowledge that lives in their heads rather than the repo. The moment the programme ends and the work becomes “operating a platform” rather than “building something new,” the interesting-kind-of-hard work changes character, and some people decide they would rather be elsewhere.
I have reviewed platforms where one resignation undid eighteen months of capability. The warning signs were visible in year one. Nobody was looking.
Who is this platform for now?
Here is the uncomfortable question at the heart of the operating years. During the programme, the answer was clear: the platform existed to serve the migration. It had a sponsor, a business case, and a date. When those expire, the platform needs a new reason to exist — and very few organisations do this deliberately.
In practice, one of three things happens:
The platform becomes a product. Someone — usually the platform lead, occasionally an enlightened leader above them — reframes the work. Tenants become customers. Onboarding becomes a funnel. There is a roadmap, release notes, a version of product management applied to internal infrastructure. This is the good path, and it is rarer than the conference talks suggest, because it requires the organisation to fund internal product management, which finance often cannot distinguish from headcount.
The platform becomes a utility. Nobody champions it; it just works. Workloads deploy, guardrails hold, and the platform team quietly becomes part of the infrastructure furniture. This sounds like failure but is not necessarily — invisible is the goal, as the second series finale ended on. The risk is that invisible platforms do not get funded, do not get headcount, and get “consolidated” in the next restructure. Survival as a utility requires someone keeping political visibility alive while staying operationally quiet. Part 5 is about that tension.
The platform becomes a fossil. The team keeps the lights on, drifts from the provider, stops onboarding anyone new because onboarding is manual and the person who understood it has left. The estate keeps growing — workloads built on the platform because it was there — and nobody is steering. Fossils are usually discovered during an incident, an audit, or a restructure. Not always fatal, but every operating-year problem in this series is worse on a fossil.
The path is not chosen in a meeting. It accretes, decision by non-decision, through year two. Which is why naming the question early is worth more than any framework.
What this series covers
Nine parts after this one, roughly in the order the problems arrive:
- Part 1 — The second wave. The legacy estate that was always coming, and what it does to an opinionated platform.
- Part 2 — Showback becomes chargeback becomes politics. The money conversation, and the meeting where the platform has to justify itself.
- Part 3 — Platform team as product team. What adopting (or refusing) product management actually costs.
- Part 4 — Guardrails meet the first real exception. Waivers, registries, and the slow rot of exceptions-as-norm.
- Part 5 — The invisible platform’s paradox. Success is silence, silence does not get funded, and the slide that saved a team.
- Part 6 — Platform drift. The provider moves, the landing zone does not, and running a major upgrade underneath people who did not know they were standing on it.
- Part 7 — Key person risk. The bus number of one, tribal knowledge, and the archaeology after the handover that was not.
- Part 8 — Platform vs. the hyperscaler’s native answer. When the provider ships 70% of what you built, and what your real value-add turns out to be.
- Part 9 — The three-year review. What it cost, what mattered, and the handoff question: what did we leave that someone else can actually run?
The through-line is deliberate: this series picks up where the fakey.xyz narrative ended — a platform going invisible after the Petone exit — and follows the logic through. Several themes get their sequel here: fractional capacity (Part 7), decommissioning as a deliverable (Part 8), operating models under pressure (Parts 2 and 5).
Parts 2, 4, and 6 are the most under-written topics in landing zone literature — lead with those if you are staggering publication.
A note on how I am using “the operating years”
I am deliberately vague about timelines because the clock does not run on calendar months — it runs on events. Some organisations hit the chargeback conversation six months after programme close; others take three years because finance is looking elsewhere. The sequence of problems is remarkably consistent across NZ organisations of similar size; the pacing is not.
So treat “year two” and “year three” as shorthand for the stage where this becomes the live problem, not a schedule.
Who this is for
The same readers as before: cloud architects, DevOps engineers, and delivery leads. But the centre of gravity shifts. If the first series was for people starting a landing zone programme and the second for people in one, this is for the people who discover — usually with some surprise — that they are now running one.
You will not find reference architecture here. No topology diagrams, no policy-as-code snippets. The failure modes of the operating years are almost never technical. They are about budgets nobody wants to own, teams nobody wants to fund, exceptions nobody wants to refuse, and knowledge nobody wrote down. The architecture is the easy part now. That is exactly the problem.
One Block · build from here
Next: Part 1 — The second wave arrives. The migration programme got the easy workloads. Now comes the legacy estate everyone politely avoided, and the landing zone has to take it — or the programme misses its target.