How to Migrate from AWS Landing Zone to AWS Control Tower

I recently guided a large enterprise through their migration from the original AWS Landing Zone (ALZ) to AWS Control Tower. They had 87 accounts across multiple OUs, custom SCPs, and a complex baseline StackSet. The process wasn’t trivial, but with the right sequencing and planning, we completed it in two weeks with zero downtime. In this post, I’ll walk through exactly what you need to do to migrate from ALZ to Control Tower.

The Problem

AWS released the original Landing Zone solution in 2016 as the first codified reference architecture for multi-account AWS governance. It’s served tens of thousands of customers well. However, the AWS Landing Zone Accelerator (LZA) has replaced it as the modern, actively developed solution. Control Tower is the fully managed service alternative. If you’re running the original ALZ, you’re missing features like self-service account provisioning, advanced guardrails, and proactive compliance detection that Control Tower offers.

ALZ vs Control Tower Comparison

Feature	ALZ	Control Tower
Self-service account creation	Via Service Catalog	Via Account Factory (built-in)
Guardrails	SCPs + Config Rules (manual)	Guardrails (managed, preventive + detective)
Baseline provisioning	StackSets (manual)	Automatic
Active development	Limited	Active
AWS support	Community	Full
Customization	High	Medium (via customizations APIs)

Why Does This Matter?

The original ALZ is no longer actively developed by AWS. While it still works, you miss out on:

Automatic guardrail updates from AWS
New compliance frameworks as AWS releases them
Faster account provisioning via Control Tower’s Account Factory
Proactive compliance detection via Control Tower’s integrated services

The Migration Path

Step 1: Deploy Control Tower

Start fresh by deploying Control Tower in your management account. Control Tower will automatically create two new accounts: Audit and Log Archive. Be prepared for this.

# In the AWS Management Console, go to Control Tower
# Click "Set up landing zone"
# Choose your home region (cannot be changed later)
# Review and deploy

Control Tower creates its own:

Audit account (for centralized compliance checking)
Log Archive account (for centralized logging)
Service Control Policies (different from your ALZ SCPs)
Config Aggregator and Organization Trail

Step 2: Prepare Your Existing Accounts

Before enrolling existing accounts into Control Tower, you must remove conflicting resources:

# In each existing account, DELETE or DISABLE:
# 1. AWS Config Recorder (if you have one)
aws configservice describe-configuration-recorders \
  --region us-east-1

aws configservice stop-configuration-recorder \
  --configuration-recorder-name default

# 2. CloudTrail (Control Tower creates its own Organization Trail)
aws cloudtrail describe-trails \
  --region us-east-1

aws cloudtrail delete-trail \
  --name my-trail

# 3. Landing Zone CloudFormation StackSets (optional but recommended)
# These won't conflict, but they might duplicate work

Critical: If you have a Config Recorder running, Control Tower cannot be deployed. Disable it first.

Step 3: Enroll Existing Accounts

Once Control Tower is running, use Account Factory to enroll your existing accounts:

# In the Control Tower console:
# 1. Go to Account Factory
# 2. Click "Enroll Account"
# 3. Enter the AWS account ID and email
# Control Tower will move the account to its "Registered" OU

Alternatively, use the API:

aws controltower create-managed-account \
  --account-email your-account@example.com \
  --account-name production-account \
  --region us-east-1

Control Tower baselines each account automatically. This takes 10-15 minutes per account.

Step 4: Migrate Custom SCPs

Your original ALZ likely has custom SCPs. You have two options:

Option A: Keep them in Organizations alongside Control Tower’s SCPs:

# Your custom SCPs stay attached to OUs via Organizations
# Control Tower's guardrails apply on top
# Result: Defense in depth, but potential conflicts

Option B: Migrate them to Control Tower Customizations:

Control Tower 3.0+ allows you to define custom SCPs via customizations-config.yaml:

# In your Control Tower Customizations repo:
cd ~/controltower-customizations
# Add your custom SCP to the config

This keeps everything unified but requires rewriting your SCPs as Customizations.

Step 5: Decommission the Original Landing Zone

Once all accounts are enrolled and verified to be working:

# In your management account:
# 1. Disable the ALZ CodePipeline
aws codepipeline update-pipeline \
  --cli-input-json file://disabled-pipeline.json

# 2. Delete the ALZ StackSet (or leave it—it won't interfere)
aws cloudformation delete-stack-set \
  --stack-set-name AWS-Landing-Zone-Baseline

# 3. Remove Service Catalog products
aws servicecatalog delete-product \
  --id prod-xxxxxxxxxx

Is This Safe?

Yes, if you follow the sequence. The key risks are:

Deploying Control Tower before disabling Config Recorder: This will cause Control Tower deployment to fail.
Enrolling accounts too quickly: Control Tower baselines accounts sequentially. Enrolling 50 accounts at once means the last one waits 12+ hours.
Deleting ALZ before verifying Control Tower works: Keep ALZ around for a week after migration to verify everything is stable.

Key Takeaway

Migration from ALZ to Control Tower is straightforward if you follow the right sequence: disable conflicting resources, deploy Control Tower, enroll existing accounts, migrate custom SCPs, and decommission ALZ. The result is a fully managed, actively supported governance platform.

Have questions or ran into a different Landing Zone issue? Connect with me on LinkedIn or X.