How to move state out of env zero

How to export env zero state before the contract ends

State can be pulled from the env zero backend with the IaC CLI and moved to a self-hosted backend. Resources stay in place as long as the move is verified before any environment is retired. Renewal terms, a pricing change or a data residency requirement may set the deadline, but the state file is the part you cannot afford to lose or reconstruct. Treat the export as its own milestone, separate from the work of rebuilding workspaces, pipelines and approval rules.

Export covers the Terraform or OpenTofu state for each environment, which is the record of what each resource is and where it lives. Before you change any configuration, take a local backup of each state, then swap the backend block to the new target and run init -migrate-state so the CLI copies state across. Two things do not move with the state. Platform objects such as templates, approval policies, stored variables, VCS connections and run history must be recreated in the new platform. Configurations that read other stacks through the terraform_remote_state data source also need extra care, because a stack that still points at the old backend will read stale or missing outputs after the move.

Confirm current export behavior against env zero's own documentation, because this page does not replace it. Ask which state versions are retained, whether state can be downloaded directly from the platform, how terraform login authenticates for your organization, and whether any secret values are stored outside the state. Keep every local backup encrypted and access-controlled, since state often contains credentials. OpenTofu's state and plan encryption documentation describes one way to encrypt state at rest, and it is worth deciding on that before the backups are created.

What you can export from env zero and how

This table lists each data type you may need to move out of env zero, the export method we could confirm, the format and any documented limits. Rows marked "confirm with env zero" have no documented export path in the sources we reviewed, so ask the vendor before you plan around them. The main takeaway: state is the item you can pull directly through the backend, and everything else needs a vendor answer or a manual record.

Data type	Export method	Format and limits
State files	CLI pull through the remote backend after terraform login, or a state download on the backend before you swap it	Terraform or OpenTofu state JSON. Confirm with env zero whether all state versions or only the current one are retrievable.
Plan output	Run terraform show on a saved plan file, or copy plan logs from the env zero run history	Saved plan binary or text output. Plans from env zero runs may expire, so confirm retention with env zero.
Variables and variable sets	Confirm with env zero whether a documented export exists, otherwise record them from the console or API	Key-value pairs. Sensitive values are usually write-only, so expect to re-enter secrets from your own vault.
Environment and workspace metadata	Confirm with env zero whether a documented API or export exists, otherwise inventory manually	Names, module paths, branch and template links. Plan a spreadsheet inventory as the fallback.
VCS links	Confirm with env zero whether repository connections can be exported, otherwise document them manually	Repository, branch and path mappings. You recreate these in Terrakube or Atlantis.
Audit logs	Confirm with env zero whether audit log export is available for your plan and retention period	Format and retention are not confirmed here. Request them before you decommission access.

What does not export and how to rebuild it

Remote state moves with a backend swap, but the platform around it holds configuration that a state file never contains. The cards below cover the items most teams discover late, and each one names a rebuild step and a check to run before you mark the env zero environments inactive. Confirm the export behavior for each item with env zero support, since the platform's export options can change.

Environment lifecycle settings

Env zero environments carry settings such as auto-deploy on pull request, time-to-live rules, and drift detection schedules. These describe how the platform acts on a stack, not what the state contains, so they do not travel with the state file. Once you move to Terrakube, rebuild the equivalent behavior as workspace settings and your pipeline triggers. Confirm with env zero which of these settings it can export, and record the rest by hand per environment before you start the swap.

Approval policies and templates

Approval rules and environment templates define who can apply and which module versions a team may use. Neither is stored in the Terraform state, so a migrated workspace runs without the gate that protected it. Rewrite approval rules as OPA policy checks in Terrakube extensions, and rebuild templates as versioned modules in the Terrakube private registry. Ask env zero for a list of active policies and templates per project so nothing is dropped silently.

Encrypted secrets held by the platform

Variables marked sensitive in env zero are stored in its own secret store, and the export path does not rewrite them into a usable form. Treat each secret as a fresh value to be supplied again. Move them into a secrets manager your runners can read, then reference them from Terrakube workspace variables. Confirm with env zero whether any values can be retrieved, and plan for rotation so old copies do not remain in the new system.

