Skip to content
Ask AI about this
Help improve this page

Migration Assessment Checklist

Use this checklist to evaluate migration readiness before starting. Work through each section, then use the results to scope your rollout plan.

1. Module Inventory

Identify which terraform-aws-modules you currently use and their versions.

# Find all terraform-aws-modules references in your codebase
rg 'source\s*=.*terraform-aws-modules' --type tf
  • [ ] List all terraform-aws-modules in use across your codebase
  • [ ] Record the version constraint for each module (e.g., ~> 5.0, = 5.2.1)
  • [ ] Count how many instances of each module exist (e.g., 3 S3 buckets, 2 VPCs)
  • [ ] Identify any forked or wrapped modules (custom modules that call terraform-aws-modules internally)
  • [ ] Identify any modules sourced from Git URLs instead of the Terraform Registry

Forked modules require extra attention. If you maintain a fork of a terraform-aws-module, you will need to point the fork's internal source to compliance.tf or migrate off the fork entirely.

2. Framework Selection

Decide which compliance framework to target.

  • [ ] Determine your primary compliance framework: SOC 2, PCI DSS v4.0, HIPAA, CIS, NIST 800-53, or FedRAMP
  • [ ] If you need multiple frameworks, decide whether to start with one and add others later
  • [ ] Confirm the framework endpoint identifier (e.g., soc2, pcidss, hipaa)
  • [ ] Review the controls for your framework to understand what will be enforced

If you are unsure, start with SOC 2. It covers the broadest set of general security controls.

3. Scope

Define the blast radius for migration.

  • [ ] Count total module instances across all environments (dev, staging, production)
  • [ ] Decide which environment to migrate first (recommended: dev or staging)
  • [ ] Identify which Terraform workspaces or state files contain the modules
  • [ ] Determine if you use Terraform Cloud, Spacelift, env0, Atlantis, or plain CLI
  • [ ] Confirm who has access to run terraform apply in each environment

4. Compatibility Check

Verify your module versions are supported by compliance.tf.

Cross-reference your module inventory against the version compatibility matrix.

  • [ ] All modules are on a supported major version
  • [ ] Modules with upper-bound constraints (e.g., >= 10.0.0, < 11.0.0) match your pinned version
  • [ ] Any modules below the minimum supported version are flagged for upgrade
  • [ ] Unsupported modules are identified (modules not in the 34-module catalog will be proxied to the upstream registry without compliance controls)

5. Risk Assessment

Identify potential breaking changes before they show up in terraform plan.

Encryption at rest

These controls may require resource recreation if encryption is not already enabled (an AWS limitation, not a compliance.tf limitation):

  • [ ] RDS instances: check if storage_encrypted = true is already set
  • [ ] ElastiCache clusters: check if at_rest_encryption_enabled = true is already set
  • [ ] Redshift clusters: check if encrypted = true is already set
  • [ ] EMR clusters: check if encryption configuration exists
  • [ ] FSx file systems: check if encryption is configured

S3 object lock

  • [ ] Check if any S3 buckets need object lock (can be enabled on existing versioned buckets but applying retention to existing objects requires S3 Batch Operations)
  • [ ] If object lock is not needed, plan to disable the s3_bucket_object_lock_enabled control

Lifecycle and state

  • [ ] Check for prevent_destroy lifecycle rules that could block plan changes
  • [ ] Check for S3 ACL usage (some controls prohibit ACLs in favor of bucket policies)
  • [ ] Check for provisioner blocks (compliance.tf removes certain provisioners)

Access and networking

  • [ ] VPC: check if map_public_ip_on_launch is enabled on public subnets
  • [ ] EC2: check if associate_public_ip_address is set to true
  • [ ] RDS: check if publicly_accessible is set to true

6. Rollout Plan

Plan a phased migration to limit risk.

  • [ ] Phase 1 (Week 1-2): Migrate in a dev/sandbox environment. Pick one module (S3 or VPC recommended) and complete the full cycle: source change, init, plan, fix, apply.
  • [ ] Phase 2 (Week 2-4): Migrate all "Usually clean" modules in staging (ACM, AppSync, CloudWatch, KMS, Lambda, Secrets Manager, SNS, SQS, SSM Parameter, Step Functions, VPN Gateway).
  • [ ] Phase 3 (Week 3-6): Migrate "Minor fixes" modules in staging (S3, RDS, VPC, EC2, ALB, EKS, etc.). Fix validation errors one module at a time.
  • [ ] Phase 4 (Week 6+): Migrate production. Apply the same module order used in staging.
  • [ ] Phase 5: Address "Minor to significant" modules (ElastiCache, EMR, FSx, Redshift) if encryption retrofits are needed.

For each phase:

  • [ ] Assign an owner
  • [ ] Set a target completion date
  • [ ] Confirm rollback plan: change source back, terraform init -upgrade, verify with terraform plan

7. Success Criteria

Verify migration is complete for each module.

  • [ ] terraform init -upgrade succeeds with the compliance.tf source
  • [ ] terraform plan produces a clean plan (no validation errors)
  • [ ] terraform apply completes without errors
  • [ ] Compliance manifest is present in the downloaded module (.terraform/modules/<name>/)
  • [ ] Any disabled controls (?disable=...) have documented justification
  • [ ] Rollback tested: verified you can switch back to upstream source without state changes

Next Steps