---
title: Application Landing Zone
description: Application landing zones adapt the platform baseline to concrete workload archetypes and migration paths with reusable patterns and controlled deviations.
sidebar:
  label: Application Landing Zone
  order: 2
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/landing-zones/application-landing-zone/"
source_file: "docs/migration/design-and-mobilize/landing-zones/application-landing-zone.mdx"
---

## Understanding Application Landing Zones

An application landing zone is a workload-specific implementation blueprint derived from the
platform landing zone baseline.

It translates enterprise guardrails into practical patterns for concrete application types,
for example VM-centric Rehost, containerized workloads, or data platform workloads.

## Why it depends on Discovery

Application landing zones are not designed in isolation. They require validated discovery input
for dependencies, data sensitivity, runtime behavior, and operational constraints.

Typical discovery-driven design inputs:

- **Dependency profile**: Inbound/outbound communication paths and trust boundaries.
- **Runtime profile**: Resource behavior, availability expectations, and scaling characteristics.
- **Data and compliance profile**: Classification, retention, and control obligations.
- **Migration strategy fit**: Rehost, Replatform, or refactor constraints for each workload.

## Typical application landing zone patterns

<CardGrid>
  <Card title="Rehost-ready pattern">
    Minimal change target for VM-based workloads with inherited central controls.
  </Card>
  <Card title="Container platform pattern">
    Segmented, policy-driven setup for Kubernetes-based workload groups.
  </Card>
  <Card title="Data workload pattern">
    Landing zone profile for data services, integration paths, and stricter controls.
  </Card>
  <Card title="Shared service pattern">
    Isolated setup for foundational services used by multiple product teams.
  </Card>
</CardGrid>

## Delivery approach

<Steps>

1. Classify workload archetypes from discovery findings and target strategy.
2. Map platform baseline controls to each archetype and identify controlled deviations.
3. Build reusable IaC templates and policy sets for each application landing zone profile.
4. Validate with pilot workloads and production-like cutover scenarios.
5. Publish templates, runbooks, and onboarding guidance for migration waves.

</Steps>

## Best practices

- **Prefer templates over one-off designs**: Reusable patterns accelerate migration waves.
- **Document deviations explicitly**: Keep risk, owner, and expiry date transparent.
- **Align with migration factory**: Integrate landing zone patterns into wave runbooks.
- **Continuously improve**: Feed migration and run feedback into the template backlog.