Your managed hosting contract is coming to an end, and someone has suggested moving to AWS. The decision looks technical. In practice, a cloud migration rarely fails over the choice of server type: it goes off the rails because of a forgotten integration, a cache that fools the team, or a question nobody answered, "who applies the patches now?".
I run technical projects, I do not provide managed hosting, and I would rather say so straight away. This article describes the project lead's work, not the hosting provider's: what I prepare, in what order, and what I refuse to leave vague before the switchover.
01What a cloud migration really changes
With a managed hosting provider, a lot gets done for you without being written down anywhere: system updates, backups, overnight monitoring. When you move to AWS, part of that work changes hands. AWS describes this in its shared responsibility model: it manages the infrastructure and physical security, while the customer remains responsible for the guest operating system, its patches, the applications and the firewall configuration (AWS, shared responsibility model).
France's data protection authority, the CNIL, says the same thing in other words. Among the mistakes it lists are assuming that security is the provider's job alone, migrating without spotting the data that is too sensitive for the cloud, and keeping backups in the same data centre (CNIL, cloud security).
The contract changes too. The EU Data Act requires cloud providers to make switching provider easier, and removes switching charges, including data egress charges, from 12 January 2027; until then, they can still be billed (European Commission, Data Act explained). I am not a lawyer, but I ask the question every time: how much will leaving cost, with the old provider now and with the new one later?
02Take the inventory before talking architecture
The first meeting of a cloud migration often drifts towards which AWS services to use. I bring it back to a more ordinary list. Until it exists, any discussion of architecture rests on guesses.
The five columns of my inventory
- The application or service (website, back office, API, scheduled jobs, outgoing mail).
- What it depends on: database, file storage, ERP, CRM, payments, domain name and DNS.
- The data it holds, how sensitive it is and where it must stay.
- Who looks after it today, at the hosting provider and in-house.
- What happens to it: move it, keep it, replace it or switch it off.
The third column avoids surprises. On an integration between two tools, I learnt on a project that mixing centimetres and millimetres could distort an entire output. Since then, I look for which data is the reference and where that is written down. A migration is the right moment to record it, because the data flows are about to be reconnected one by one.
This inventory becomes the basis of the migration specification. I version it, as I did on an ERP and e-commerce integration specification that changed at almost every meeting: everyone talks about the same document, with a version number at the top.
03Choose a strategy per application, not one for everything
AWS describes seven migration strategies, the "7 Rs": retire, retain, rehost as is, relocate, repurchase (move to software as a service), replatform with a few adjustments, or refactor the architecture (AWS Prescriptive Guidance, migration strategies). The same page advises against refactoring during a large migration and recommends modernising once the move is done.
What I take from it is the idea of one decision per inventory line. A back office used by three people can stay where it is. An old campaign site can be switched off. The main website can be moved almost as is. Filling in the fifth column with those words forces everyone to take a position.
In a re:Invent talk, Jake Burns, from AWS's Executives in Residence team, warns against mixing migration and modernisation: you multiply one complexity by another (AWS Events, accelerating large-scale migration). He also says he gave himself 12 months for his own migration, that it took 17, and that with a 17-month deadline he thinks it would have taken two years.
That is the view of an AWS executive, so of a cloud vendor, but I agree with him on the deadline. I started out in television and film production, where the broadcast date does not move, and I know what a fixed date forces you to decide.
One limit, though: rehosting as is does not make the site faster or cheaper by magic. If the site has problems, they move with it. That is why I run a technical audit before moving anything, to know what you are taking with you.
04Write down who does what after the switchover
This is the part I refuse to leave vague. After the migration, someone has to apply patches, monitor, restore a backup at three in the morning and renew certificates. If nobody's name sits next to those lines, the first incident will tell you who it was meant to be.
I make a simple table, one row per task, with three columns: AWS, the operations supplier if there is one, and the in-house team. The shared responsibility model fills in the first column. The CNIL asks for this split to be set out in a contract (CNIL, cloud security), and I have the table read by the people who will sign.
Handing operations to a supplier after the migration is a sound choice. Jake Burns argues for another route in the same talk: he finds it easier to teach cloud skills to your own teams than to teach how your organisation works to outsiders. Both hold up. What does not hold up is making no choice at all. I present this table to the steering committee, so that a decision is taken and written down.
05Rehearse the switchover and check as a visitor
For a site whose addresses do not change, Google describes a procedure that I follow as written (Google Search Central, changing your web hosting). You copy the site to the new infrastructure, test it on a temporary hostname blocked from indexing, check that the firewall lets Googlebot through, and lower the TTL of your DNS records at least a week beforehand.
On the day, you remove the indexing blocks, change the DNS, then watch the logs on both servers. The old hosting is only switched off once its traffic has dropped to zero.
My switchover day list
- A full rehearsal, a few days before, on the test environment.
- A short write freeze for the final copy of the data.
- A comparison of counts and a few sample records, old against new.
- A written rollback plan: who decides to go back, before what time, and how.
- A check in a private window on the public address, with a form sent and a test order placed.
That last point comes from a mistake I saw on a project: a site that looked normal to the logged-in team was broken for visitors, because of a cache. Since then, I check as a visitor, not with the team's session. I borrow a rule from my content machine: a check that did not happen counts as a failure, never as a success by default. My acceptance testing and go-live checklist covers the rest.
Google also warns that a temporary drop in crawling is normal just after a hosting change, and that it picks up again over the following days. I tell the marketing team before the switchover, to avoid a pointless alarm the next morning.
06Where to start if your contract is ending
If your managed hosting contract is nearing its end, this is what I would do on Monday:
- Reread the current contract: notice period, reversibility, exit charges, format in which the data is handed back.
- Start the five-column inventory with the person who knows the system best, even if it stays incomplete.
- Set a switchover date that is realistic but close, and keep to it.
- Fill in the "who does what" table before choosing a single AWS service.
None of this needs advanced cloud skills, only order and written decisions. If you would like someone to run this migration alongside you, the services page explains how I work, and the portfolio shows the kind of projects I lead; we can talk it through.