Cloud Exit Plan: Documents, backups, and Terraform files to have before switching providers

A Cloud Exit Plan is not a “just in case we move” folder, but a verifiable procedure for exiting the current cloud. Before switching providers, a company must understand which services are critical, where the data is stored, how it is encrypted, what dependencies the applications have, and how long it will realistically take to restore everything in another environment.

The minimum set of artifacts includes:

• An inventory of cloud resources: accounts, projects, regions, networks, DNS, databases, queues, storage, and managed services;
  
• A service dependency map: applications, data, IAM roles, secrets, keys, external APIs, DNS, and queues;
  
• Architectural and operational documentation: network diagrams, environment descriptions, runbooks, and cutover and rollback procedures;
  
• Contractual documents: notice period, data access window, export terms, egress traffic costs, and support during the exit phase;
  
• A backup register: contents, format, location, retention period, encryption, key owner, and restore procedure;
  
• Results of a test restore outside the current provider;
  
• A Terraform repository, lock file, state, backend description, outputs, variables for each environment, and a resource import map;
  
• A register of secrets, certificates, and keys with a plan for migration, reissue, or rotation;
  
• A migration plan with the sequence of work, owners, success criteria, and a rollback plan.

The main check is simple: can the critical environment be restored outside the current cloud within the RTO/RPO and the contractual window? If the Terraform state is held by a contractor, the backup can only be read through the old KMS, the dependency map is incomplete, and recovery has never been tested in an independent environment, the Cloud Exit Plan is not ready yet.

Why “we’ll move if we have to” often doesn’t work

Consider a B2B SaaS company with a customer-facing API, authentication, billing, a customer database, object storage, queues, DNS, and several external integrations. On paper, everything looks fine: the infrastructure is described in a repository using Terraform, backups run on a schedule, and both the contractor and the internal team have access.

But the need to leave the current cloud rarely arises at an ideal moment. It may be triggered by a commercial dispute, contract termination, changes in compliance requirements, SLA degradation, cost increases, or a strategic migration. At that point, it becomes clear that “we have Terraform” and “we have backups” are not the same as having an exit plan.

Terraform state may be stored in the contractor’s account. Some resources may have been created manually and never captured in code. Backups may be restorable only within the old cloud. Encryption keys may be tied to the current provider’s KMS. The payment gateway may accept requests only from the previous IP addresses. And the contract may provide only a limited window for exporting data and validating recovery.

A Cloud Exit Plan is designed for exactly these situations. It maps technical artifacts in advance to a managed scenario: what to move first, which data is required, which services depend on each other, which keys and secrets need to be reissued, who is responsible for the cutover, and how to verify that the new environment is actually working.

What a Cloud Exit Plan Should Capture Before Changing Providers

A Cloud Exit Plan does not start with exporting all data or copying the Terraform repository. First, you need to determine what exactly the company must be able to restore, within what time frame, and under what constraints.

Otherwise, the team risks migrating everything indiscriminately: test environments, old archives, secondary analytics, and temporary services. At the end of the migration window, it may turn out that critical billing, authentication, or the customer database has not been restored within the required timeframe.

For the business, the minimum critical scope usually does not include the entire cloud landscape, but only the services without which the product cannot be considered operational: authentication, the customer database, billing, the public API, key queues, and external integrations.

Before collecting artifacts, it is worth defining several things:

Next, services need to be categorized by criticality. Not all components have to move on day one: some directly support the product and revenue, while others are important but can wait until the core environment has stabilized.

Criticality levels can be used for this classification. For example, Tier 0 refers to systems without which the business process stops immediately: authentication, billing, the payment environment, and customer data. Tier 1 refers to important services that allow a slightly longer recovery window: order processing, internal integrations, and second-tier customer APIs.

This criticality is best tied to a BIA — business impact analysis. It helps determine which systems actually affect revenue, customer commitments, and regulatory requirements. Services are then mapped to RTO/RPO: what must be restored within minutes, what can take hours, and what can be migrated later with acceptable downtime.

