Migrating to IaC Console

Your path forward from CDKTF and constrained HCP Terraform free tier—with a complete tool suite that eliminates the need to build internal IaC tooling.

If you’re here, you’re likely facing one of these situations:

• CDKTF has been deprecated (as of December 10, 2025) and you need a new home for your programmatic infrastructure code
• HCP Terraform’s free tier now caps at 500 managed resources with only 1 concurrent run, and your team is hitting those limits
• You want a modern Infrastructure as Code platform with AI assistance, better code reusability, and no vendor lock-in
• Your team is tired of managing internal IaC tooling (CI/CD pipelines, config management, state backends, audit logs)

IaC Console is designed for DevOps, DevSecOps, and SRE teams who want to amplify their expertise, not replace it. This guide will help you migrate smoothly.

For Teams & Engineering Managers

Before migrating: Understand that IaC Console is an organizational investment, not just a tool replacement. By migrating, you’re choosing to:

• ✅ Avoid building internal tooling and focus on your core product
• ✅ Enable 1-5 engineer teams to work transparently with full audit trails
• ✅ Maintain security with Secure Agent Mode (credentials never leave your environment)
• ✅ Eliminate vendor lock-in with open-source CLI and standard HCL

The migration typically takes a short time for most teams, and the ROI justifies itself quickly through improved team productivity.

---

Understanding What Changed

CDKTF Deprecation (December 10, 2025)

HashiCorp officially deprecated the Cloud Development Kit for Terraform (CDKTF) on December 10, 2025. While CDKTF allowed teams to write infrastructure in TypeScript, Python, Java, C#, and Go, it’s no longer supported or maintained.

What this means:

• No security patches or bug fixes
• No new features or provider updates
• Growing compatibility issues with new Terraform/OpenTofu versions
• Need to migrate to either HCL or an alternative solution

HCP Terraform Free Tier Transition (March 31, 2026)

On March 31, 2026, HCP Terraform’s legacy free tier reaches end of life. While an “enhanced” free tier still exists, it comes with significant constraints:

Legacy Free Tier (Ending):

• User-based model
• More flexible for small teams

Enhanced Free Tier (Current):

• ✅ Still exists (technically “free”)
• ⚠️ Capped at 500 managed resources
• ⚠️ Only 1 concurrent Terraform run
• ⚠️ Limited team collaboration features

Why teams are migrating: For any moderately complex infrastructure or team doing parallel work, these limits become real blockers. The community reaction has been significant — Gruntwork (makers of Terragrunt) noted the “déjà vu is real” in reference to HashiCorp’s earlier BSL license change.

---

Why Choose IaC Console?

1. Complete Tool Suite, Not Just One Product

IaC Console provides everything you need for modern IaC management:

• iacconsole-cli — Open-source CLI (free forever)
• iacconsole-api & CMDB — Centralized configuration management
• IaC Console Web App — Browser-based management with AI Assistant
• go-entrypoint — Runtime config/secrets injection for microservices

This is what teams spend significant time building internally. We provide it out-of-the-box.

2. Open Source CLI with Secure Agent Mode

Unlike proprietary solutions, IaC Console’s CLI is fully open source. Your credentials never leave your machine — the agent runs locally and connects to the cloud dashboard securely via outbound-only WebSocket.

3. Superior Code Reusability (DRY Infrastructure)

IaCConsole enforces separation of Units (logic) from Dimensions (configuration data). Write your Terraform code once, deploy it to unlimited environments without duplication.

# Traditional Terraform: duplicated folders
dev/main.tf     # Hardcoded values
prod/main.tf    # Hardcoded values

# IaCConsole: one unit, multiple dimensions
units/myorg/vpc/main.tf              # Pure logic
inventory/myorg/env/dev.json         # Dev data
inventory/myorg/env/prod.json        # Prod data

3. Built-In AI Assistant (Gemini 2.5 Flash)

Generate, modify, and explain Terraform code using AI. The assistant has access to the OpenTofu registry and your project context, providing accurate suggestions based on current documentation.

4. No Resource Limits

Deploy 10 resources or 10,000 resources. Run parallel plans across multiple environments. Scale without hitting artificial caps.

5. Managed State Without Lock-In

State files are automatically managed and stored securely. You can export and migrate anytime — no proprietary format, no vendor lock-in.

6. API-Driven CMDB

All your infrastructure configuration is queryable via REST API. Integrate with CI/CD, audit systems, or build custom tooling on top.

---

Migration Paths

For CDKTF Users → IaCConsole

If you’ve been using CDKTF to write infrastructure in TypeScript/Python/etc., here’s your path:

Step 1: Synthesize Your CDKTF Code to HCL

