Landing Zone
A landing zone is a pre-built, governed environment — organizational or technical — into which new capabilities, business units, or workloads are placed so they can operate safely and consistently from day one.
Definition
In enterprise architecture, a landing zone most commonly refers to a pre-configured cloud environment — accounts, network topology, identity controls, security guardrails, and compliance baselines — established before any workload is deployed. Instead of provisioning infrastructure ad hoc for every new application, architects stand up a landing zone once, then route new capabilities into it, ensuring every workload inherits the same governance, security posture, and operational standards. Business architects use the same underlying idea in a broader sense: a landing zone is the defined target environment — process, data, organizational, and system — that an incoming capability, acquired business unit, or migrated function is placed into during a transformation. It is not the end-state operating model itself; it is the receiving structure that absorbs change in a controlled way while the broader target operating model is still being finalized. Think of it as a staging ground with guardrails, not a permanent home. The critical boundary to understand is that a landing zone is about controlled placement, not final design. A target operating model defines how the business will ultimately run; a landing zone defines where and how something lands safely in the interim, with governance already in place, so integration doesn't create chaos, security gaps, or capability duplication.
Origin & Context
The term originated in cloud computing around 2017-2018, popularized by AWS and Microsoft Azure as a packaged set of governance, networking, and security configurations for multi-account cloud environments. Enterprise and business architects subsequently borrowed the concept to describe any pre-governed receiving structure for change — extending it into M&A integration, divestitures, and large-scale capability migrations, where the same principle of 'land safely first, optimize later' applies to organizational and process change, not just infrastructure.
Why It Matters
CIOs and cloud architects care because a well-designed landing zone prevents the security gaps, compliance violations, and cost sprawl that come from teams provisioning environments independently. Business architects care because in M&A and divestiture scenarios, a defined landing zone lets an acquired unit's capabilities begin operating under enterprise governance immediately, rather than waiting months for a fully negotiated target operating model. For regulated industries, the landing zone is often where auditors and risk officers focus first, since it is the enforcement point for controls during a period of maximum organizational vulnerability.
Common Misconceptions
- Myth: A landing zone is purely a cloud/IT concept with no relevance to business architects.
- Reality: While the term originated in cloud infrastructure, business architects apply the same logic to organizational and process integration — particularly in M&A, where an acquired unit needs a governed operating environment before its capabilities are fully harmonized into the target operating model.
- Myth: Once a landing zone is built, it's the permanent home for whatever is placed in it.
- Reality: A landing zone is intentionally an interim, controlled structure. Capabilities or workloads placed there are expected to be rationalized, optimized, or migrated further once the target state is fully defined — treating it as permanent leads to accumulated technical or organizational debt.
- Myth: A single landing zone works for every capability or business unit entering the enterprise.
- Reality: Mature organizations design multiple landing zone patterns calibrated to risk profile — a highly regulated payments capability needs different guardrails than a low-risk internal tool, just as an acquired unit in a tightly regulated market needs a different integration landing zone than one in an adjacent, lightly regulated line of business.
Practical Example
A regional bank acquires a smaller digital lender. Rather than waiting for a fully negotiated target operating model, the enterprise architecture team, working with the business architecture lead, defines a landing zone: the acquired lender's loan origination and underwriting capabilities are mapped against the bank's capability map, placed into a segregated but governed technology environment, and subjected to the bank's existing risk, compliance, and data-security controls immediately post-close. Business architects produce a capability cross-mapping showing which acquired capabilities are duplicates, which are unique and should be preserved, and which need interim workarounds. This lets the combined entity begin serving customers under one governance framework right away, while the harder decisions — which loan origination platform ultimately survives, how underwriting processes get rationalized — are worked through over subsequent quarters without operational or regulatory risk in the interim.
Industry Applications
- Financial Services
- Used to onboard acquired institutions or fintech partnerships into a governed environment that satisfies regulatory and data-security requirements before full systems integration is complete.
- Healthcare
- Applied when a health system acquires a physician group or hospital, giving newly acquired provider capabilities a compliant environment for clinical data and billing before full EHR and revenue-cycle harmonization.
- Technology & Software
- Used in its original cloud form — a pre-governed multi-account structure that lets product teams launch new capabilities on standardized security and networking guardrails without waiting for custom infrastructure approval.
Related Terms
- Business Capability: The unit of analysis placed into or evaluated against a landing zone