---
title: "VM Application Landing Zone for Relocate"
description: "Technical blueprint for creating a VM application landing zone with the STACKIT Accelerator, manual security groups, and Coriolis or Acura handoff."
scfAsset:
  managed: false
  category: "blueprint"
  external: false
  tags: ["design-and-mobilize", "landing-zone", "relocate", "vmware", "vm", "opentofu", "coriolis", "acura"]
  maintainers:
    - user: "lukas.weberruss"
source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/vm-application-landing-zone-relocate/"
source_file: "docs/migration/assetcontainer/stackit/vm-application-landing-zone-relocate.mdx"
---

## Purpose

Use this blueprint to create the Application Landing Zone for a VM-based Relocate wave. It keeps
the shared Platform Landing Zone, the workload project baseline, and the migrated workload clearly
separated while giving Coriolis or Hystax Acura a controlled target in which to deploy.

## Landing zone and workload boundary

The Platform Landing Zone supplies organization-wide governance, connectivity, identity, audit,
and automation capabilities. The STACKIT Landing Zone Accelerator then creates one Application
Landing Zone project for the workload and environment. Security Groups form an explicit manual
approval gate before migration tooling or VMs enter that project.

```d2
vars: {
  d2-config: {
    pad: 32
  }
}

style.font-size: 22
direction: right

Platform: "Platform Landing Zone" {
  Governance: "Governance and IAM"
  Connectivity: "Shared connectivity and DNS"
  Operations: "Audit and automation baseline"
}

Application: "VM Application Landing Zone" {
  direction: right

  Accelerator: "Accelerator baseline" {
    Project: "STACKIT project and RBAC"
    Network: "Routed network and DNS zone"
    Secrets: "Secrets Manager and automation identity"
    Storage: "Object Storage and state bucket"
    Observability: "Observability endpoint"
  }

  Security: "Manual gate" {
    Groups: "Security Groups"
    Approval: "Rule review and approval"
  }

  Accelerator -> Security: "baseline ready"
}

Workload: "Tool and workload content" {
  Tool: "Coriolis or Hystax Acura"
  VMs: "Migrated VMs and volumes"
  Telemetry: "Guest metrics, logs, and backup"
}

Platform.Connectivity -> Application.Accelerator.Network: "inherit shared route policy"
Platform.Governance -> Application.Accelerator.Project: "inherit guardrails"
Application.Security -> Workload: "approved ingress and egress"
```

The boundary is deliberate:

- **Landing Zone responsibility**: Project, roles, routed network, DNS zone, Secrets Manager,
  Object Storage, automation identity, optional Observability instance, labels, and shared routing.
- **Manual security responsibility**: Security Groups and their workload-specific ingress and
  egress rules are reviewed and created before tool deployment.
- **Workload responsibility**: Migration appliances, migrated servers and volumes, guest
  configuration, application dependencies, backup policies, and telemetry agents.

## What the Accelerator provisions

Create one Accelerator `landing_zones` entry per workload environment. For a private VMware target,
use a corporate landing zone connected to the approved Network Area and enable Observability.

```hcl
landing_zones = {
  "erp-prod" = {
    project_name          = "ERP Production"
    project_code          = "erp"
    owner_email           = "platform-owner@example.com"
    env                   = "prod"
    corporate             = true
    network_area_key      = "default"
    network_prefix_length = 24
    secretsmanager_enabled = true

    observability = {
      enabled   = true
      plan_name = "Observability-Starter-EU01"
      acl       = ["approved-admin-cidr"]
    }

    role_assignments = [
      {
        role    = "project.owner"
        subject = "migration-automation@example.com"
      }
    ]
  }
}
```

After `tofu apply`, capture the project ID, landing-zone type, connected Network Area ID, DNS zone,
Secrets Manager instance ID, Observability instance ID, Grafana URL, and metrics push URL. These
outputs become controlled inputs for the migration wave, not values chosen during cutover.

The Accelerator does not create migrated VMs, workload disks, guest agents, or Security Groups in
this module. It creates the governed project baseline into which those resources are deployed.

## Manual Security Group gate

Create Security Groups only after the dependency matrix and tool path are approved. Keep the rule
set version-controlled even when the initial creation is manual.

Review the default ingress and egress behavior before writing the approved rule set. Explicitly
test same-group traffic and outbound restrictions rather than assuming every direction is denied
by default. Resolve migration-tool ports from the selected tool's documentation.

