// Guide · Cloud
Preparing a cloud migration: the checklist before the first move
What has to be settled before a single application is moved — from dependency analysis through identities and connectivity to the route back.
// Preface
Sequence decides the outcome, not the platform
Which cloud it should be is usually the first question asked and rarely the most important one. What matters is which applications are meant to move at all, what data flows between them, and in what order the move can happen without stopping the business.
That preparatory work is called readiness. It sounds like paperwork and is in fact the part that saves the evenings later. How a cloud environment is then built and operated is covered on our page about cloud solutions; the orderly move itself is described under cloud migration.
The list below is written so you can work through it without a provider in the room. If you get stuck on three points, you have found the scope of the project.
// Readiness
Six points that come before the decision
Each one is a question to your own organisation. Answer them and you will get proposals with substance instead of a platform recommendation.
-
Inventory every application
Including the small database in accounts and the tool only one department uses. Those are exactly the systems that turn up later as blockers.
-
Make dependencies visible
Which application talks to which, over what interface, in which direction? Anything connected has to move together or needs a bridge in the meantime.
-
Settle data protection and location
Where is personal data processed, which agreement governs it, and who has technical access? That review belongs before the selection, not after the move.
-
Check the site connection
After the migration everything runs over the internet line. Bandwidth, availability and a fallback path have to match the new dependency.
-
Put identities in order
A central directory with clean accounts and a second factor is the precondition. Neglected user accounts otherwise move across one for one.
-
Review licences and contracts
Not every licence may be run in someone else’s environment, and the remaining term of existing agreements helps decide when a move makes commercial sense at all.
// A decision per application
Three routes, all three legitimate
Sort every application on your list into exactly one of these columns. Only then is a conversation about platforms worth having.
Take it across as it is
The application moves unchanged into a rented environment. Quick to do, but nothing changes about how it is built or how much care it needs.
- Suits a short window or hardware reaching end of life
- Costs stay visible, savings are modest
- Running it remains your responsibility
Replace it with a service
Instead of your own installation, a ready-made service takes over. The largest benefit and the largest intervention in established habits.
- Maintenance and updates disappear from your side
- Processes adapt to the service rather than the other way round
- Data transfer and training are where the real effort sits
Deliberately keep it in-house
Some systems belong where the data is created — beside machinery, next to large local holdings, or in an application about to be replaced.
- Short paths to production and measurement equipment stay intact
- No move for a system that is being retired anyway
- Mixed operation has to be factored into the network design
// Execution
In waves rather than on one date
After each wave there is a state in which the business can carry on normally. That is the difference between a project and a weekend with an open ending.
Build the foundations
Directory, sign-in, permissions and network connectivity come first. Without that base, every application lands on uncertain ground.
Start with the uncritical
Begin with systems whose failure does not stop the business. This wave is the dress rehearsal for process, communication and timing.
The interwoven systems
Applications that talk to each other move together. This is where you find out whether the dependency analysis was complete.
Switch off the old systems
Legacy systems only leave the network once the new environment demonstrably holds. Running both costs money, but less than a retreat with no way back.
// Safety net
The rollback plan nobody enjoys writing
Before every wave it should be clear how the previous state gets restored. These points belong in writing before the first application is touched.
- Who decides to abort, and up to what moment that decision is still available
- How long the old system stays operable, not merely switched on
- How data already changed in the new environment finds its way back
- Which accounts and forwarding rules have to be reversed for that
- Who informs the workforce, and by what route if email is the thing that is down
- When a wave counts as finished, so the way back can be closed
// Common questions
What comes up before a cloud migration
01 Where does a migration sensibly begin?
With a complete list of applications and their dependencies, not with picking a platform. Migrations tend to stall at an interface nobody thought about, precisely because it appeared on no list.
02 Does everything really have to move?
No, and that assumption causes avoidable cost. Systems handling large volumes of local data, software tied to machinery, or applications close to being replaced are often better left where they are. Moving is a decision per application, not per company.
03 What happens to our internet line?
It becomes a critical component. What used to run inside your own network afterwards runs across the connection, telephony and file access included. Bandwidth, availability and a second path for outages therefore belong before the migration, not after it.
04 How long does a project like this take?
That depends on the number of applications and how tightly they are woven together, not on the volume of data. A realistic approach runs in waves across several months, with a stable state after each wave, rather than a single date on which everything moves at once.
05 How much does the location of the data matter?
A great deal, as soon as personal data is involved. Where processing happens, which agreement governs it and who has technical access all belong before the decision — pulling a migrated data set back afterwards takes considerable effort.
06 What changes for day-to-day operations afterwards?
Work shifts from looking after hardware to managing accounts, licences and cost. Cloud environments grow quietly: without firm control over what has been created and by whom, a year later you are paying for things nobody can name.
Further reading
All guides
How many applications are on your list?
Once the list exists, we sort it into the three routes with you and propose an order that fits around the work your teams still have to get done.