For example, a company does not have to migrate all test environments, archives, and internal analytics on the first day. The first step is to bring up the minimum operational scope: authentication, the customer database, billing, and the public API. Everything else can be migrated after product availability, data correctness, and fulfillment of customer commitments have been confirmed.

If this framework is not defined, backups, Terraform files, and contracts remain disconnected assets. Once the framework is clear, it can be translated into a concrete set of artifacts: documents, a dependency map, backups, Terraform state, test logs, and contractual terms that the team must have before changing providers.

Required Cloud Exit Plan artifacts: what the team needs to have in hand

Once the exit scope has been defined, it needs to be turned into a verifiable set of materials. The Cloud Exit Plan must be understandable not only to the infrastructure team, but also to security, engineering, legal, and procurement teams. Otherwise, the plan quickly becomes a collection of files whose meaning is known only to a single engineer or contractor.

The core principle is simple: the artifacts should prove not that “we have something,” but that “we can restore the critical environment outside the current provider.” For each area, it is therefore important to understand what it documents, why it is needed, and how to verify that it is up to date:

This set does not have to be large at the start. What matters is that it is coherent. Terraform without backups does not restore data. Backups without keys do not guarantee readability. Documents without tests do not prove that the plan can be executed. A dependency map is needed so that the team does not bring up an “empty” service without DNS, secrets, queues, and external integrations.

After this summary, it is best to examine the key categories separately. First, documents: they record the architecture, operational procedures, and contractual constraints without which a technical exit quickly runs into tribal knowledge and hidden dependencies.

Documents to Have Before Switching Providers

Documents in a Cloud Exit Plan are not just a formality. Their purpose is to eliminate dependence on the current provider, contractor, and individual employees who “just know how everything works.” Before switching providers, the team should have a complete set of materials that makes it possible to understand the architecture, perform the cutover, and verify contractual constraints.

It is useful to divide the documents into three groups:

Architectural documents need to show not only the list of resources, but also the relationships between them. For example, a public API may depend on DNS, a load balancer, a customer database, a queue, IAM roles, a KMS key, and an external CRM. If these dependencies are not documented, the team may migrate the server and database but end up with a nonfunctional service.

Operational documents should answer the question: “What needs to be done during the migration window?” They should include the sequence for freezing changes, switching DNS and load balancers, the rollback procedure, contacts for the people responsible, post-recovery checks, and a list of manual actions that have not yet been automated.

The contractual section is often underestimated, even though it is what connects the technical plan to reality. If the contract provides access to data for 30 days after notice, but a test export takes 45 days when channels, data volume, and validation are taken into account, this is a risk for the Cloud Exit Plan. It must be documented before the contract is terminated, not after the old provider has already started counting down the period.

Once the documents are in place, it becomes clear exactly what needs to be migrated and what constraints apply to the process. The next step is to document service dependencies; without this, the resource inventory remains just a list of objects rather than a usable recovery map.

Service Dependency Map: Why a Resource Inventory Is Not Enough

A typical scenario: the team restored the application and database in a new environment, but the public-facing service failed to start. The issue was not in the code: the secret for the payment API, the access role for object storage, and the DNS record for the customer domain had not been migrated. These resources were visible in the inventory, but the relationships between them had not been documented as prerequisites for startup.

That is why critical services need not only an inventory, but also a dependency map. It shows which components must be migrated together and which services must be brought up first.

For example:

• Client API. Depends on the client database, cache, public DNS, load balancer, private subnets, database read role, log write role, encryption keys, API tokens, CRM, and support system. If only the application and database are migrated, the service may technically start, but it will not be able to serve customers.
• Billing. It depends on the payment database, invoices, queues, private access, outbound NAT, DB access role, payment gateway secret, KMS key, payment provider, and accounting system. For this type of service, it is important to separately verify RTO/RPO compliance, because the loss of payment events is usually more critical than delays in internal analytics.
• User authorization. Depends on the account and session databases, DNS auth domain, load balancer, user directory access role, token signing keys, SSO, and mail service. If the signing keys or SSO integration are forgotten, users will not be able to log in even if the database has been restored.
• Order processing. Depends on orders, events, queues, internal routes, queue read roles, writes to storage, service account secrets, warehouse, and delivery. Such a service cannot be migrated separately from queues and external counterparties; otherwise, part of the business process will stop.

