A production-ready landing zone takes a few weeks. I’ve built them on GCP for a logistics-technology company in India, for Koo, and as the first deliverable on more migration programmes than I can list. Folder hierarchy, org policies, shared VPC, IAM groups, logging sinks, Terraform state split by stage. Done.
Then the programme goes quiet.
I wrote earlier that migrations are org problems first. This is the part that comes after: once the org has agreed to move, the thing that decides whether they actually use the platform is the operating model. And it rarely gets scoped.
What I mean by operating model
Four questions, answered in writing:
- Who can create a project, and what does it cost them in time? If the answer is “raise a ticket and wait two weeks”, teams will keep building on the old estate.
- Who approves a change to shared infrastructure, and how many approvals is too many? Three levels of approval on a firewall rule sounds safe. It also means the team stops asking and starts working around you.
- Where does the evidence live? When the auditor, the CFO, or the incident review asks “who changed this and why”, the answer has to be a link, not a person’s memory.
- What’s the cadence? A governance forum that meets when something breaks is an incident review with a nicer name.
That’s the product. The landing zone is packaging.
The engagement that taught me this
In 2024 I ran a two-week on-site discovery for a logistics-technology company: application dependencies, security posture, operational workflows, and a TCO model their leadership could actually decide on. We built a production-ready GCP landing zone.
And then the migration was deferred. Commercially, for good reasons. But the landing zone sat there, correct and unused, because the decision it needed wasn’t a technical one.
I don’t think that was a failure of the engagement. I think it’s the normal shape of these programmes when the operating model is left implicit. The technical work finished. The organisational work hadn’t started.
Where I’ve seen it work
At an urban and infrastructure consultancy in Singapore, on an AWS MAP Mobilize programme, the governance forums, steering discussions, and risk reviews were designed alongside the landing zone. Account structure, tagging, IPAM, and service catalogue were decisions with owners, made in a room with a cadence. Boring on paper. It’s why the artefacts got accepted.
Internally at Ollion, when we standardised how we deliver migrations, the pieces that made the biggest difference weren’t Terraform modules. They were discovery questionnaires, execution playbooks, and operating guides written for project managers, because the PMs are the ones who run the cadence when the architects have moved on to the next engagement.
The uncomfortable bit for architects
If you’re the person who designs the landing zone, you’re probably also the person best placed to design the operating model. And you probably don’t want to, because it’s meetings and RACI charts and arguing about approval counts.
Do it anyway. Decision rights, cadence, and an evidence trail are architecture. They just don’t compile.
The technical platform I hand over will be replaced in five years. The operating model, if it’s good, is what the next platform gets built on.