Before CDKTF support ends completely, run:

cdktf synth

This generates HCL files in cdktf.out/stacks/<your-stack>/. These are standard Terraform files.

Step 2: Organize Code by Purpose (Units)

In IaCConsole, a Unit is a deployable piece of infrastructure with a clear purpose. Group your synthesized HCL by logical components:

units/
  └── myorg/
      ├── vpc/              # Network infrastructure
      ├── eks-cluster/      # Kubernetes cluster
      ├── rds-postgres/     # Database
      └── cloudfront-cdn/   # Content delivery

Step 3: Extract Configuration to Dimensions

Look for hardcoded values in your HCL (instance types, CIDR blocks, region names). Move them to dimension files:

Before (CDKTF-synthesized HCL):

resource "aws_instance" "app" {
  ami           = "ami-12345678"
  instance_type = "t3.large"  # Hardcoded

  tags = {
    Environment = "prod"      # Hardcoded
  }
}

After (IaCConsole Unit):

resource "aws_instance" "app" {
  ami           = "ami-12345678"
  instance_type = var.iacconsole_env_data.instance_type

  tags = {
    Environment = var.iacconsole_env_name
  }
}

Configuration (inventory/myorg/env/prod.json):

{
  "backup_enabled": true,
  "instance_type": "t3.large"
}

Step 4: Create Unit Manifest

Each unit needs a unit_manifest.json describing its required dimensions:

{
  "required_dimensions": ["org", "env", "datacenter"]
}

Step 5: Deploy with IaCConsole CLI

Download the latest pre-built binary for your platform (Linux/macOS) from GitHub Releases.

# Start agent (runs locally)
iacconsole-cli agent

# Use web dashboard to plan/apply
# Or use CLI directly:
iacconsole-cli exec plan --org myorg --env prod --dc us-east-1 --unit vpc

---

For HCP Terraform → IaCConsole

If you’re migrating from HCP Terraform (formerly Terraform Cloud) due to resource/concurrency limits:

Step 1: Export Your Existing Code

Clone your Terraform repositories. You likely already have organized code — that’s a head start.

Step 2: Restructure as Units

If your code is already in modules, converting to IaCConsole Units is straightforward:

HCP Terraform structure:

environments/
  ├── dev/
  │   ├── main.tf          # Calls modules with vars
  │   └── terraform.tfvars
  └── prod/
      ├── main.tf          # Duplicate calls
      └── terraform.tfvars

IaCConsole structure:

units/
  └── myorg/
      └── infrastructure/
          ├── main.tf              # Module calls
          └── unit_manifest.json

inventory/
  └── myorg/
      ├── env/
      │   ├── dev.json
      │   └── prod.json
      └── datacenter/
          ├── us-east-1.json
          └── eu-west-1.json

Step 3: Migrate State Files

IaCConsole can import existing Terraform state:

# Export state from HCP Terraform
terraform state pull > terraform.tfstate

# Import to IaCConsole (via CLI)
iacconsole-cli state import --org myorg --env prod --dc us-east-1 --unit infrastructure --file terraform.tfstate

Step 4: Update Backend Configuration

Remove HCP Terraform backend blocks and let IaCConsole CLI manage state automatically:

Before:

terraform {
  backend "remote" {
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
  }
}

After:

# For S3:
terraform {
  backend "s3" {}
}

IaCConsole CLI injects -backend-config flags at init time, automatically constructing a unique state path from your org, dimensions, and unit name. No manual key management required.

→ Full state management guide →

Step 5: Parallel Execution (No More Queues!)

With HCP Terraform free tier limiting you to 1 concurrent run, you’d queue up. With IaCConsole:

# Run plans for multiple environments in parallel
iacconsole-cli exec plan --org myorg --env dev --unit vpc &
iacconsole-cli exec plan --org myorg --env staging --unit vpc &
iacconsole-cli exec plan --org myorg --env prod --unit vpc &

Or use the web dashboard to trigger multiple runs simultaneously.

---

Migration Checklist

Pre-Migration

• [ ] Audit your current infrastructure (resource count, dependencies)
• [ ] Identify logical units (VPC, databases, applications, etc.)
• [ ] Document current state file locations
• [ ] Create IaCConsole account at iacconsole.com
• [ ] Install IaCConsole CLI: GitHub Releases

During Migration

• [ ] Create organization structure (units/your-org/)
• [ ] Define dimension hierarchy (org → env → datacenter)
• [ ] Convert/organize HCL code into units
• [ ] Extract configuration to dimension JSON files
• [ ] Create unit_manifest.json for each unit
• [ ] Test locally with iacconsole-cli exec plan
• [ ] Import existing state files

Post-Migration