A dependency map shows not just “what exists,” but what must work together. If access credentials, keys, DNS, or external integrations are not configured for a critical service, it is not ready for release even if all resources are present in the inventory.

Special attention should be paid to managed services: databases, queues, serverless and event-driven services, cloud IAM, access policies, and key management services. They cannot be considered portable simply because they appear in the resource list. For each such component, you need to specify what happens to it as part of the exit:

• Migrated as data;
• Replaced with an equivalent in the new environment;
• Rebuilt from scratch;
• Temporarily remains dependent on the old provider;
• Excluded from the first migration phase.

Once the dependency map is complete, it becomes clear which data and settings must be migrated together.

Backups: which copies are needed and how to validate them

A backup in a Cloud Exit Plan should answer more than just whether a copy exists. It is important to understand where it is stored, how it is encrypted, what format it is stored in, whether it can be read outside the current provider, and how long recovery will take.

Exiting the cloud typically requires copies of several types of data:

• Databases — full dumps, transaction logs, or point-in-time recovery, if available;
• Object storage — bucket copies, object versions, metadata, and lifecycle policies;
• Machine disks and images — snapshots of critical servers, if recovery from an image is included in the scenario;
• Queues and events — exporting messages if the business process cannot tolerate their loss;
• Configuration data — application parameters, feature flags, routing settings;
• Logs and Audit — security logs, operational logs, data for investigations and reporting;
• Secrets and certificates are not plaintext passwords, but a managed process for export, reissue, or rotation.

For each copy, you need to record its format. The more tightly it is tied to a specific provider service, the higher the risk when exiting. For example, a database exported as a standard dump is easier to validate in another environment than a managed database snapshot that can be restored only within the same cloud. Such snapshots can be useful, but they should not be the only recovery method.

Keys must be checked separately. If data is encrypted with a key from the current cloud’s KMS, you need to determine in advance whether the key material can be exported, whether the data can be re-encrypted, or whether recovery can be performed using a new key in the target environment. If the key cannot be exported and used outside the provider, the backup may technically exist but be unsuitable for independent recovery.

After that, the main question is no longer “is there a backup,” but “can it be restored outside the old cloud.” This must be tested separately.

Verifying Data Recoverability Outside the Current Provider

Having a backup does not mean being ready to exit. For a Cloud Exit Plan, data must be restored in an environment that does not depend on the current provider. This may be a test environment with another provider, an isolated site, or a local environment sufficient to validate the format, keys, and integrity.

The validation should preferably follow a consistent template:

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure



Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans



Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus



Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster


1. Select a data set: a critical database, part of object storage, configurations, logs, secrets, or certificates.
   
2. Retrieve a copy from the current cloud through a native export, replication, or export to independent storage.
   
3. Verify access to keys: confirm that the data can be decrypted outside the old KMS, or that there is an approved key reissue process.
   
4. Restore the data in an independent environment without using an internal recovery mechanism available only from the current provider.
   
5. Verify integrity: record counts, checksums, sample business checks, and relationships between tables and objects.
   
6. Measure the recovery time and compare it with the RTO.
   
7. Assess data loss and compare the recovery point with the RPO.
   
8. Document the limitations: incompatible formats, missing metadata, dependency on provider services, and manual steps.
   
9. Assign owners for remediation if the recovery fails.

The validation result must be documented in a report: date, data volume, copy source, target environment, keys used, recovery time, verification result, and list of limitations. Without such a report, the statement “we have backups” does not confirm exit readiness.

Once the data has been validated, the second major layer remains: infrastructure. Terraform helps here, but only if the company has not just a single repository with .tf files, but a complete set of artifacts that link the code to the real environment.

Terraform Files: What You Need Beyond the Code

Terraform helps describe infrastructure as code, but a repository alone is not enough to switch providers. A Cloud Exit Plan must include not only .tf files, but also everything that links the code to the actual infrastructure:

State is especially critical. If it is stored by a contractor or in the current provider’s storage without an independent copy, the company may have the code but not a managed infrastructure state. In that case, terraform plan will show not a controlled migration, but an attempt to recreate resources or delete resources that Terraform does not correctly recognize.

Before exiting, at least four checks should be performed:

• The repository is accessible to the company, not only to the contractor;
  
• The state has been exported, protected, has a checksum, and is available outside the current provider;
  
• Terraform plan runs in an isolated environment without hidden dependencies on production accounts;
  
• All resources from the inventory are either present in Terraform or included in the import map or the manual replacement list.

When migrating between providers, Terraform code cannot always be transferred directly: resources and providers differ. Even then, however, it remains an important source of facts: which networks existed, which access rules were applied, what parameters the databases had, and which output values were used by applications.

The purpose of a Cloud Exit Plan is to preserve this information in a managed form before the provider change begins. After that, the organization can build not just separate documents and checks, but a complete migration plan: what will be done, in what order, who is responsible, how success will be validated, and when rollback will be performed.

Migration Plan Template

We have prepared a sample migration template because, without one, a Cloud Exit Plan quickly turns into a set of intentions. It may include backups, Terraform, and documentation, but it remains unclear who presses the button, in what order services are brought online, where the point of no return is, and what to do if validation fails.

To make it easier to navigate, let’s break it down step by step.

What the plan should include before migration begins

The plan should start by defining the scope of work. This helps prevent the migration window from expanding mid-process and avoids disputes on cutover day over which services “definitely should have been migrated.”

The plan should explain why the provider is being changed and what outcome will be considered successful. For example, the objective might be stated as follows: migrate the product’s critical environment to the new cloud without breaching RTO/RPO and without losing customer data.

Next, define the scope of work: which services are included in the first phase and which are deliberately excluded. The first phase typically includes authentication, billing, the customer database, the public API, and key integrations. Test environments, archives, and internal analytics can be moved later to avoid overloading the critical cutover window.

Service criticality, owners, the agreed window, and responsible parties should be documented separately. The team must know in advance which systems are classified as Tier 0/Tier 1, how much time is available for data export, and who is responsible for infrastructure, data, security, the application, contracts, and business validation.

What must be technically ready

The technical section of the plan should tie together all the artifacts that have already been collected. The key is not simply to state that “backups exist” or “Terraform exists,” but to describe exactly which materials will be used during the migration.

It is useful to keep this in a short table:

This kind of table helps quickly identify where the plan is still incomplete. If the data has been restored but the keys have not been reissued, the service will not work. If the infrastructure is up but DNS and allowlists with external partners have not been updated, users still will not reach the new environment.

Cutover and validation procedure

The most important part of a migration plan is the sequence of work. It must be written so the team can follow it during a high-pressure window, rather than reconstructing the order of operations from memory.

The sequence typically looks like this:

1. Freeze changes in the old environment and approve any exceptions;
2. Provision or update the infrastructure in the target environment;
3. Restore the data and verify access to keys;
4. Configure secrets, certificates, roles, and external integrations;
5. Perform technical checks: network, DNS, API, queues, logs, and monitoring;
6. Perform business checks: authorization, billing, payments, and customer operations;
7. Switch DNS or load balancers;
8. Monitor metrics, API errors, queues, and support requests;
9. Record the cutover result.

Success criteria must be specific. Not “the service is working,” but “authorization succeeds, payments are created, the customer API responds, record counts match, API errors are within the normal range, and new events appear in the target database and logs.”

Rollback, Risks, and Decommissioning the Old Environment

A plan without a rollback path is not a plan; it is a bet on luck. Before the migration begins, define the conditions under which the team will return to the old environment and who is authorized to make that decision.

For example, if billing validation is not completed within 20 minutes, the team points DNS back to the old load balancer, resumes writes to the old database, and records the reason the migration was stopped. It is better to discuss this scenario in advance than to argue about it during an incident.

This section should also document known risks, temporary workarounds, and tasks that must be completed before the next attempt. If some managed database snapshots cannot be restored outside the provider, that should not come as a surprise on cutover day. This risk must be documented in advance and addressed with another recovery method: a dump, transaction logs, or replication.