Cost governance data

Cost estimates, budgets, and usage reports that env zero shows per environment are reporting records, not infrastructure state. Their history stays in env zero. In Terrakube, the Infracost extension can produce fresh estimates on each run, but past figures will not carry over. Export or screenshot the reports you need for finance and audit records before the account is closed, and confirm the retention window that applies to your plan.

Run history and audit logs

Plan and apply logs, who triggered each run, and approval timestamps form the record of past changes. This history is not part of the state file, so it will not appear in Terrakube. Keep an archive of exported logs in your own storage, indexed by environment and date. Check whether env zero offers a bulk export, and document the gap in your change records so auditors know where the earlier evidence lives.

Export sequence: back up, swap the backend and verify a no-change plan

This sequence moves each environment's state from the env zero remote backend to a self-hosted Terrakube backend, with a check after every step. Each environment stays reversible until you mark it inactive in env zero, so the deployed resources are not touched during the move.

Confirm the env zero backend host and environments
Before any change, list every environment and workspace that uses the env zero remote backend, and record the backend host, organization and workspace name for each one. Confirm the exact host name and login method in env zero's own documentation, because this guide does not assume a hostname. Search configurations for terraform_remote_state references, since OpenTofu's migration guide warns that these need extra care. Done when you have a written inventory that maps each environment to its code directory and its target Terrakube workspace.
Authenticate to the env zero backend host
Run terraform login against the env zero backend host so the CLI holds a token that can read the current state. Then run one read-only command, such as terraform state list, in a single environment to confirm the token works and the state is reachable. Store the token on a machine you control and limit it to the access this migration needs. Done when the command returns the resource list for that environment without an authentication error.
Back up state and code locally
For each environment, run terraform state pull and write the output to a dated file outside the repository, then copy the configuration directory. The backup is optional, but it gives you a rollback copy that does not depend on env zero staying available. Store it with the same access controls as the original state, because state can contain secrets. Done when each backup opens as valid JSON and its resource count matches what the read-only command showed in the previous step.
Swap the backend block to Terrakube
In each configuration, replace the env zero backend block with a remote backend that points at the Terrakube API hostname, organization and workspace you created for it. Create and configure the matching Terrakube workspace first, including its variables and credentials, so the backend has a destination. Keep the change on a branch so reviewers can see the diff. The Terrakube CLI-driven workflow documentation covers the required settings. Done when terraform validate passes and the diff touches only the backend block.
Migrate state with init -migrate-state
Run terraform init -migrate-state in the environment's directory and answer the prompt that asks whether to copy existing state to the new backend. Confirm the prompt names the Terrakube workspace as the destination and the env zero backend as the source. Leave the source state in env zero untouched, since it remains your fallback. Done when init reports a successful migration and terraform state list against Terrakube shows the same resource addresses as the backup from the earlier step.
Verify a no-change plan before any apply
Run terraform plan against the Terrakube backend and read the summary. A correct migration reports no changes, because the code, state and providers are unchanged. If the plan shows creates, updates or deletes, stop and do not apply. Check variables, workspace settings and provider versions first. OpenTofu's migration guidance follows the same pattern of backing up, initializing and verifying, then testing with a small change, so make one small reviewed change and confirm it plans as expected. Until you mark env zero environments inactive, you can point the backend block back at env zero and migrate state in reverse.

Choosing the state path for each environment

A single operator who owns an environment and runs plans and applies from a terminal is the simplest case. The migration is mostly mechanical: download the current state from env zero, keep a local backup, change the backend block, and run init with the migrate-state option. Because one person drives the changes, there is little risk of overlapping runs and the cutover window is short.

