Cloud migration to AWS and Azure, planned application by application

Why so many migrations go off track

A cloud migration rarely fails because of the provider. It goes off track because the inventory was incomplete, because a hidden dependency (a file share, an overnight job, a hard-coded IP address) was discovered on cutover day, or because the target foundation was not ready and “temporary” network access was opened and never closed.

The other common causes are well known: a cost estimate based on a price list rather than a specific architecture, an underestimated dual-running period, application teams brought in at the last minute, and no written rollback plan.

Our approach is designed to deal with these risks before they become expensive: discover, decide, rehearse, then cut over. We work with companies in the Lille area, and across France and Europe, on AWS and Azure alike.

Our migration approach

1. Discovery and inventory

We catalogue servers, databases, applications and data flows, along with their dependencies, maintenance windows and business owners. The providers’ discovery tools help collect technical data; interviews with your teams provide what the tools cannot see: criticality, availability constraints and ongoing projects.

2. A strategy per application, using the 7Rs

Each application is assigned one of the seven options of the 7Rs model, described in AWS’s migration guidance. The table below summarises when we choose each one; the method is covered in detail in our article on cloud migration strategy and the 7Rs.

Strategy	When we choose it
Retire	The application is barely used or no longer used: migrating it would mean paying for nothing.
Retain	Strong latency, licensing or timing constraints: the application stays where it is, for now.
Rehost	Tight deadline, stable application: the machines are moved as they are and optimised afterwards.
Relocate	A VMware estate that needs to move quickly to a hosted VMware offering in the cloud.
Replatform	Quick wins for little effort, for example moving a database to a managed service.
Repurchase	A SaaS product meets the need better than an application maintained in-house.
Refactor	A strategic application whose roadmap justifies a redesign around cloud-native services.

3. Preparing the target foundation

Before the first wave, the landing environment must be ready: AWS account or Azure subscription structure, network and connectivity with the existing site (VPN or dedicated link), identities and permissions, logging, backups, budgets and alerts. All of it described as code. This foundation is covered in detail on our AWS and Azure pages.

4. Migration in waves

Applications are grouped into coherent batches according to their dependencies: systems that talk to each other a lot move together. The first wave deliberately covers low-criticality applications, to test the tools, procedures and coordination. Later waves increase in criticality.

Every wave follows the same sequence: data replication, functional and performance testing in the cloud by business teams, a cutover rehearsal, then the actual cutover in an agreed window.

5. Cutover and rollback plan

For each wave, a rollback plan is written and tested before cutover: objective trigger criteria, who makes the call, the steps to return to the source, and the maximum time allowed to do so. The original environment remains available throughout the stabilisation period. A cutover with no possible rollback is a gamble, not a plan.

6. Stabilisation and optimisation

After cutover comes rightsizing instances based on real measurements, putting pricing commitments in place once usage is stable, and decommissioning the old resources. This is where the FinOps work begins.

Migrating on-premises and VMware workloads to the cloud

Changes to VMware licensing are leading many companies to rethink their virtualisation. There are three routes, often combined:

• Stay on VMware, but in the cloud. AWS and Azure each offer a way to run a VMware environment on their infrastructure (Amazon Elastic VMware Service on AWS, Azure VMware Solution on Microsoft’s side). It is the fastest way to free up a data centre, but it does not settle the long-term licensing question: check this against your contract.
• Rehost the virtual machines on native instances, using the providers’ replication tools (AWS Application Migration Service, Azure Migrate). You leave the hypervisor behind, but you still have servers to manage.
• Modernise the applications that justify it towards managed services: databases, containers, object storage.

The choice is made per application, weighing licensing, timelines and acceptable effort. Exiting VMware is also a chance to decommission what is no longer used.

Deliverables

• Application inventory and dependency map.
• Decision record: the strategy chosen for each application, with its rationale.
• Target cost estimate based on the chosen architecture, including dual running.
• Wave plan and cutover schedule agreed with the business.
• Target foundation as Infrastructure as Code (Terraform or OpenTofu).
• Cutover runbooks and rollback plans for each wave.
• Operations documentation and knowledge-transfer sessions.

Pitfalls to avoid

• Migrating without decommissioning. Paying for both the old and new environments for longer than planned quickly wipes out the business case.
• Re-architecting everything at once. A redesign is justified for a few strategic applications, not for the whole estate.
• Rehosting everything without rightsizing. Reproducing servers sized for a peak from five years ago sends the bill soaring.
• Opening the network “for now”. Temporary rules become permanent. Security is set up before the first wave.
• Forgetting about licences. Windows Server, SQL Server, Oracle: their terms of use in the cloud change the equation and must be checked early.

How we work with your teams

We do not migrate on your behalf inside a black box. Your infrastructure and application teams take part in decisions, review the code and run the rehearsals alongside us. Each wave builds their autonomy: by the last one, they should be able to run a cutover on their own. This follows our Scope, Build, Industrialise, Improve method, described on our AWS and Azure cloud consulting page.

Who it is for, and when to call us

• A hosting or data centre contract is coming to an end.
• Your VMware infrastructure or hardware is due for renewal.
• A first migration was done in a hurry and the cloud environment needs reworking.
• You want an independent opinion on a migration plan proposed by another provider.

If you are in one of these situations, book a 15-minute call to talk it through.

[ YOUR QUESTIONS ]

Frequently asked questions

How do you migrate to the cloud?

Start with an inventory of applications and their dependencies, then choose a strategy for each application. Next, prepare the target foundation (accounts or subscriptions, network, identities, security), and only then migrate in waves, each one rehearsed and backed by a rollback plan.

How much does a cloud migration cost?

The cost depends on the number of applications, the strategy chosen for each and the complexity of their dependencies: we do not give a figure before the inventory. You also need to budget for a dual-running period, when the old and new environments run in parallel. Providers sometimes offer funding programmes, and eligibility has to be checked case by case.

Why migrate to the cloud?

The strongest reasons are practical: a hosting contract ending, hardware renewal, changes to virtualisation licensing, or a need for managed services and on-demand environments. If there is no clear reason, a migration can cost more than it returns, and we will tell you so.

How do you migrate VMware virtual machines to the cloud?

There are several routes: rehost the virtual machines with the providers’ replication tools, use a hosted VMware offering on AWS or Azure to save time, or modernise towards managed services. The choice is made application by application, based on licensing, timelines and acceptable effort.

How long does a cloud migration take?

It ranges from a few weeks for a small scope to several months for a full data centre. The duration depends mainly on dependencies between applications, the cutover windows the business can accept and the availability of application teams.