Why you should build a cloud mobility strategy into your cloud adoption plans

Justin Campbell CTO@junkshon

Moving workloads to the cloud might feel like a final step in a long journey, but in reality, you need to build contingency plans to move from one cloud to another or even to move workloads back on-premise.


So, why might that be? Here’s just a few potential scenarios:


  • Regulated industries that may require you to have a cloud mobility plan to comply with governing bodies. Financial services is a good example of this.

  • Service quality, if you are unhappy with the service quality with one provider for some reason, you may wish to move. This is not limited to the cloud but a general scenario for all information technology services.

  • Mergers and acquisitions or divestitures. You may need to split your business and either move cloud provider or return to on-premise.

  • Cost and technical requirements. It is important to monitor the economics and technical architecture of your cloud footprint. It could be that your specific workloads are better suited to a different provider due to cost or better technical solution.

The chances are you’ll never need to roll back your cloud migration in these ways, but it is essential that you understand your options and don’t leave it to chance.


In today's digital world, companies can no longer do without the advantages of the cloud to support all or parts of their business. In fact, the pressure to undertake digital transformation sometimes makes it feel like a race to the cloud.


But when you are planning a cloud migration, you need to create a mobility strategy. This could include adopting multi-cloud or how to move workloads back on-premise if required.


The five areas to consider when developing your exit strategy:

  • Processes

  • Cost

  • Commercials

  • Skills

  • Technology

Processes: As you adopt cloud technology, you will be developing new processes for operations (monitor), management (patch), deployment (development lifecycles) and financial management. When moving your workloads, you will need to factor in the potential cost of redefining those processes and touchpoints with the cloud providers' various interfaces.


Cost: is an important factor to consider when building an exit strategy. The cloud provider may charge to migrate data from their cloud. You may also need to retrain staff and potentially purchase services and software to replace cloud provider specific solutions.


Commercials: while the cloud provides greater flexibility than traditional infrastructure technology outsourcing (ITO) contracts, there are considerations to be made about committing to reserved instances; upfront payments for services.


Skills: Skills play a significant role in migrating and operating workloads in the cloud. You will invest in cloud architects, dev/ops teams and security experts specialising in a particular cloud provider’s technology. This skills gain takes time and money. Going multi-cloud can, if not managed correctly, increase resourcing costs as well as stretching your skills base very thin. The cloud market is a hot-bed of continuous innovation.


Technology – Technology can, in some cases, cause vendor lock-in. This is increasingly the case when you start to adopt proprietary technology that the cloud providers offer to differentiate themselves in the market. On the one hand, these innovations can give you a critical competitive edge, but that can lock you into a specific technology and hinder your ability to move between clouds or back to on-premise.


Below are some tips that should ensure you avoid nasty surprises if you decide to execute your cloud exit plan.

  1. When building your cloud strategy, you should develop application deployment patterns for your different workloads. This will allow you to evaluate the potential exit strategy/cost associated with selecting a specific solution.

  2. Building on this, develop KPIs to help you assess the solutions you choose in the cloud so you can better manage the lock-in risk and build the associated costs into your strategy and business case. I like to think of those KPIs being as follows:

  1. When migrating to the cloud and selecting your target solutions, Performance, Function, Purchase Option and Fit to use case: (PFPU)

  2. When assessing the migration exit strategy, you should be assessing against Cost, Time, Operations and Risk: (CTOR)



You also need to maintain an inventory of your estate. This is not just a list of your servers but all components, including management services that support your critical services and applications. You want to know at all times the state of your landscape to enable easy migrations.


Using open-source infrastructure services like Kubernetes or tooling like Terraform to build infrastructure across clouds or software such as OpenFaaS enables you to provide and manage application functions across different clouds, and on-premise deployments will help ensure you maintain a level of abstraction. You will not avoid using cloud provider native tools/services entirely, but evaluating your options and using open source alternatives can help.


When it comes to the operational aspects of exiting the cloud, and especially if you are moving back on-premise, you will need to be ready to take charge of everything that was previously the cloud provider's responsibility. Documenting your shared responsibility model as you enter the cloud is a good way of understanding what you will either have to take back in-house or outsource to the new provider.


In summary, it is essential to build a continuity plan to fully understand the people, process, technology and economics of exiting a cloud provider or any provider.


In my next blog post, I will be exploring the entry and exit KPIs in more detail as a mechanism to manage the cost/risk of operating workloads in the cloud.


Feel free to connect up with me on Linkedin or Twitter if you are interested in knowing more about what we do at junkshon.


47 views