Landing Zones Without Business Context

Spurious Lending Limited, is a mid-sized fintech company in Wellington. With eighty staff, a rapidly growing lending product, they are fresh off a capital raise that mentioned “cloud-first transformation” in the investor deck at least seventeen times.

It’s Monday morning. The CEO forwards the board’s digital strategy to the CTO with one line: “Board wants us in the cloud by third quarter. Make it happen.”

The CTO talks to their senior engineer who brings it to the team. After a team meeting, they agree on a plan. “We need a landing zone. We have a deadline and a full backlog. Let’s deploy the reference implementation and iterate from there.” The team agrees and the project is added to the next sprint.

The Azure Landing Zone 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 dicussion with the product team, the platform team decides to do a lift and shift. Migration will be done over a weekend.

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 organisations compliance and governance requirements. Microsoft make it easy to deploy one, but your governance, security, and compliance requirements are not encoded in the accelerator.

What data sovereignty or residency requirements apply?

The landing zone accelerator defaults to Azure Australia East. While neither the Privacy Act 2020 nor the Credit Reporting Privacy Code mandates New Zealand storage, putting personal or credit information in an overseas region is usually an offshore disclosure. You need comparable safeguards, not an accelerator default.

The platform policies still allow engineers to deploy anywhere. Contracts, customer questionnaires, NZISM for agency work, RBNZ outsourcing expectations, and board risk appetite often pin location harder than the statute. Many New Zealand teams will choose Azure New Zealand North as policy because an in-country story is simpler to defend.

What compliance requirements apply?

The application handles credit information, so the Privacy Act 2020 and Credit Reporting Privacy Code both apply: purpose, access, security, and those offshore disclosure gates — including for DR replicas. It does not mean “must store in New Zealand.”

What security requirements apply to the workload?

What performance requirements apply to the workload?

What operational requirements apply to the workload?

What regulatory requirements apply to the workload?

What legal requirements apply to the workload?

What business requirements apply to the workload?

Migrate Day: The Migration Stalls

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.

Three days of troubleshooting later, the application can finally see its data. So what happened?

The landing zone accelerator worked perfectly. The workload was lifted and shifted onto the landing zone without issue. But the workload was not mapped to the landing zone’s design. The landing zone was built for no particular workload, then handed one:

Spurious Lending did — Built the LZ, then met the workload Should have done — Spent week one inventorying the workload: server specs, IP scheme, SQL dependencies, data flows, integrations, alerting

Spurious Lending did — Let root policies deny first, exempt later Should have done — Set policy with a documented exception process before the first migration

Spurious Lending did — Discovered the on-premise IP conflict at cutover Should have done — Reconciled the source addressing plan with the landing zone’s design, and allowed for the overlap, before day one

Spurious Lending did — Assumed the SQL Server would lift as-is Should have done — Run an actual SQL assessment: linked servers, Agent jobs, compatibility level, hard-coded hostnames

Spurious Lending did — Discovered latency in production Should have done — Mapped every cross-premises data flow — file shares, batch jobs, chatty app-to-database traffic — and profiled it before cutover

Spurious Lending did — Let DR defaults point offshore, with no region restriction Should have done — Written an allowed-regions position: IPP 12 / Rule 12 safeguards for any offshore choice, plus contracts, NZISM, and board appetite checked — many teams pick Azure New Zealand North as policy because it is simpler to defend

Spurious Lending did — Centralised logs without classifying them Should have done — Decided what the logs contain, who may read them, and how long they’re kept before shipping PII to a shared workspace

Week 7: The Latency Crack

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

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 a file share still on-premise, because nobody inventoried the data flows and nobody migrated that share. The four-hour batch becomes eleven hours, overrunning the bureau’s processing window. The 9am loan-approval reports are late, and the operations manager’s first question is why “the cloud” is slower than the server room.

Latency bites the interactive paths too. An application server left on-premise during the phased 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.

And the third crack: 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.

Week 8: The Compliance Crack

Tui, the compliance lead, catches the migration 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.

Worse: 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.

Meanwhile the migration slips past Q3, and the CEO asks why the thing that “worked perfectly” in week two can’t host one application in week eight.

What Spurious Lending Should Have Done First

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:

Spurious Lending did — Built the LZ, then met the workload Should have done — Spent week one inventorying the workload: server specs, IP scheme, SQL dependencies, data flows, integrations, alerting

Spurious Lending did — Let root policies deny first, exempt later Should have done — Set policy with a documented exception process before the first migration

Spurious Lending did — Discovered the on-premise IP conflict at cutover Should have done — Reconciled the source addressing plan with the landing zone’s design, and allowed for the overlap, before day one

Spurious Lending did — Assumed the SQL Server would lift as-is Should have done — Run an actual SQL assessment: linked servers, Agent jobs, compatibility level, hard-coded hostnames

Spurious Lending did — Discovered latency in production Should have done — Mapped every cross-premises data flow — file shares, batch jobs, chatty app-to-database traffic — and profiled it before cutover

Spurious Lending did — Let DR defaults point offshore, with no region restriction Should have done — Written an allowed-regions position: IPP 12 / Rule 12 safeguards for any offshore choice, plus contracts, NZISM, and board appetite checked — many teams pick Azure New Zealand North as policy because it is simpler to defend

Spurious Lending did — Centralised logs without classifying them Should have done — Decided what the logs contain, who may read them, and how long they’re kept before shipping PII to a shared workspace

The accelerator never asked what workload would live on the platform. It couldn’t. 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.

Before you run the accelerator, inventory the workload that will move onto it and the three NZ regulations that apply to its data. If either list is blank, discovery is the work — not deployment. If you want that work structured as an engagement, see Fractional Cloud Architecture and Advisory.