Back up first: Save a copy of the state file and the working directory before touching the backend block, and keep it until the no-change plan is clean.
Migrate in one step: Run init with -migrate-state after changing the backend, and confirm the state reaches the new backend before deleting anything locally.
Verify with a no-change plan: A plan that reports no changes is the signal that the state and configuration agree. Treat any proposed change as a reason to stop and investigate.
Keep the old environment readable: Do not destroy env zero environments yet. Marking them inactive leaves resources in place and gives you a rollback path.
Test with a small change: Make one harmless change, such as a tag, to prove the apply path works end to end.

Confirm with your team that no pipeline or second operator still runs against the old backend before you close the window.

Keep state encrypted once it leaves env zero

State files often contain sensitive values, including database passwords, generated keys and connection strings that providers write in plain text. When env zero hosted the remote backend, the platform handled storage and access controls for you. Once state sits on a self-hosted backend, the team owns encryption at rest, so this decision belongs in the migration plan before the first terraform init -migrate-state runs, not after. OpenTofu offers client-side encryption of state and plan files, meaning the CLI encrypts them before they reach the backend. Its documented key providers include AWS KMS, GCP KMS, OpenBao, Azure Vault and PBKDF2, the last being a passphrase-derived option. Each provider implies a different key custody model: a cloud KMS keeps keys in your cloud account under its IAM policies, OpenBao or a similar service keeps them under your own operators, and PBKDF2 depends on how the passphrase is distributed and rotated. Choose the provider and the custody model with your security team, and record who can decrypt state and who can rotate keys.

Encryption only protects you if the rest of the chain holds. Confirm that your chosen backend, the Terrakube database and object storage, and the key provider meet your organization's own control requirements for key management, access logging, backups and retention, and ask your auditors which evidence they will want. Also check that the runners and any local backup files from the migration are covered by the same rules, since an unencrypted copy left on a laptop undoes the protection on the server. Test decryption on a non-production workspace before you rely on it, and confirm with the OpenTofu documentation, linked here, which provider versions and settings your OpenTofu release supports.

Questions teams ask before exporting env zero state

How much effort does exporting env zero state take?

The effort scales with how many environments you move and how they depend on each other. Each environment needs its state pulled from the env zero remote backend, its backend block changed, and a no-change plan confirmed on the new backend. A small set of independent environments is a short, repeatable task. The work grows when environments share state, when one configuration reads outputs from another through the terraform_remote_state data source, or when pipelines and variables depend on env zero's own features. Ask for an inventory of environments, shared state and data source references before agreeing on scope, because that inventory is what sizes the job.

Can our own team export the state without outside help?

Often yes, if your engineers already run the Terraform or OpenTofu CLI against the env zero backend and understand the backend block. The steps are documented: authenticate, optionally back up the state locally, change the backend configuration, and run init with the migrate-state option. The harder part is the surrounding work, such as checking data source dependencies, confirming that no one applies during the change window, and deciding how the target platform is hosted and secured. Teams without that experience, or with many shared states, often bring in a partner for the planning and verification steps while keeping day-to-day control in-house.

What access and preparation does the export require?

You need four things in place before work starts:

CLI access to each env zero environment, with a session created by terraform login or the equivalent for OpenTofu
Credentials for the cloud accounts the configurations manage, so a verification plan can run
A target platform, either self-hosted Terrakube or Atlantis, reachable from your network and sized for the number of workspaces
A change window agreed with the teams that deploy to these environments, so no run starts between the state move and the verification plan

Ask the provider to confirm which of these they will need from you and which they will set up themselves.

How long does the migration take?

No duration can be stated for your environment from the sources available here, so treat any figure as unverified until it is written into a scoped plan. The main drivers are the number of environments, the number of shared states and cross-state data source references, how many cloud accounts must be checked with a plan, and how quickly the target platform is ready. Ask for a timeline that lists each environment, the change window and the verification steps, and check that it covers the time needed to fix any configuration that fails the no-change plan.

Will the migration destroy cloud resources?

No, moving state does not destroy resources by itself, and the migration is designed so that it does not need to. The state file records what Terraform or OpenTofu manages, and moving it to a new backend leaves the real infrastructure untouched. The verification step is what gives you confidence: a plan run after the backend change should report no changes. If it reports creates or destroys, stop and resolve the difference before any apply. Environments in env zero should then be marked inactive so the platform does not act on them, which is a separate step from deleting anything in the cloud.