• [ ] Verify state consistency
• [ ] Run drift detection
• [ ] Update CI/CD pipelines to use IaCConsole CLI/API
• [ ] Train team on Units/Dimensions model
• [ ] Set up dimension-level access controls (if using Team plan)
• [ ] Archive old HCP Terraform workspaces or CDKTF projects

---

Common Migration Scenarios

Scenario 1: “We have 1,200 managed resources”

Problem: HCP Terraform free tier caps at 500 resources.

Solution: IaCConsole has no resource limits. Migrate your units progressively:

1. Week 1: Migrate networking units (VPC, subnets)
2. Week 2: Migrate compute units (EC2, EKS)
3. Week 3: Migrate data stores (RDS, S3)
4. Week 4: Full cutover

During migration, you can run both platforms in parallel — use IaCConsole for new resources while maintaining existing infrastructure in HCP Terraform.

Scenario 2: “We need parallel deployments”

Problem: HCP Terraform free tier allows only 1 concurrent run.

Solution: IaCConsole supports unlimited concurrent runs. Each agent can handle multiple executions, or run multiple agents for different environments:

# Terminal 1: Dev environment
iacconsole-cli agent --env dev

# Terminal 2: Prod environment
iacconsole-cli agent --env prod

Scenario 3: “CDKTF was our abstraction layer”

Problem: You wrote TypeScript/Python because HCL felt too verbose.

Solution: IaCConsole’s Units + Dimensions model provides abstraction without needing a different language:

CDKTF TypeScript (deprecated):

const bucket = new s3.S3Bucket(this, 'bucket', {
  bucketName: `app-data-${environment}`,
  versioning: { enabled: true },
});

IaCConsole HCL (with AI assistance):

resource "aws_s3_bucket" "data" {
  bucket = "app-data-${var.iacconsole_env_name}"
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id

  versioning_configuration {
    status = var.iacconsole_env_data.versioning_enabled ? "Enabled" : "Disabled"
  }
}

Use the AI assistant to generate boilerplate, explain syntax, and suggest best practices — all from the web dashboard.

Scenario 4: “We use Terraform modules heavily”

Problem: You’re worried about losing module composition.

Solution: IaCConsole supports standard Terraform modules and adds Shared Modules:

shared-modules/
  └── s3-encrypted-bucket/
      ├── main.tf
      ├── variables.tf
      └── outputs.tf

units/
  └── myorg/
      └── app-infrastructure/
          └── main.tf

Using shared modules in units:

module "logs_bucket" {
  source = "./shared-modules/s3-encrypted-bucket"  # Auto-linked by CLI
  bucket_name = "logs-${var.iacconsole_env_name}"
}

The CLI automatically links shared-modules/ to every unit’s execution directory.

---

Getting Help

Documentation Resources

• Quick Start Guide
• Code vs Config Philosophy
• CLI Reference
• API Documentation
• Terraform State Management

Community & Support

• GitHub CLI: github.com/IaCConsole/iacconsole-cli
• Issues & Feature Requests: Open an issue on GitHub
• Email Support: hello@iacconsole.com

Need Migration Assistance?

For teams migrating large infrastructure (500+ resources), we offer migration support:

• Architecture review of your current setup
• Automated conversion scripts for CDKTF → Units
• Hands-on migration workshop for your team

Contact us: hello@iacconsole.com

---

Why Teams Are Switching Now

“After HashiCorp deprecated CDKTF and changed the free tier, we needed a solution that wouldn’t leave us stranded again. IaCConsole’s open-source CLI gives us control, and the Units model finally solved our environment duplication problem.” — DevOps Lead, Series B SaaS Company

“We were hitting the 500-resource limit and couldn’t afford the $0.47/resource/month jump to Standard. IaCConsole saved us $2,800/month and gave us better features.” — Infrastructure Engineer, E-commerce Platform

“The AI assistant is genuinely useful. It pulled documentation from the OpenTofu registry and generated working code in seconds. That alone justified the switch.” — Solo Founder, Early-Stage Startup

---

The Bottom Line

CDKTF is deprecated. HCP Terraform’s free tier has hard limits. Both situations create real migration pressure.

IaCConsole offers a modern alternative:

• ✅ Open source CLI (never locked in)
• ✅ No resource limits
• ✅ Unlimited concurrent runs
• ✅ Native code reusability (Units + Dimensions)
• ✅ Built-in AI assistance
• ✅ API-driven infrastructure inventory

Get Started Free →

Download the latest pre-built CLI binary for your platform (Linux/macOS) from GitHub Releases and try it locally:

iacconsole-cli agent

Migration deadline: HCP Terraform’s legacy free tier ends March 31, 2026. Start your migration today.