A cloud migration strategy usually focuses on getting somewhere.
Which workloads should move? Where should they go? What will the migration require? How much will the new environment cost? How will it improve performance, scalability or resilience?
Those are important questions.
But there is another one worth asking before the migration begins:
What happens if we need to move again?
An exit strategy doesn’t mean an organization expects its cloud decision to fail. It means understanding how today’s infrastructure choices could affect tomorrow’s options.
Pricing can change. Business requirements evolve. Applications are modernized. Companies acquire other companies. Security and compliance requirements shift. New technologies emerge. And, as many organizations reconsidering long-standing VMware environments have discovered, licensing and commercial models can change too.
A strong cloud migration strategy should therefore consider more than how efficiently a workload can move into an environment.
It should also consider how much flexibility remains once it gets there.
An Exit Strategy Isn’t a Plan to Leave
The phrase “cloud exit strategy” can sound more dramatic than it needs to be.
It doesn’t necessarily mean maintaining a second environment waiting for workloads to arrive. Nor does it mean avoiding useful cloud services because they might create dependencies.
At its simplest, an exit strategy means understanding what would be required to move a workload, its data and the operations surrounding it to another environment if business or technical requirements changed.
AWS defines a cloud-provider exit strategy as an organization’s approach to moving one or more workloads from a cloud service provider to another environment. Its guidance recommends considering the target environment, technical requirements, staffing and skills, contractual commitments, data residency, timing and testing as part of that planning.
The National Institute of Standards and Technology (NIST) has addressed the related concept of cloud portability for years. Its Cloud Computing Standards Roadmap describes portability in terms of moving data and applications between cloud environments at an acceptable cost.
The point isn’t to predict exactly why an organization might leave an environment.
It’s to understand whether it reasonably could.
Start With Workload Portability
In our recent article, Rethinking Your Cloud Migration Strategy After VMware Changes, we made the case for choosing infrastructure based on workload requirements rather than allowing the event that triggered the migration to determine the destination.
The same workload-first principle applies to an exit strategy.
Start by asking:
- What would it take to move this workload elsewhere?
- Which components could move largely as they are?
- Which would need to be reconfigured?
- Would any components need to be rebuilt or refactored?
- What dependencies exist between the application and its current environment?
- Which skills and tools would be required to operate it somewhere else?
- How much downtime could the business tolerate during a future move?
Not every workload needs to be completely portable.
Some applications may benefit enough from a provider-specific service to justify becoming more dependent on that environment. Others may be important enough that preserving flexibility should carry more weight.
The key is making that tradeoff consciously.
Don’t Confuse Application Portability With Data Portability
Being able to move an application doesn’t necessarily mean its data will be equally easy to move.
NIST distinguishes between application and data portability and notes that data portability can present its own complexities because of the different volumes, types and forms of data applications use.
That makes data an important part of the exit conversation.
Ask How the Data Comes With You
Before choosing a new environment, organizations should understand:
- How is data stored?
- In what formats can it be exported?
- How much data would need to move?
- How long could that transfer take?
- What network capacity would be required?
- Are there data-transfer or egress costs?
- Are there geographic or data-residency requirements?
- How will data integrity be verified following a move?
- What happens to the original copies after the transition?
For data-intensive workloads, moving the application may be the easy part.
The volume, location and architecture of its data can have a much greater impact on how practical a future migration would be.
Understand the Dependencies You’re Creating
Every infrastructure decision creates dependencies.
The question isn’t whether dependencies exist. It’s whether the organization understands them and considers them worthwhile.
A workload may depend on proprietary services, APIs, databases, security capabilities, networking constructs, automation tools or operational processes available within a particular environment.
Those capabilities can deliver significant value.
But the deeper the application becomes integrated with environment-specific services, the more work a future migration may require.
Microsoft’s Azure Well-Architected Framework similarly cautions that relying on platform or vendor solutions can introduce dependencies and recommends developing an exit strategy when the solution and workload requirements significantly diverge.
Vendor Lock-In Isn’t Automatically Bad
“Vendor lock-in” is often treated as something that should always be avoided.
That oversimplifies the decision.
A provider-specific capability may deliver enough performance, efficiency, functionality or operational value to justify the dependency it creates.
The more useful questions are:
What are we gaining from this dependency?
And:
What would it cost—in time, money and complexity—to unwind it?
If the organization understands both sides of that tradeoff, it can make an informed decision.
Avoiding every dependency can create its own complexity. AWS’s multicloud guidance similarly notes that using multiple providers can introduce additional operational costs and challenges and should be driven by actual business requirements rather than multicloud for its own sake.
Flexibility should be intentional, not theoretical.
Look at the Contract Along With the Architecture
Cloud portability isn’t purely a technical issue.
The architecture may allow a workload to move while the commercial agreement makes moving difficult—or expensive.
As part of a cloud migration strategy, organizations should understand:
- Contract length and renewal provisions
- Termination rights
- Minimum commitments
- Data-transfer provisions
- Support during a transition
- Responsibilities at contract termination
- Time required to retrieve or transfer data
- Any services tied to specific commitments
AWS includes contractual commitments and termination rights among the legal considerations organizations may need to evaluate in a cloud exit strategy.
Technical flexibility and contractual flexibility should be evaluated together.
Consider the People and Processes That Have to Move Too
Infrastructure isn’t the only thing that becomes connected to an environment.
People do too.
Over time, IT teams develop expertise around specific platforms. Automation is created. Monitoring and security processes evolve. Documentation reflects a particular architecture. Operational procedures become familiar.
Moving a workload may therefore require more than transferring applications and data.
Organizations should ask:
- Do we have the skills required to operate the workload somewhere else?
- Which operational processes would need to change?
- What automation would need to be recreated?
- Would monitoring and security tools continue to work?
- What documentation would need to be updated?
- Who would own and execute the transition?
This is one reason exit planning shouldn’t begin when an organization has already decided it needs to leave.
By then, years of technical and operational dependencies may already be embedded in the environment.
Hybrid and Multicloud Don’t Automatically Solve Portability
One response to concerns about cloud vendor lock-in is to spread workloads across multiple providers.
That can make sense when different environments serve distinct workload, geographic, resiliency or business requirements.
But simply operating in more than one cloud doesn’t automatically make workloads portable.
In fact, a poorly designed multicloud environment can introduce another layer of complexity: different tools, security models, operational processes, skill requirements and provider-specific services.
Using multiple cloud providers should deliver enough value to justify the additional costs and complexity the approach can introduce.
The objective should not be:
How many clouds can we use?
It should be:
How much flexibility does this workload actually need, and what architecture provides it without creating unnecessary complexity?
Test the Assumptions Behind the Exit Strategy
An exit strategy that exists only on paper can create a false sense of flexibility.
If portability matters for a critical workload, some assumptions should be validated.
Could the data actually be exported?
Could the application run somewhere else?
Are current backups usable outside the existing environment?
How long would a transfer take?
Does the organization still have the skills and documentation required to execute it?
AWS recommends testing cloud exit strategies and challenging the assumptions behind them through exercises where appropriate.
That doesn’t mean every organization needs to perform a full migration exercise for every workload.
The amount of testing should reflect the importance of the workload and the consequences of discovering that an assumed exit path doesn’t work.
Add an Exit Test to Your Cloud Migration Strategy
Before approving a new infrastructure destination, add one more step to the evaluation.
Ask:
If our requirements changed two years from now, what would it take to move this workload again?
Then consider five areas:
1. Application
How dependent will the application become on the target environment?
2. Data
Can the organization’s data be retrieved, transferred and used somewhere else within an acceptable timeframe and cost?
3. Operations
What tools, automation, processes and skills would have to change?
4. Commercial Terms
Do contracts, commitments or data-transfer provisions materially affect the ability to leave?
5. Migration
Is there a realistic technical path from the new environment to another one?
The answers don’t all have to be simple.
They need to be understood.
Flexibility Is Part of the Infrastructure Decision
There is no infrastructure environment with zero dependencies.
Nor should eliminating dependencies be the objective of every cloud migration strategy.
The goal is to understand the choices being made.
A workload may be an excellent candidate for a deeply integrated public-cloud architecture. Another may benefit from dedicated private-cloud infrastructure. Some applications may remain on-premises, while others may operate across a hybrid environment.
Each choice comes with different advantages, dependencies and degrees of portability.
The important thing is to evaluate those factors before they become constraints.
Because a good cloud migration strategy doesn’t just answer:
Where should this workload operate today?
It also asks:
How much freedom do we want to make a different decision tomorrow?
Frequently Asked Questions About Cloud Exit Strategy
What is a cloud exit strategy?
A cloud exit strategy outlines how an organization could move workloads, applications and data from a cloud provider to another environment if business, technical, regulatory or commercial requirements change. It can address technical migration requirements as well as data, operational, contractual and staffing considerations.
Is a cloud exit strategy the same as avoiding vendor lock-in?
No. Avoiding every provider-specific service or dependency may unnecessarily limit functionality and create additional complexity. An exit strategy is about understanding dependencies, determining whether their benefits justify them and knowing what would be required to change environments later.
What is cloud portability?
Cloud portability generally refers to the ability to move applications or data from one cloud environment to another. NIST’s cloud-computing guidance treats both workload and data portability as important considerations and notes that the complexity of moving each can differ.
Should every workload be designed to run in multiple clouds?
Not necessarily. Designing every workload for multiple environments can introduce additional cost and operational complexity. The appropriate level of portability should reflect the workload’s business requirements, risk, importance and the value of retaining future infrastructure choices.
Reassessing Your Cloud Strategy?
Infrastructure decisions shouldn’t begin with a predetermined destination.
EnTelegent Solutions helps organizations and their Technology Partners evaluate workload requirements across private cloud, public cloud, hybrid infrastructure, connectivity and managed services.
Whether you’re planning a migration, reconsidering an existing environment or evaluating where a new workload belongs, we can help you understand the requirements and options before you make the move.