Can the export be reversed if something goes wrong?

Yes, the process is designed to be reversible. OpenTofu's migration guidance describes a sequence of backing up state and code, installing the tool, initializing and verifying the configuration, and testing with a small change, described as safe and reversible. Keep the local state backup taken before the backend change, and keep the env zero environment active until the new backend has passed its verification. If you need to roll back, restore the original backend block and re-initialize against env zero. Confirm the exact rollback steps for your own configurations as part of the written plan.

Should the export and the new platform be scoped together?

They can be, but they answer different questions. Moving state is about where the record of your infrastructure lives. Choosing Terrakube or Atlantis is about how runs, approvals and pull request workflows operate afterward. Teams that move state first can keep their existing deployment process while they validate the new backend, then move pipelines in a later phase. A fixed-scope agreement can cover both, with separate deliverables and acceptance checks for the state move and for the run workflow, so each can be signed off on its own evidence.

What to plan before the env zero renewal or termination date

Moving state out of env zero is mostly a planning exercise. The items below sequence the work so that export, target platform, change windows and record retention are settled before any backend is switched. Contract dates and notice periods belong to your env zero agreement, so confirm them there first.

Confirm the export path in writing

Ask env zero to confirm, in writing and before the notice window closes, how state and plan data can be exported from its remote backend, what format it arrives in, and whether any limits apply to volume, history or access after termination. Do not rely on a verbal answer from sales or support. Ask for the same confirmation for run logs and variable values, which may not be exportable at all.

Inventory every workspace and backend

List every environment, its state location, its backend configuration, its VCS source and the modules it reads through terraform_remote_state. Environments that share state data need a dependency order, because a consumer cannot move before its producer. Record the owner of each environment so that each cutover has a named approver.

Decide the target platform and identity model

Choose between Terrakube for remote runs and state from the CLI, or Atlantis for plans on pull requests, and choose OpenTofu or Terraform as the CLI. Then define how engineers will authenticate, for example through an identity provider mapped to groups, so that workspace permissions exist before the first migrated state is pushed. Note that OpenTofu compatibility with future Terraform releases is not guaranteed.

Schedule a change window per environment

Plan one window for each environment, starting with the lowest-risk one, and avoid scheduling production changes during freezes or release periods. Each window should include the backend swap, a verified no-change plan and a rollback step. Agree on who can pause a window if a plan shows unexpected changes.

Retain run history and logs

Before termination, export or document run history, plan outputs, approval records and audit logs that your retention policy requires. Confirm with env zero which of these it can provide and in what form, and confirm your own retention periods with compliance or legal owners. Store the exports in a location your organization controls.

Set the date to mark environments inactive

Mark each env zero environment inactive only after its state has been migrated and a no-change plan has passed against the new backend. Pick the date with the owner of each environment, and make sure no one will run an apply from the old environment. Inactive marking must not destroy resources, so check the platform's documentation before choosing this path for any environment.

How DeployOpen scopes and delivers an env zero state exit

DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a state exit from env zero, we start from a written scope that names each environment, backend and runner involved, then move state in a controlled sequence with verification at each step.

How we scope

We inventory every env zero environment, its remote backend configuration and the Terraform or OpenTofu versions in use
We identify configurations that read other state through terraform_remote_state, which need extra sequencing care
We agree in writing which environments move, which are marked inactive, and who signs off each cutover

How we build

We prepare the target backend and state storage in your own cloud account, data center or air-gapped network
We run the backend swap and init with state migration in a non-production environment before any production change
We confirm a no-change plan for each migrated environment and record the output as evidence

How we hand over

We deliver a runbook covering the backup, backend block changes, migration commands and rollback steps
We document which env zero environments were marked inactive and confirm that managed resources were left in place
We provide the verification records and configuration files so your own engineers can repeat the process

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
We do not issue audit reports or certifications; we prepare the controls and evidence that your independent auditor reviews