There's no single "step one" for adopting a platform. Where you start depends on how much Terraform you already have and how good it is. This is the map.
Part 5 of 6 in the Aiden for InfraOps series. Start with the series overview »
The short version
The fastest way to stall an infrastructure platform rollout is to give every customer the same starting instructions. A team building from scratch has nothing in common, day one, with a team sitting on a thousand hand-written Terraform files. So before recommending a single action, the real first step is a question: how mature is your Terraform investment?
That maturity, gauged mostly by how much IaC you already have and how good it is, sorts cleanly into a few paths. Here's the map, and what to actually do at each fork.
| Where you are now | Starting move |
|---|---|
| Greenfield — building new infra from scratch | Producer workflow: project settings, Catalog, resource packs, appStack templates |
| Brownfield, zero Terraform (ClickOps / CloudFormation) | cloud2code to reverse-engineer live resources into synthetic IaC |
| Brownfield, Terraform exists but no hardened Modules | Adopt composite Modules or onboard quality Modules from a registry into the Catalog |
| Brownfield, hardened Modules but stale microservice IaC | Onboard Modules to the Catalog, build microservices via the Terraform Importer CLI |
| Brownfield, hardened Modules and good app-level Terraform | Use the Terraform Importer CLI to onboard applications as appStacks |
Now the detail.
If you're building new infrastructure and new application deployments from scratch, you have the rare luxury of no legacy to reconcile. Don't waste it by improvising per app.
Start with the Producer workflow, the platform-team side of the house. Define your project-level settings first: environments, SCM integration, state backends, the things nobody should reinvent for every application. Then build out the Module Catalog, the resource packs, and the appStack templates your developers will consume. You're setting the standards once, up front, so that every appStack built afterward inherits them. (The Catalog is the curated library at the center of this; see Why Your Module Catalog Isn't an IDE.)
Greenfield teams who invest here early get the cleanest version of the producer-consumer model, because the consumer experience is built on a deliberate foundation rather than retrofitted onto whatever already existed.
A lot of teams aren't greenfield and aren't Terraform shops either. They provisioned through the console (ClickOps) or used something like CloudFormation, and they have no prior Terraform investment to build on.
Often the immediate goal is modest and sensible: get a code-based backup of the live cloud topology, so it can be recreated for disaster recovery or stood up in a new region. For this, start with cloud2code. It reverse-engineers your live resources and generates synthetic IaC using atomic Modules, giving you a code baseline of what's actually running.
This is the messiest middle, and the right move depends on one question: do you have proper, hardened Modules yet?
If you don't have hardened Modules — your Terraform exists but nothing encapsulates your organizational constraints — the move is to get good blocks fast rather than authoring them all yourself. Adopt composite Modules, or find and onboard high-quality Modules from a registry into your Module Catalog. You're populating the shelf with trustworthy building blocks before worrying about every microservice.
If you do have well-managed, hardened Modules but your microservice IaC is out of date, you're closer than you think. Onboard those Modules into the Catalog, then build your microservices on top of them, either by hand or, more efficiently, using the Terraform Importer CLI. Your good Modules become the foundation; the importer helps you get applications expressed against them.
The most mature case: you have well-managed, hardened Modules and solid Infrastructure as Code for your applications and microservices. You're not missing pieces; you just need them inside the platform.
Here the path is direct. Use the Terraform Importer CLI to onboard your applications onto Aiden for InfraOps. The Terraform Importer CLI is a tool built to import existing Terraform code into an appStack, so your already-good IaC becomes a managed appStack rather than something you rebuild by hand. (Docs for the Terraform Importer CLI.) If your Terraform is in good shape, this is the shortest distance between where you are and a managed, consumable application.
Before you adopt any platform, locate yourself on this map honestly. Overstate your maturity and you'll skip the Module curation that makes self-service work. Understate it and you'll rebuild things you could have imported in an afternoon. The point of meeting teams where they are is that the correct first action is genuinely different for each starting point, and getting it right saves weeks.
Wherever you start, the destination is the same: a curated Catalog of hardened Modules and applications expressed as appStacks, which is the producer-consumer split that everything else builds on (Modules vs. appStacks). The path just changes depending on how much of that you're starting with.
← Previous — Part 4: Why Your Module Catalog Isn't an IDE (and Shouldn't Be)
Next — Part 6: Authoring Modules for Developers, Not for DevOps →
See all six parts in the series overview »