Is your business planning to migrate applications and services into the cloud, but you’re still unsure of what the steps should be, and what each step requires?
Before anything else, the first step is to understand everything you have running in your current environment, and what the dependencies are. Armed with this information, you’re in a better position to decide what you should migrate first, and then work on how you’ll do the moving.
The Discovery and Planning Phase
Jaco Venter, head of the cloud management team at BBD, an international software development company and cloud managed services provider, recommends leveraging a tool that can assess your environment and discover the various servers and applications currently running.
Venter says that “when planning to migrate, this information will be vital as you would want to make sure that you move your applications in an optimised state”. He goes on to explain that it’s important to remember that the cloud allows you to deploy only what you need and then increase your resources when you identify additional demand or if your application’s requirements change.
By using this discovery process as an opportunity to identify what workloads would be easier to migrate and which would have a higher level of complexity, you’re putting yourself one step ahead of your plans from the start.
The top 6 cloud migration strategies unpacked:
- Rehost — otherwise known as “lift-and-shift”
When you rehost, you are essentially moving applications into the cloud without making any changes to them. It is the equivalent of carefully lifting your application and shifting it into the cloud.
This is often a go-to strategy when you’re looking to quickly meet business objectives because it can be simpler to optimise and re-architect once an application is already in the cloud, mostly because of the difficult part – the actual migration of the application, data and traffic – has already been done.
“Because they can be the quickest option to test functionality for a business, we often find that many early cloud projects either gravitate toward rehosting existing services or deploying net new workloads as their initial go-to cloud strategy. And although most rehosting can be automated with tools these days, it’s not always the best choice for your particular situation” clarifies Venter.
- Replatform — also known as “lift-tinker-and-shift”
Replatforming is when you make a few cloud (or other) optimisations in order to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application you’re looking to migrate.
Examples of some relevant “tinkering” include reducing the amount of time you spend managing database instances by migrating to a database-as-a-service platform like Amazon Relational Database Service or migrating your application to a fully managed platform such as Amazon Elastic Beanstalk.
Venter explains that this is often one of the options BBD prefers when helping clients plan for their migrations as it results in an improvement in performance, resiliency and operational costs.
The third migration strategy involves moving a legacy system from a perpetual licence to a SaaS (Software as a Service) model that provides similar capabilities.
Replacing your outdated on-premise software allows you to quickly migrate live data with little effort, and moves you away from needing to manage installed applications. If you’re looking to swap products or vendors for these services, this is an ideal opportunity.
An example of a repurchasing strategy would be to move from hosting your own email service to leveraging a product such as Microsoft 365.
- Refactor / Re-architect
Rearchitecting is a strategy that allows you to re-imagine how an application is architected and developed using cloud-native features. This is typically driven by a strong business need to add features, scale, or improve performance that would otherwise be difficult to achieve with the application’s current architecture.
This strategy would see you moving from a monolithic to a micro-service oriented and server-less architecture to boost agility and improve business continuity. “This strategy tends to be the most expensive, but it is often the most rewarding as it could considerably decrease operational costs” notes Venter.
For a more in-depth look at such a migration strategy and the benefits you could gain from cloud-native development.
“The best strategy often involves cutting the fat and rather focussing on what drives value for your business.”
After completing the discovery phase in your environment, it’s advisable to ask each functional area who owns each application.
AWS is quoted as “Finding as much as 10 – 20% of an enterprise’s IT portfolio is no longer useful and can simply be turned off”. This allows the organisation to reduce the overall complexity of the system, its running costs and future maintenance.
Maybe you’re still riding out some depreciation, you aren’t ready to prioritise an application that was recently upgraded or are otherwise not inclined to migrate some of the applications in your environment. When this is the case, a workable strategy is to retain the situation as is, for now.
Venter explains that one of the biggest reasons companies opt to retain a specific application is due to the technical debt associated with a recent investment into that application. “At this point, it wouldn’t make sense to move that application to the cloud, but that shouldn’t stop you from moving others while you sweat the new onsite hardware, networking or licensing you invested in.”