Most cloud migrations that fail don’t do so for technical reasons. They fail because someone moved a system whose dependencies no one had mapped out—only to discover it on Monday morning when invoices weren’t being sent.
Start with the inventory, not the technology
What are you running, where is it running, and what talks to what? The question sounds simple, but it is rarely answered fully on the first attempt. Legacy integrations, scheduled jobs on a forgotten server in the on-premises environment, and hardcoded file paths in an application are what derail schedules.
A thorough inventory also provides the basis you need to decide the order. The systems with the fewest dependencies are moved first—both because they are the easiest and because they build experience for the difficult ones.
The requirements matter more than the platform
How long can each system be down? What times of day are impossible? Are there legal requirements for where data may be stored? Who signs off that a system is considered migrated?
A requirements specification that answers those questions makes it possible to plan the migration instead of improvising. Without it, every partial move becomes a negotiation.
How to minimize downtime in practice
Run in parallel for a period. The new environment is built and tested while the old one is still in operation, so that the cutover becomes a decision rather than a leap of faith.
Move in waves. One system or group at a time, with a defined rollback plan for each wave.
Synchronize data until the switch. This makes the final step a quick cutover instead of a long transfer.
Decide in advance what triggers a rollback, and who makes that decision.
This is what the timeline usually looks like
Inventory and dependency mapping normally take a few weeks and is the phase that determines whether the rest of the project stays on schedule. This is also where the order of systems is decided.
Next, the target environment is built and a first wave is migrated—ideally something important enough to be significant, but not so critical that a problem would halt operations. The experience gained from that wave is used to adjust the plan for the rest.
Thereafter, the waves follow more closely together, as the pattern is established. The final wave is usually the system with the most dependencies, and it is moved once everything else is already in place.
This is how we work through the migration
Our consultants perform the inventory and dependency map together with you, and develop a plan that holds up in reality. We have done this before in environments where downtime is not an option.
The target environment will be our IaaS platform in our own Swedish data centers, with cloud operations and monitoring included. If parts need to remain on-site, we build a hybrid cloud instead of forcing a full migration.
Frequently asked questions about cloud migration
Does everything have to be moved at once?
No, and that is rarely wise. A phased migration with parallel operations provides both lower risk and the opportunity to learn along the way.
How much does a migration cost?
It is determined by the number of systems and how complex the dependencies are. The inventory is what makes it possible to estimate the cost.
Can we move back if it doesn’t work?
Yes, if you have planned for it. The rollback plan must be in place for each wave before that wave begins.
A move that is planned, not improvised.
We map your systems and dependencies and develop a plan that holds up in reality.