Key Takeaways
- Most migrations are triggered by hardware end-of-life or a lease expiry, which means they arrive with a deadline attached.
- Lift-and-shift is fastest and rarely cheapest to run. Re-platforming costs more up front and less every month afterwards.
- The application dependency map is the artefact that decides whether the migration is uneventful.
- Cloud is not automatically cheaper. It is elastic, which only becomes cheaper if something actually scales things back down.
Why you are probably reading this now
Migrations rarely start as strategy. They start as a deadline: servers reaching end of support, a datacentre contract ending, a hardware refresh quote that prompts somebody to ask whether there is another option, or an acquisition forcing consolidation.
That matters, because a deadline-driven migration has less room for the discovery phase that determines whether it goes well. The single best thing you can do is start the dependency mapping before the deadline forces the decision. If you need to migrate from on premise to cloud, starting this work early gives the team more room to identify dependencies and sequence the move.
The four approaches, and what they really cost
When planning an on premise to cloud migration, the approach should be selected according to the workload rather than applied uniformly across the estate. For organizations evaluating cloud infrastructure and managed cloud environments, managed hosting and cloud services can also be considered as part of the broader migration strategy.
| Approach | What it means | Trade-off |
|---|---|---|
| Lift and shift | Move the workload as-is onto cloud infrastructure | Fastest and lowest project risk. Usually the most expensive to run, because you inherit on-premise sizing |
| Re-platform | Move it, then adapt it to managed services such as a managed database | More work up front, materially lower run cost, fewer things for you to patch |
| Re-architect | Rebuild the application for cloud-native patterns | Highest cost and highest ceiling. Rarely justified for a line-of-business application that works |
| Retire or replace | Decommission it, or move to SaaS | Frequently the best answer and consistently the least considered |
In practice most estates are a mix. The mistake is choosing one approach for everything, usually lift-and-shift because it is fastest, then being surprised by the monthly bill.
Definition Callout: Cloud sprawl. Where a lift-and-shift inherits on-premise sizing, so machines provisioned for a peak that happens twice a year run at that size continuously and are billed by the hour.
What actually goes wrong
- An undocumented dependency. Something depends on a server nobody mapped, and it surfaces at cutover.
- Licensing that does not transfer, discovered after the move rather than before.
- Latency between a migrated application and data left on-premise.
- Backups reconfigured for the new environment but never restore-tested.
- Identity and access reworked hurriedly, leaving permissions broader than before.
- Nothing scaling back down, so the bill only ever rises.
The common thread is discovery. Many of these issues can be identified or reduced through thorough dependency mapping and inventory before migration begins, and almost none is preventable once cutover has begun.
A sequence that works
The right cloud migration steps depend on the estate, but a structured sequence helps reduce avoidable problems.
- Inventory everything, including what you believe is decommissioned. Assessment output should flag end-of-life operating systems, unsupported versions and outdated firmware, because those decide what can move as-is.
- Map dependencies, application by application, including scheduled jobs and integrations. This is the step that gets compressed and should not be.
- Decide the approach per workload, not per estate. Retire what nobody uses first, because it is the cheapest win available.
- Design identity and access before moving anything, because retrofitting it is painful and usually leaves permissions too broad.
- Migrate in waves, lowest risk first, so the team learns on something that does not matter.
- Run parallel where you can, then cut over with a tested rollback and a defined abort point.
- Right-size after a month of real usage data, not on migration day. This is where the run cost is actually decided.
- Restore-test in the new environment. A backup configuration that worked on-premise is not evidence of anything in the cloud.
This process also provides a practical framework for server to cloud migration, particularly during the inventory and dependency-mapping stages.
Is cloud actually cheaper?
Sometimes, and not automatically. Cloud converts capital expenditure into operating expenditure and makes capacity elastic. Elastic only becomes cheaper if something is actively scaling it back down when demand falls, and that is exactly what does not happen by default.
The workloads that genuinely save money are variable ones. A steady workload running the same size continuously often costs more in cloud than on hardware you already own, and there is no shame in leaving it where it is.
Security posture is a separate question from cost and worth planning deliberately. CISA’s Cybersecurity Performance Goals provide a voluntary baseline of high-priority cybersecurity practices, while eligible organizations can use CISA’s no-cost Cyber Hygiene Services, including vulnerability scanning, to assess internet-accessible assets after the move.
Client Case
Client environment: A global energy group. Outcome: Improved consistency across multiple countries through asset discovery, patch management and remote software deployment. Relevant because discovery, not the move itself, is what makes a large estate manageable.
Frequently Asked Questions
1. How long does a migration take?
It is driven by estate complexity and dependency mapping quality rather than by data volume, which is what most people assume. A handful of straightforward workloads is a very different project from an estate with undocumented interdependencies, even at similar size.
2. Will we have downtime?
Planned downtime, usually. Unplanned downtime is what good sequencing prevents: waves rather than a single cutover, parallel running where the architecture allows, and a tested rollback with a defined abort point.
3. Should we move everything?
No, and treating that as the goal is a common and expensive error. Some workloads are cheaper and simpler where they are. Retiring unused systems is frequently the highest-value part of the whole exercise.
4. What about our old hardware?
Decommissioning should be planned rather than assumed, including secure data destruction. This gets forgotten routinely and it is the one step with a compliance consequence attached.
