Landing Zones Without Business Context

Spurious Egregious Lending Limited (or SELL!) is a fictional company used to illustrate how things can go wrong when you rush to deploy a landing zone without understanding the business context.

Any resemblance to a real platform team’s war story is, unfortunately, the point.

Setting the Scene

Monday morning at SELL!, a Wellington fintech with eighty staff and a lending product that needs to scale. The investment deck has said “cloud-first transformation” seventeen times. Capital is raised. The board is ready.

“Board wants us in the cloud by third quarter. Make it happen.”

The CTO passes it down. The team meets once, lands on a plan, and puts it in the next sprint: deploy the reference landing zone, iterate later. Deadline first, backlog second.

The Pilot: The Accelerator Works Perfectly

And without business context, it does. At the end of the sprint at week two, Spurious Lending has:

The architecture diagrams look great. The CTO shares them with the board and congratulates the team on a job well done.

The Workload Nobody Mapped

The mandate of “third quarter” gives no time to map the workload’s dependencies, and so, given the criticality of the application and discussion with the product team, the platform team decides to do a lift and shift. Migration will be done over a single weekend, everything at once.

The product team does not fully understand the landing zone’s architecture or policy assignments, and so the platform team does not fully understand the workload’s dependencies. The two halves of the company are about to meet for the first time.

A landing zone is an architectural expression of your organisation’s compliance and governance requirements. Microsoft make it easy to deploy one, but your governance, security, and compliance requirements are not encoded in the accelerator.

Nobody asked the only two questions that mattered: what data sovereignty or residency requirements apply, and what compliance requirements apply. The application handles credit information. The accelerator defaulted to Australia East. The FAQ below covers both, including where DR replicas should live. Those answers come due in Part 2.

Migration Day: The Weekend Cutover

On migration day, the product team’s deployment fails. Exemptions go out by hand, one policy at a time. Each failure is treated as a new problem rather than evidence of a missing intake process.

The weekend window was Saturday plus a Sunday recovery day. By Tuesday night, three days of troubleshooting later, two of them unplanned, the application can finally see its data. But the cutover was declared done with pieces still straddling both worlds: one application server was left on-premise “temporarily,” and the file share the batch jobs read from was never migrated at all. Both still straddle the circuit at week eighteen.

So what happened?

The accelerator deployed without issue. The workload landed on it in pieces. The landing zone was built for no particular workload, then handed one.

Post-Migration: The Cracks Widen

The workload is up. Then the first real business day begins, and the cracks widen.

Latency Issues

The on-premise SQL Server sat ten metres from the application servers. On the landing zone, the nightly batch job, a four-hour credit reconciliation running against the bureau data, now pulls its inputs over an ExpressRoute circuit from that unmigrated file share, because nobody inventoried the data flows. The four-hour batch becomes eleven hours, overrunning the bureau’s processing window. The 9am loan approval reports are late, and Ross, who runs operations from the Petone floor, asks why “the cloud” is slower than the server room.

Latency bites the interactive paths too. The application server left on-premise during the weekend cutover now makes thousands of chatty database calls across the circuit for every loan application. Approval times triple. Nobody had profiled the chatter because the assessment was a checklist, not a design exercise.

Compliance Issues

Tui, the compliance lead, catches the remediation work during its third attempt. Her questions are short and the landing zone answered none of them.

The database holding credit information falls under the Privacy Act 2020 and Credit Reporting Privacy Code, and the landing zone’s DR guidance pointed at a paired region in Australia. That was not automatically unlawful, but it was never assessed as an offshore disclosure with comparable safeguards. “Not a residency law” was treated as “any region is fine.” It was a default nobody caught. Meanwhile the policies still allowed engineers to deploy anywhere on Earth.

And then: centralised logging now ships the workload’s logs, containing customer PII, to a workspace that half the platform team can read. Privacy by design, inverted.

Then Sales signs a pilot with a government agency, and procurement forwards a questionnaire asking for an NZISM control mapping and evidence of a completed cloud risk assessment. The platform team spends the next four weeks remediating: region restrictions written after the fact, log access redesigned, the bureau integrations and on-premise data flows documented for the first time, and an unpleasant conversation with the agency’s assessor about why the architecture diagrams predate the workload they claim to host.

The board deadline is the last day of Q3. Cutover is week eight, a fortnight before that date, and still incomplete. Four weeks of Tui’s remediations push the programme into Q4. The CEO asks why the thing that “worked perfectly” in week two cannot host one application by the date the board was given.

Monitoring Issues

The workload’s alerting never made it to the new Log Analytics workspace. The monitoring that existed on-premise died with the cutover. The empty workspace from week two is still empty.

The Lessons We Can Learn

Nothing about the eventual architecture was wrong. The hub-spoke network was fine. The management group hierarchy was fine. What was wrong was the order: the landing zone was built for no particular workload, then handed one.

The accelerator never asked what workload would live on the platform. It could not. It deployed Microsoft’s defaults flawlessly, to a problem it had never been introduced to.

The Moral

A landing zone is an architectural expression of your organisation’s obligations and its actual workloads. Spurious Lending built one from defaults, then discovered both, obligations and workloads, one outage at a time. Two weeks of deployment bought them eight weeks of retrofit, a slipped deadline, and an auditor’s first impression they never fully recovered from.

The test: can you name the workload, its data flows, and the regulations covering its data before the first terraform apply? If not, you are deploying an accelerator, not designing a platform.

If you want that work structured as an engagement, see Fractional Cloud Architecture and Advisory.