Moving to the cloud without turning it into a bet

Why migrations go wrong

Nearly always in the same place: you find out mid-project what the application actually does. An undocumented nightly batch, an IP address hard-coded years ago, a network share mounted from someone's desktop, a certificate renewed by hand by a person who has since left. None of that appears on the architecture diagram.

So the inventory is not a formality at the start of the project, it is where the schedule is decided. Until you know what talks to what, any announced date is an opinion.

How a cutover is prepared

Start from what exists: what runs, what talks to what, what has to stay reachable from outside, who holds the access. Then every component gets an explicit decision. Move as is, replace with a managed service, rewrite, or switch off. Switching an application off is the cheapest migration there is, and there are always one or two.

The move happens in batches, never as one night for the whole estate. Each batch arrives with its rollback plan written beforehand, not during: what triggers the rollback, who calls it, and how long there is to do it. A rollback nobody has tested does not exist.

Data usually decides the rest. A database that copies overnight and a database that takes three days are not migrated the same way. The first tolerates a downtime window, the second forces replication and an integrity check afterwards.

Where we are the wrong answer

If the application cannot be changed, the cloud will cost you more, not less. A machine left running at a provider costs more than a server already written off in your own room. The savings come from being able to switch off, resize, or replace a component with a managed service. Without permission to touch the code, you get the bill and none of the upside.

Lift-and-shift often just moves the bill. Rehosting your virtual machines unchanged solves a hosting problem and no architecture problem. It is sometimes the right call when the date is imposed, but it has to be owned as a step rather than sold as modernisation.

And a migration with no rollback plan is a gamble. If your schedule leaves no room to prepare and test that rollback, we will say so before we start and not on the evening of the cutover. If you are looking for a supplier who signs the date as it stands, that is not us.

Where the data sits, and who touches it

Our engineers can work inside your environment, on your infrastructure, with your accounts and your access controls. In that setup the data does not move, which removes a large part of the transfer questions before they are asked.

On security, the precise position: our practices follow ISO/IEC 27001 principles and are mapped against CyberFundamentals from the Belgian Centre for Cybersecurity, with the Stage 2 audit planned with a BELAC-accredited body in 2027. We are not certified today, and you should hear that from us rather than find it in a procurement questionnaire.

Contracting runs through JADEV GROUP SARL in Belgium, in euros, under Belgian law. The engineering team is in Rabat and Casablanca at UTC+1, the same working day as Brussels, Paris and Amsterdam. On cutover day that matters.