Resolving CDK-to-Terraform Migration Hesitations Through Client Engagements — IaC Standardization Decision Framework 2026

On May 30, 2026, Debating Whether to Ditch CDK and Migrate to Terraform Vol. 1 was published on Zenn, sparking intense debate across social media and developer communities. The central theme of the article reflects honest frontline struggles: as assets built with AWS CDK / CloudFormation expand, CDK-specific quirks (synthesis overhead, drift, disparities in TypeScript proficiency across teams, and the difficulty of stack splitting) turn into operational liabilities. Around the same time, peripheral tools like OpenTofu 1.12, Pulumi, cdktf, Atlantis, and Spacelift matured, leading mid-sized enterprises operating on a multi-cloud premise to increasingly adopt the pragmatic solution of "retaining CDK in select areas while centering on Terraform/OpenTofu."

From our position supporting mid-sized enterprises' cloud infrastructure, SRE, and platform teams through client engagements, this signifies not a binary dispute of "CDK vs. Terraform," but an entry into a standardization phase to determine which assets to align with which IaC tooling. Connecting with the licensing compliance + governance covered in OpenTofu 1.12 Terraform Migration Services (GH Media), the multi-cloud network design covered in AWS Interconnect Multi-Cloud Services (GH Media), and the cross-sectional operations covered in AWS DevOps Agent Multi-Cloud AIOps (GH Media), we outline how to execute an "IaC standardization migration" from the perspective of custom engineering engagements.

Why the "CDK to Terraform decision" marks a watershed

In short, standardizing on Terraform/OpenTofu is not about "abandoning CDK," but rather a structural transition to an IaC foundation capable of withstanding multi-cloud architectures, cross-team collaboration, and audit requirements.

Three structural changes beneficial to custom development projects

Structure 1: From "single-cloud premise" to the "scale barrier"

CDK is exceptionally well suited for single-AWS, developer-centric, small-to-medium scale environments. However, once stack counts surpass 50 and teams grow beyond five, synthesis times, complex dependencies, and cross-account configurations cause operational costs to spike dramatically. In client engagements, we conduct a "scale barrier" diagnosis indexed on stack count × team count × monthly change frequency, delivering a hybrid architecture that migrates only the areas exceeding the threshold to Terraform. This represents a scale-dimension variant of the governance design explored in OpenTofu 1.12 Terraform Migration Services (GH Media).

Structure 2: From "AWS-exclusive" to "multi-cloud portability"

Many mid-sized enterprises use AWS as their primary cloud while concurrently leveraging GCP (data platforms), Azure (Microsoft 365 integrations), and Cloudflare (CDN). Because CDK cannot define GCP or Azure resources, teams ultimately end up running Terraform in parallel anyway. In our client engagements, we provide architectures that unify common modules (VPC, IAM, audit logging, secrets management) under Terraform, while retaining only advanced AWS-specific configurations (such as Step Functions and internal Lambda construct libraries) in CDK. This is the IaC counterpart to the multi-cloud connectivity covered in AWS Interconnect Multi-Cloud Services (GH Media).

Structure 3: From "developer-exclusive" to "cross-team IaC portability"

While CDK offers high affinity as IaC written by application developers, concerns have grown that it is difficult for dedicated infrastructure, SRE, and security teams to manage. Terraform/OpenTofu + HCL serves as a common cross-functional language, and PR-based review flows via Atlantis or Spacelift readily satisfy audit compliance. In our client engagements, we design IaC layering tailored to team topologies (platform, product, application). This is the configuration language edition of the cross-sectional operations discussed in AWS DevOps Agent Multi-Cloud AIOps (GH Media).

The 5 phases of "IaC standardization migration" delivered in client engagements

Phase 1: Current state assessment (2–3 weeks)

• Asset inventory across CDK, CFn, Terraform, and Pulumi
• Measurement of stack count × team count × monthly change frequency
• Data collection on drift, synthesis times, and failure history
• Inventory of multi-cloud usage status
• Compilation of audit requirements (ISO 27001, SOC 2, PCI DSS)
• Risk and ROI matrix

Phase 2: Design (2–3 weeks)

