Migration strategies

Introduction

Define the migration strategy Go to page means choosing how to move applications and data to the cloud commensurate with the expected value and available resources. There is no absolute best strategy: the decision is made on a per-service basis after the assessment Go to page , considering priorities, time, budget, skills and constraints.

Strategies in brief

Retain (conservation)

A decision is made not to migrate an application but to set a review date. It is useful with newly purchased software, technical dependencies that cannot be overcome, lack of SaaS alternatives (Software as a Service) or security requirements that require on-premise (on their own servers) permanence.

Retire (dismantling)

Applications that are no longer useful or redundant are decommissioned. This strategy requires careful management of historical data and verification of dependencies before final shutdown.

Re-purchase (replacement)

You replace the software installed on your servers with a qualified SaaS solution. This choice eliminates infrastructure management, accelerates upgrades, and shifts the focus from technical maintenance to service utilization.

Re-host (host transfer)

You move the application to the cloud without major changes to the code (approach lift & shift), often using automated migration tools. It is the fastest approach but does not take advantage of cloud capabilities: it requires a subsequent optimization phase to reduce costs and improve performance.

Re-platform (platform transfer)

You migrate the application to the cloud by replacing some components with managed services (e.g., database, load balancers, storage). It brings targeted benefits in reliability, scalability and maintenance through incremental and measurable transformations.

Re-architect (refactoring/new architecture)

You redesign the application from a cloud-native perspective to maximize scalability, resilience and speed of evolution. This is the most challenging approach because it requires time, specialized skills, automated testing and progressive releases, but it is the one recommended for the organization's strategic systems.

How to choose the strategy

The choice is based on the assessment of each service. In practice, the entity evaluates service role, technical dependencies, code status, frequency of use, security and interoperability requirements, as well as cost and time. A rule of thumb to keep in mind is this: the greater the transformation, the greater the benefit to the entity, but it will also mean more time, expertise and budget.

It is therefore convenient to define measurable objectives, constraints, and available resources for each application, choosing the option that offers the best ratio of expected benefits to required effort. It is often effective to combine multiple strategies for different components of the same system.