Azure's native export gets you a file. Clophi gets you a repository — structured, parameterized, and ready to deploy.
When you want to bring existing Azure infrastructure under IaC management, the only built-in option is Azure's Resource Group "Export template" feature. It produces ARM, Bicep, or Terraform from your live resources, and on the surface it looks like exactly what you need.
In practice, the output is rarely usable as-is. Read-only properties bleed into it. Sensitive values come back masked in ways that make it impossible to tell what was configured. Child resources show up duplicated. A single SQL Server with one database can produce 30+ resources. Permission boundaries silently break the Terraform path. Parametrization barely exists. Modularization doesn't exist at all. Anything beyond a single resource group is left for the engineer to compose by hand.
We've covered all of this in detail elsewhere. Why Azure's Resource Group Export Template Falls Short — if you want the full diagnostic, that's where to start.
This post is about the other side of the problem: what a tool that handles this properly actually needs to do, and how Clophi does it.
Going from existing Azure infrastructure to clean, deployable IaC isn't just a matter of dumping resources to disk. It requires:
Azure's native export answers approximately none of these. Clophi was built around all of them.
Real environments don't fit into a single resource group. Production workloads span multiple RGs, sometimes across subscriptions, and the boundaries that exist in Azure rarely match the boundaries that make sense in your IaC repository.
In Clophi, you start by selecting what you want to bring under code management. You can pick entire resource groups, hand-pick individual resources, or compose a logical grouping across multiple RGs. For example, building a single IaC module that represents a complete application stack pulled from three different resource groups.
Before any code is generated, Clophi shows you exactly what's in scope: every resource that will be codified, with its dependencies, its relationships, and any flags Clophi has surfaced about how it will be handled. This is your chance to catch anything that shouldn't be there, add anything that's missing, or adjust how specific resources will be represented.
This step exists because the worst time to find out something is wrong with the output is after you've integrated it into your repository. The review step makes the generation predictable.
Existing infrastructure often has implicit relationships that aren't visible in the raw resource definitions. A function app that references a Key Vault secret. A VM that depends on a storage account hosting its boot diagnostics. Clophi lets you make these dependencies explicit, add new resources that should be part of the deployable unit, and modify resource configurations directly in the interface.
The point: the IaC you generate should reflect the architecture you want to deploy, not just a snapshot of what currently exists.
Sensitive values should never live in source code. Azure's export handles this by stripping the values out and leaving you to figure out which fields were sensitive and where to put their replacements. Clophi handles it actively. When a sensitive field is detected, Clophi warns you and gives you two options: reference an existing Key Vault secret, or create one directly from the platform and reference it inline.
The result is generated code that already has Key Vault references wired in correctly, with no manual sweep through the output looking for hardcoded credentials or Masked sensitive attribute placeholders.
When you generate, Clophi produces code in your framework of choice: Terraform, Bicep, or ARM. The output is:
Only the configuration that actually defines the resource is in the code.
No subnets appearing both inlined and as standalone resources, no auto-provisioned children that Azure manages itself, no master-database subtrees from a single SQL server creation.
Values that should be parameters are lifted out as parameters. Resource references use the appropriate framework functions, not hardcoded strings.
Output is split across logically organized files, not one flat dump.
The same input produces the same code every time. Regenerations produce diffs you can review, not unrecognizable rewrites.
Once generation completes, you have two options. Download the generated files as an archive, or push them directly into your team's existing repository. The file structure is designed to drop into a real IaC codebase without manual reorganization. Naming conventions, folder layout, and module boundaries are all chosen to integrate cleanly with how engineering teams actually structure infrastructure repos.