Moving to the cloud, or back, without unnecessary risk
Moving to the cloud, moving back to your own servers, or simply replacing an aging system with something newer - these are all projects where one badly planned night can stop operations for days. I plan and run the migration so nobody's phone rings over the weekend because nothing works.
Where the problem comes from
Companies start a migration for one of two reasons. Either support for an old system is ending and it can no longer be run safely, or the cost of owned infrastructure stops making sense compared to the cloud - or the other way around, a cloud bill grows large enough that moving back to owned servers pays off.
The decision itself isn't usually the problem - the execution is. Migration often gets postponed for years because nobody wants to be the one who brings down the system that production or accounting depends on. The result is a legacy system that keeps the company stuck in place, while the risk of an outage grows with every month support is missing.
Where migrations most often fail
In the ones I've seen fail or drag on far longer than planned, it was almost always one of these:
- No dependency map. Nobody knows exactly what connects to the old system until it breaks during the migration.
- Migrating live with no test run. The first real test happens in production - and by then it's too late.
- No way back. When something goes wrong, there's no planned route back to the original state.
- Underestimating the data. Data transfer and validation take several times longer than expected.
- Treating migration as a purely technical project. Without involving the people who use the system daily, and without training them on the new environment.
The goal of a migration isn't "being in the cloud" or "having a new system." The goal is for the company to run as well as before, or better - and for nobody to lose sleep getting there.
How I approach it
Analysis & dependency mapping
I find out what the system contains, what depends on it, and where the hidden risks are. Without this step, a migration can't be reliably planned.
Plan & test run
I design the target architecture and a phased migration path. Key steps get validated in a test environment first, not directly in production.
Migration with a rollback plan
The actual cutover happens in a planned window, with a clearly defined point of return if anything doesn't go as expected.
Validation & handover
After migration, I confirm everything works as expected and train the team on the new environment - migration doesn't end when the switch is flipped.
What you get
- A migration without unplanned downtime - or with risk reduced to what can be planned for in advance.
- A clear way back if something doesn't go according to plan.
- A system with a future - support, updates, room to keep growing.
- A trained team that understands the new environment and can run it.
When it makes sense
- Support for your current system is ending or has already ended.
- The cost of owned infrastructure - or of the cloud - no longer makes economic sense.
- The system is holding back further development - nothing new can be connected to it.
- You're planning a migration but nobody in the company has run a project like this before.
Frequently asked questions
Does it have to be the cloud? We can't picture giving up our own servers.
The cloud isn't always the right answer. Sometimes the recommendation is to stay on-premise, or to go hybrid. The goal isn't migration for its own sake - it's infrastructure that actually fits what the company needs.
How long does a migration take?
It depends on scope - a simpler system can take weeks, a complex environment with ties to dozens of applications can take months. You'll get an accurate estimate after the initial analysis, not a guess up front.
What happens if something breaks mid-migration?
That's why every plan includes a rollback scenario - a clearly defined point you can return to if something doesn't check out. Migration never starts without a tested path back.
Do we have to migrate everything at once?
No, and I usually recommend against it. A phased migration - grouped by risk and dependencies - limits the impact if something goes wrong, and lets you apply lessons learned to the next phase.
Planning a migration?
Thirty minutes, no strings attached. I'll tell you whether cloud, on-premise, or hybrid makes the most sense for your situation - and what that would mean in practice.
Book a free consultation →