Cloud migration: moving what you have without breaking it

A cloud migration rarely breaks during the copy. It breaks when you think you have finished. In July 2026, the disk of our server, which runs a dozen services including the CRM of Palmora Property, a property portal that we operate for its agency, was full, and the databases on it were at risk: the CRM itself stored the property photos there. We moved them to object storage without losing a single file; the catch was access keys that did not reach the application.

By migrating, we mean moving what already runs (applications, data, files, domain names) to a major provider, to another host, or back onto a server of your own. This is the method we apply, workload by workload, for teams of 20 to 500 people. It assumes that the infrastructure foundation that will host these workloads already exists.

What should you inventory before migrating?

Google Cloud’s migration guide splits a migration into four phases: assess, plan, deploy, optimise. The first is there to “understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks”.

Dependencies decide the order. According to Microsoft’s planning guide, “dependencies between workloads cause service disruptions if not migrated together”, and each batch has to take along what its applications need, “including supporting infrastructure such as load balancers, DNS records, or caching layers”.

Also take stock of what your users keep on their side. For a browser, a different address is a different application: when Challenge Us, a group challenge app that we built, changed address in September 2026, the session, the settings, the installed app and the notifications stayed on the old one.

Which strategy for each workload?

AWS’s guide to large migrations sorts the options into seven strategies, the “7 Rs”:

• Retire: decommission or archive what is no longer used.
• Retain: keep in place, for now or for good.
• Rehost: move to a new host without changing anything, the “lift and shift”.
• Relocate: transfer many servers to the cloud version of their platform.
• Repurchase: replace with a different version or another product.
• Replatform: move with a little optimisation along the way.
• Refactor or re-architect: rework the architecture to take advantage of cloud-native features.

For a large migration, AWS advises against refactoring, “because it involves modernizing the application during the migration”, and recommends “rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete”.

The three migrations we have carried out fit into these boxes: Palmora Property’s daily synchronisation, rehosted on our server without changing its steps; the storage of its CRM files, replatformed through configuration, without touching the code; the pages of Challenge Us, moved to another host without being rewritten. We have not carried out any migration to AWS, Google Cloud or Azure: their guides serve here as a common vocabulary, whatever the destination.

Why copy rather than move?

Copying keeps the original intact until the copy has proved itself: rolling back then comes down to one line of configuration. For the files of Palmora Property’s CRM, after a read-only survey, we put four safeguards in place:

• A separate storage space: the one holding the site’s images has its orphaned files purged, and in a shared space that clean-up would have erased the CRM’s files.
• A dedicated access key, limited to that space, which can be revoked without touching the site.
• Files that stay private, served by the CRM behind its own authentication.
• A backup of every configuration file, with the old value kept as a comment: that is the rollback.

This CRM is Twenty: we have run it in production since early 2025, and we contribute to the project. It can store its files in S3-compatible storage, that is, storage that exposes the same interface as Amazon’s storage service: we checked this in its code. The trap was elsewhere: the container configuration passed on only some of the storage settings, without the access keys. They had to be added to the main service and to the background-jobs service.

How do you check before switching over, then before purging?

Before the switchover, access to the new storage was tested for reading and writing, the copy finished without errors and the new configuration was validated. After the switchover, three tests, and a fourth after the purge:

1. 01Reading

   A record with photos opens, served from the new storage.

2. 02Writing

   An image that is added lands in the new storage, and the old folder does not change.

3. 03Integrity

   Comparing the two sides finds no difference. This test is what authorises the purge.

4. 04Final proof

   With the old folder emptied, any image that is still displayed must come from the new storage.

One limit: the comparison covered file names and sizes, in one direction only, with no content checksum. It shows that nothing is missing, not that every byte is identical.

How do you switch over with a way back?

The rollback is decided before you start. Microsoft spells it out: “Always establish rollback criteria and procedures before initiating any migration or deployment.” Its triggers are measurable, such as “CPU usage limits, response time thresholds, or error rates”, and the procedure is tested: “Verify that the rollback procedure restores the system to a stable, known-good state.”

For a domain name, everything depends on the order of the steps. When Challenge Us changed address, a redirect would have frozen the application: its service worker, the small program that serves it from the browser cache, never updates through a redirect. So both addresses served the same version, and the old one only offered users the move once the new one was ready.

When Challenge Us later changed host, the operation happened in four stages.

Our rule since then: keep the record and go through a routing rule, or delete it and attach the name straight away, never one without the other.

How long should you keep the old path?

A migration does not always go to the cloud. Since 23 July 2026, the daily synchronisation that feeds Palmora Property’s site from its CRM has been running on our own server, no longer in an online continuous integration service. The CRM is local there, the caches live on disk, the steps and the schedule have not changed, and a lock stops two runs from overlapping.

The old path has remained, as a manual fallback. But a fallback ages: its cache has been frozen since July, and it would recheck thousands of objects and could run for hours. For Challenge Us, the old address will never be cut off: it costs nothing, and it is what brings the already-installed apps back. So keep the old path for as long as someone uses it, and check from time to time that it still works.

When to purge, and what to measure afterwards?

The purge comes last, after the comparison, and with safeguards: an exact path, and a check that the folder really contains what you expect. After it, rolling back is still possible but changes in nature: about an hour of copying back, the configuration restored, a restart. Our article on what really breaks when you back up your own server makes the same point: a copy is only worth something if you know how to put it back.

Then measure.

Challenge Us, for its part, measures who still opens the app through the old address.

Keeping part of it in place: is a hybrid a failure?

No, if it is deliberate. AWS makes “Retain” a strategy in its own right, and cites, among its refactoring cases, a database some of whose tables, “such as customer information, patient, or patient diagnosis tables”, stay on premises for security and compliance reasons. Microsoft asks you to document why a component stays on premises, and to limit the in-between period: “Minimize split-environment operation time.”

Both of these client projects are hybrid, by choice. Palmora Property’s CRM runs on our server, its files live in object storage, and a weekly clean-up task stays, for now, in the continuous integration service. Challenge Us changed host for its pages, but its database, accounts and server functions have not moved. For what comes next, our analysis of Europe’s dependence on the American cloud explains what European law changes about the fees for switching provider.

The checklist before the switchover

• The copy finished without errors, and the original is intact.
• The new settings reach every service concerned, not just the first one.
• Reading and writing are tested on the new destination.
• The conditions for rolling back are written down, with the name of who decides.
• The old path stays open, and you know for how long.
• A signal will warn you if the new path stops running.

Where to start

List what has to move, with a strategy and a rollback condition for each line. Start with a workload that is easy to roll back, files for example. If your tools need to leave their subscriptions for a server of your own, our Leaving SaaS offer moves them one by one, with verified data and a rollback planned. If the destination is a major provider or a European cloud, write to us with what has to move and where you want to take it.

Frequently asked questions

Sources

1. Google Cloud’s migration guide (new tab)docs.cloud.google.com
2. Microsoft’s planning guide (new tab)learn.microsoft.com
3. AWS’s guide to large migrations (new tab)docs.aws.amazon.com