> From the STACKIT docs: [Concepts › Security rules](https://docs.stackit.cloud/products/network/core-networking/security-groups/basics/concepts/#security-rules) (Source updated 19.11.2025, copied 06.10.2026)

Security Group rules define which traffic is allowed or denied. Each rule specifies:

- **Direction**: Whether the rule applies to incoming traffic (ingress) or outgoing traffic (egress)
- **IP Protocol**: The network protocol (TCP, UDP, ICMP, or any protocol)
- **Port Range**: The specific port or range of ports affected by the rule (for TCP/UDP)
- **Source/Destination**: IP addresses or CIDR blocks that the rule applies to

### Default behavior

When you create a new Security Group, it includes a default security policy:

- **Egress (Outbound)**: All outgoing traffic is allowed by default
- **Ingress (Inbound)**: All incoming traffic is blocked by default, with one important exception—traffic from instances within the same Security Group is allowed

The default deny-all ingress policy ensures that your servers remain protected until you explicitly allow specific traffic. This “deny by default” approach prevents accidental exposure of services to the internet and helps maintain a strong security posture.

### Ingress rules

Ingress rules control incoming traffic to your servers. You must explicitly create ingress rules to allow:

- External access to your applications (e.g., HTTP/HTTPS traffic on ports 80/443)
- Management access (e.g., SSH on port 22 or RDP on port 3389)
- Custom application traffic on specific ports
- Traffic from specific IP addresses or ranges

### Egress rules

Egress rules control outgoing traffic from your servers. By default there is a rule that allows all egress traffic. You can create restrictive egress rules to:

- Limit outbound connections to specific destinations
- Control which protocols and ports your servers can use for outbound communication
- Implement security policies that restrict data exfiltration

1. Create separate groups for migration-tool management, transfer traffic, workload ingress, and
   workload east-west dependencies where their life cycles differ.
2. Allow administration only from approved operator or bastion ranges.
3. Allow Coriolis or Acura control and data paths only between the documented source, appliance,
   worker, and target addresses. Resolve exact ports from the approved product version.
4. Translate the Discovery dependency matrix into explicit workload rules; do not clone broad
   VMware VLAN access.
5. Restrict outbound traffic to required platform services, repositories, DNS, time, telemetry,
   backup, and application dependencies.
6. Record owner, purpose, evidence, expiry, and rollback for every temporary migration rule.
7. Test default-deny behavior and remove temporary transfer rules after source retention ends.

The gate passes only when platform security and the application owner approve the rules and both
migration-tool connectivity and workload dependency tests succeed.

## VM Application Landing Zone build sequence

<Steps>
1. Confirm the Platform Landing Zone prerequisites: governance folders, IAM model, Network Area, shared DNS, routing and firewall policy, audit path, and automation ownership.
2. Derive one VM Application Landing Zone specification from Discovery: environment, project owner, dependency boundaries, address demand, DNS names, data classification, availability, recovery objectives, and telemetry requirements.
3. Add the workload environment to the Accelerator `landing_zones` map and enable corporate networking, Secrets Manager, and Observability as required.
4. Apply the Accelerator and verify the project, role assignments, routed network, route policy, DNS zone, secrets boundary, state storage, automation identity, and Observability outputs.
5. Create and approve the Security Groups manually from the dependency matrix and the selected migration tool's control and transfer paths.
6. Hand the approved project ID, network, DNS, Secrets Manager, Observability endpoints, Security Groups, quotas, and target mappings to either the Coriolis or Acura runbook.
7. Let the selected tool deploy only its required appliance, worker, server, volume, image, and migration content into the Application Landing Zone.
8. Connect VM guest metrics and logs to the provisioned Observability endpoint, apply backup and recovery policies, and validate all controls in an isolated test migration.
</Steps>

Do not hand the project to a migration tool before steps 1 through 5 pass. The tool consumes the
Landing Zone; it does not define or replace it.

## Tool handoff contract

Provide the same approved Landing Zone contract to either tool while keeping their implementations
separate.

- **Common inputs**: STACKIT project and region, target network and addresses, Security Groups, DNS,
  machine and volume mappings, Secrets Manager usage, Observability endpoints, quotas, and rollback
  boundaries.
- **Coriolis content**: Coriolis appliance components, STACKIT endpoint, minion pools, Transfers,
  Deployments, and the resulting VM and volume resources.
- **Hystax Acura content**: Acura control components, replication integration, cloud-site settings,
  orchestration plans, target snapshots or volumes, and the resulting VM resources.
- **Common completion evidence**: Security-rule test, dependency test, guest telemetry, backup and
  restore evidence, application acceptance, and removal plan for temporary migration access.

## Definition of ready

The VM Application Landing Zone is ready for a production wave when:

- the Accelerator apply is reproducible and its outputs are stored with the wave evidence;
- project ownership, automation identity, quotas, naming, and labels are approved;
- network attachment, routing, DNS, and hybrid reachability are tested;
- Secrets Manager and Observability access are restricted and operational;
- Security Groups are manually created, reviewed, tested, and linked to the dependency matrix;
- the selected tool can reach only its required endpoints and target resources;
- backup, recovery, guest telemetry, acceptance thresholds, and rollback are defined.

## Primary source

<LinkCard
  title="STACKIT Landing Zone Accelerator"
  href="https://github.com/stackitcloud/stackit-landing-zone"
/>