• Triaging into "retain CDK," "migrate to Terraform," and "new OpenTofu"
• State splitting design (by environment, team, and lifecycle)
• Common module design (VPC, IAM, audit logging)
• CI/CD pipelines (Atlantis / Spacelift / GitHub Actions)
• Drift detection and notification design
• Rollback and DR design

Phase 3: Implementation (4–6 weeks)

• Implementation of Terraform/OpenTofu common modules
• State backend setup (S3 + DynamoDB / Tofu Cloud)
• Atlantis / Spacelift setup
• Policy configuration with TFLint, Checkov, and tfsec
• Phased CDK-to-HCL migration bridge using cdktf
• Automated import scripts

Phase 4: Pilot migration (3–4 weeks)

• Preemptive migration in non-critical environments (dev / staging)
• Drift detection + rollback drills
• Team-by-team onboarding training
• KPI measurement (plan time, review time, failure rate)
• Feedback loop

Phase 5: Monthly operational reviews (ongoing)

• Inventory of migration progress and remaining CDK assets
• Module version management
• Root cause analysis of drift and incidents
• Support for new resources (provider updates)
• Semiannual standardization guide updates

Standard technology stack set for custom development

Which projects need this and which do not

For small-scale CDK projects, deciding to leave them as they are is actually rational. In our custom development, rather than "unifying everything under Terraform," we design architectures that "retain a hybrid model based on scale and system boundaries."

Six clauses to include in client contracts

Client ROI estimate (120 stacks / 40 SRE + dev members assumed)

At an assumed rate of ¥8,000/hour, this delivers ¥19.2 million in annual labor savings plus business opportunity gains from faster rollouts. Because ROI varies significantly depending on stack count, team count, and monthly change frequency, the safest approach is to build an ROI matrix based on your company's actual metrics during the Phase 1 diagnostic before committing to a migration.

Five common pitfalls

Pitfall 1: Splitting state solely by environment

Splitting state only across dev, staging, and prod leads to frequent conflicts as teams multiply. Split state across three axes—environment × team × lifecycle—and pair this with PR-level locking via Atlantis or Spacelift.

Pitfall 2: Neglecting drift and falling into "import purgatory"

Assets that were manually modified in the AWS Management Console during the CDK era require massive import efforts when migrating to Terraform. Eliminate all drift prior to migration and establish a framework for continuous detection using driftctl.

Pitfall 3: Over-abstracting module design

Pursuing "DRY" to create ultra-generic modules makes the blast radius of changes unpredictable. Limit module hierarchy to two tiers—platform layer (shared) and product layer (team-specific)—and prohibit three or more tiers.

Pitfall 4: Discarding CDK entirely

Rewriting domains into Terraform where CDK's expressiveness shines—such as Step Functions and in-house Construct libraries—actually creates technical debt. Clearly document boundaries and deliberately protect retained CDK assets.

Pitfall 5: Postponing Policy as Code

If Checkov, tfsec, or OPA are introduced only after migration, existing modules will trigger massive policy violations, grinding operations to a halt. Introduce policies incrementally alongside the migration, establishing grace periods categorized by severity.

90-day action plan

Summary — IaC operations evolving from "CDK vs. Terraform" to "standardization by scale and boundaries"

The CDK operational debt highlighted in the Zenn discussions is not because "CDK is inherently flawed," but rather "the result of postponing decisions regarding scale and boundaries." From the perspective of supporting cloud infrastructure for mid-sized enterprises through custom development, deliberately distinguishing between CDK workloads to retain and Terraform/OpenTofu workloads to migrate based on scalability walls, multi-cloud requirements, and cross-team collaboration is essential to "IaC standardization migrations."

If you are facing challenges such as "expanding CDK assets making operations unsustainable," "needing to unify IaC for multi-cloud deployments," or "establishing IaC governance to meet audit standards," we provide custom quotes based on your stack volume, team structure, and compliance needs. Please feel free to reach out via our contact form.

Sources

• Debating Whether to Ditch CDK and Migrate to Terraform Vol. 1 (Zenn 2026-05-30)
• OpenTofu 1.12 Terraform Migration Client Services (GH Media)
• AWS Interconnect Multi-Cloud Custom Development (GH Media)
• AWS DevOps Agent Multicloud AIOps (GH Media)
• AWS MCP IAM Governance Services (GH Media)
• GitHub Actions Supply Chain Continuous Audit Services (GH Media)