Adopt in an existing estateMigration kit

Assessment checklist

For the platform lead scoping a move from terraform-aws-modules to compliance.tf across more than one root or team. Work through it in an afternoon: you end with a module inventory, the risks the first plans will surface and a phased rollout with an owner per phase. The Migration kit has the per-module steps.

Step 1: Inventory your modules

# Every terraform-aws-modules reference in the codebase
rg 'source\s*=.*terraform-aws-modules' --type tf

List every terraform-aws-modules module in use
Record the version constraint for each (for example ~> 5.0 or = 5.2.1)
Count the instances of each module (for example 3 S3 buckets, 2 VPCs)
Find forked or wrapped modules: in-house modules that call terraform-aws-modules internally
Find modules sourced from Git URLs rather than a registry

A fork needs its internal source pointed at compliance.tf, or the code moved off the fork.

Step 2: Pick the framework

Name the primary framework: SOC 2, PCI DSS v4.0, HIPAA, CIS, NIST 800-53 or FedRAMP
If you need several, decide which one goes first
Note its registry host from Registry endpoints (for example soc2, pcidss, hipaa)
Read the framework page: it lists the controls modules enforce and the mapped-only controls that stay with your team

Step 3: Set the scope

Count module instances across every environment (dev, staging, production)
Pick the environment to migrate first: dev or staging
List the workspaces or state files that hold the modules
Note where Terraform runs: HCP Terraform, Spacelift, env0, Atlantis or the plain CLI
Confirm who can run terraform apply in each environment

Step 4: Check version support

Compare the inventory with Version compatibility.

Every module is on a supported major version
Modules with an upper bound (for example >= 10.0.0, < 11.0.0) match your pinned version
Modules below the supported range are marked for an upstream upgrade first
Modules outside the module catalog are marked: they download from the public registry without compliance.tf controls

Step 5: Find the risks

Encryption at rest

These settings can need a rebuild when encryption is not on yet. The Migration kit explains what AWS requires for each.

RDS: is storage_encrypted = true already set?
ElastiCache: is at_rest_encryption_enabled = true already set?
Redshift: is encrypted = true already set?
EMR: does an encryption configuration exist?
FSx: is encryption configured?

S3 object lock

Find the buckets that need object lock. AWS turns it on for an existing versioned bucket; objects already in the bucket need S3 Batch Operations to get retention
For buckets that do not need it, plan to turn off s3_bucket_object_lock_enabled and record why

Lifecycle and state

prevent_destroy lifecycle settings that could block a plan change
S3 ACL usage: some controls require bucket-owner-enforced ownership
Provisioner blocks: an operational rule can remove them

Access and networking

VPC: is map_public_ip_on_launch on for public subnets?
EC2: is associate_public_ip_address = true set?
RDS: is publicly_accessible = true set?

Step 6: Plan the rollout

Start with the module the Migration kit names, then batch by the migration impact in its table.

Phase 1 (weeks 1-2): in dev or a sandbox, take one module through the whole cycle: source change, init, plan, fix, apply
Phase 2 (weeks 2-4): in staging, migrate the modules rated "Usually clean"
Phase 3 (weeks 3-6): in staging, migrate the "Minor fixes" modules, one module type at a time
Phase 4 (week 6 onward): migrate production, in the order used in staging
Phase 5: handle the "Minor to significant" modules (ElastiCache, EMR, FSx, Redshift) if encryption retrofits are needed

For each phase:

Name an owner and a target date
Confirm the rollback: point the source back, run terraform init, check with terraform plan
Track every module in one table or issue board: current source, assigned engineer, status

Before Phase 1, set up registry authentication in CI once for the team (CI/CD integration). The optional module source check can warn during the rollout and block after Phase 4.

Review each migration pull request against this list:

The source points at <framework>.compliance.tf/...
terraform plan shows no validation errors
Every ?disable= has a reason in the pull request description
No unrelated changes in the same pull request

Check the result

A module is done when:

terraform init succeeds with the compliance.tf source
terraform plan shows no validation errors, and terraform apply completes
.terraform/modules/<module name>/compliancetf-manifest.json exists and names the framework you picked
Every turned-off control (?disable=...) has a recorded reason
The rollback is tested: the source points back at upstream without a state change

Next steps

Migration kit

Version compatibility

On this page