Communications are described separately: who must be notified before, during, and after the cutover. Depending on the service, this may include internal teams, customer support, contract owners, external contractors, and integration partners.

The old environment must not be deleted immediately after the cutover. A monitoring period is usually required: the team checks metrics, customer inquiries, data integrity, and integrations. Only after that can access be revoked, resources deleted, the data destruction record retained, and the completion of the exit documented.

What Counts as Exit Readiness

A Cloud Exit Plan can be considered usable not once the files have been collected, but once it has been validated. It is not enough to have Terraform, backups, documents, and contracts; you must prove that the critical environment can be restored outside the current provider within the defined constraints.

A minimal readiness check looks like this:

The main sign of a mature Cloud Exit Plan is that the team can prove an exit is possible under the defined conditions. The documents show what needs to be moved and in what order. Backups confirm data availability. Terraform captures the infrastructure facts. The dependency map shows which services cannot be restored in isolation. Tests prove that the data can be read outside the current provider.

If one of these elements is missing, the plan has not necessarily failed, but the risk must be explicitly described:

This kind of plan does not guarantee that changing providers will be simple. But it reduces the main risk: the company can see in advance which elements are genuinely portable, which require replacement, which are tied to the current cloud service, and which still exist only as tacit knowledge held by the team or the contractor.

After this review, you can move to the final conclusion: a Cloud Exit Plan is needed not to create an impressive archive of documents, but to enable a controlled cloud exit without emergency improvisation.

Conclusion

A Cloud Exit Plan is not a folder of Terraform code, backups, and diagrams for a future migration. It is a verifiable runbook: what to move, in what order, with which data, using which keys, within what timeframe, and who is responsible for each step.

Readiness to switch providers exists only when the artifacts are linked together. Documentation describes the architecture and constraints, the dependency map shows the order in which services should be restored, backups confirm data availability, Terraform captures the infrastructure, and tests prove that the critical environment can be brought up outside the current cloud.

A good Cloud Exit Plan does not make migration easy, but it eliminates the most dangerous scenario: an exit that relies on memory, under the pressure of a dispute, a deadline, or service degradation. The company understands in advance where it has genuinely portable assets, where it depends on the provider, and where there is still only hope rather than a plan.

FAQ

Is a Cloud Exit Plan needed only before an actual migration?

No. It is better to prepare it in advance, before there is a dispute with the provider, a hard deadline, or an emergency. When things are calm, it is easier to verify backups, Terraform state, keys, contractual restrictions, and service dependencies.

Is Terraform code enough to switch providers?

No. Terraform code without state, a backend, a lock file, outputs, variables, and an import map does not show the full mapping to the actual infrastructure. In addition, when switching providers, resources and managed services may differ, so the code often serves as a source of facts rather than a ready-made migration plan. Terraform state stores the mapping between objects in the remote system and resources in the configuration, and import is needed to bring existing resources under Terraform management.

Why should backups be tested outside the current provider?

Because a backup may exist but be usable only within the old cloud, due to the snapshot format, a dependency on a managed service, or a KMS key. For a Cloud Exit Plan, it is important to prove that the data can be read, decrypted, and restored in an independent environment.

What to Do If Some Services Cannot Be Migrated Directly

They should be classified in advance: what will be migrated as data, what will be replaced with an equivalent, what will be rebuilt in the new environment, and what will temporarily remain a dependency on the previous provider. It is better to document this risk in the plan before terminating the contract than to discover it during the migration window.

How can you tell whether a Cloud Exit Plan is actually ready?

Readiness is confirmed not by the number of files, but by validation: the critical environment has been restored outside the current cloud, RTO/RPO have been measured, dependencies have been documented, the Terraform state is accessible to the company, keys and secrets have a migration plan, and the migration plan defines owners, success criteria, and rollback. NIST SP 800-34 Rev. 1 specifically emphasizes the importance of contingency planning as a process for preparing to restore information systems after operational disruptions.

Sources

1. HashiCorp Developer — Terraform State 

2. HashiCorp Developer — Import Existing Infrastructure Resources

3. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems