VM Application Landing Zone for Relocate

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.

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.

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 docsConcepts › Security rulesSource 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

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

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

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.

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

Code & registry github.com STACKIT Landing Zone Accelerator Open the repository