Migrating to Frostmoln with Terraform

If you already manage infrastructure with Terraform on another cloud, the fm CLI can convert that configuration to the Frostmoln provider for you. It rewrites what maps cleanly and — crucially — reports every resource and attribute Frostmoln does not support yet, so nothing is dropped silently.

Supported source clouds: Amazon Web Services (AWS), Microsoft Azure, Google Cloud (GCP), and Oracle Cloud Infrastructure (OCI).

What the converter does

• Preserves your layout — your file and module structure is kept; each source file becomes the equivalent Frostmoln configuration in the same place.
• Rewrites what maps cleanly — for example an instance becomes a frostmoln_instance, a VPC becomes a frostmoln_vpc, and a security group becomes a frostmoln_security_group plus its standalone rules.
• Never guesses silently — where a value cannot be derived, the original is kept and a finding is recorded; anything unsupported is commented out in place behind a grep-able marker rather than dropped.
• Reports everything — the run prints a summary of every finding grouped by severity, and can write a full JSON report.

Configuration only: state migration is out of scope. The converter reads your .tf files and writes new ones — it never touches Terraform state or your existing cloud.

Install

The converter is built into the fm CLI — see the fm CLI guide to install it. No extra plugin is required.

Run it

Point the command at the root of the repository that holds your existing Terraform:

fm terraform convert ./infra

By default this runs fully offline — no account and no network are needed — and writes the converted configuration to ./infra/frostmoln.

Aim at the repository root rather than a single environment directory. Every directory holding .tf files is converted in one run, and module sources such as ../modules/network only resolve when the shared modules are inside the tree being converted. The output directory is excluded from the input, so re-running is safe.

Options

Flag	What it does
--provider	Source cloud: auto (default), aws, azure, gcp, or oci. auto detects it from the configuration.
--out	Output directory (default: <dir>/frostmoln).
--report	Write the full findings report as JSON to this path.
--online	Resolve live catalog values (flavors, images, regions) through your authenticated Frostmoln account instead of leaving placeholders. Requires fm auth login (or an API key).
--force	Overwrite a non-empty output directory.

# Force the source provider and choose an output directory
fm terraform convert ./infra --provider aws --out ./frostmoln

# Resolve real catalog values and save the report
fm terraform convert ./infra --online --report report.json

With --online the converter looks up real flavors, images, and regions from your account and fills them in. If the catalog is unreachable it falls back to the same placeholders as an offline run and prints a warning — it never fails the conversion for that reason.

Read the output

Two markers flag everything that needs your attention. Find them with grep:

grep -rn FM-TODO    ./infra/frostmoln   # catalog values to fill in
grep -rn FM-CONVERT ./infra/frostmoln   # anything that needs your attention

• FM-TODO — a placeholder where a live catalog value is needed (a flavor, image, or region) but was not resolved. Replace it with a real value; fm compute flavor list, fm compute image list, and the frostmoln_regions data source help you find one. Running with --online fills most of these in automatically.
• FM-CONVERT — something that needs your attention. Configuration Frostmoln does not support yet is commented out in place (never dropped) so you can decide what to do with it: remove it, or recreate the behavior another way. The marker is also attached to blocks that were left working but still belong to your old cloud (see below), and to values worth double-checking.

Blocks that still need your old cloud

Some resources are not Frostmoln's to convert — an identity provider's application registration, a raw ARM or cloud-specific escape hatch, a repository or pipeline definition. Those are copied through unchanged and still working, and each one is marked and counted separately in the summary. They are the part of your configuration that a migration does not finish on its own: decide for each whether to keep it where it is, or replace it.

What ends up in the output directory

The output holds your Terraform — .tf, .tf.json, .tfvars, .tfvars.json — plus any file your configuration actually reads with file(), templatefile(), or a related function: a user_data script, a cloud-init template, a policy document, an SSH public key. Those are copied unchanged, because the converted configuration still refers to them.

Everything else in the source tree is not copied, and each skipped file is listed as an info finding. The output directory is a new location that you may not have gitignored and may well share with a colleague, so the converter does not quietly duplicate your editor settings, git hooks, or unrelated data files into it.

Variable files are copied, and they usually hold secrets

.tfvars files are copied unchanged — the converted configuration needs their values — and each one raises a warning naming the file. Variable files are where credentials habitually live. The CLI creates the output directory readable by you alone, but check the permissions again before you move, commit, or share it.

Findings and severities

Every run prints a summary in which each finding carries a severity:

Severity	Meaning
blocker	The converted configuration will not pass terraform validate until you act — a required value is missing, or a construct cannot be represented.
warning	Converted, but with a behavior difference worth reviewing (for example a default that differs from the source cloud).
info	Informational — a file skipped, a resource with no equivalent removed, and so on.

Pass --report report.json to get the full machine-readable list of findings.

Exit codes

Code	Meaning
0	Converted cleanly (info and warning findings still exit 0).
2	Converted, but blocker findings exist — the output is still written, but review the blockers before applying.
1	A usage, I/O, API, or authentication error — nothing usable was written.

Blockers fail validation on purpose

Blockers are emitted as markers that make terraform validate fail. This is deliberate: you can never terraform apply a plan that the converter already knew was incomplete. Resolve every blocker — fill in the FM-TODO values and handle the FM-CONVERT blocks — then re-run terraform validate, and only then terraform plan.

What converts, per cloud

The exact mapping — every resource type and attribute, and what happens to each one — is published as a per-cloud matrix (English):

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud (GCP)
• Oracle Cloud Infrastructure (OCI)

See the matrix index for all four.

Next steps

1. Convert: fm terraform convert ./infra.
2. Resolve the FM-TODO and FM-CONVERT markers in the output.
3. Run terraform init && terraform validate in the output directory.
4. Run terraform plan and review it before terraform apply.

Related

• Terraform provider overview
• Getting Started with Terraform
• Terraform Provider Reference (English)
• fm CLI guide

Trademarks

Frostmoln is an independent cloud provider and a competing alternative to Amazon Web Services, Microsoft Azure, Google Cloud, and Oracle Cloud. Frostmoln is not affiliated with, endorsed by, or sponsored by any of them. AWS, Azure, Google Cloud, and Oracle Cloud are trademarks of their respective owners; all references are nominative and for interoperability only.