What you will take away
- Lift-and-shift moves the bill without moving the benefit.
- Data egress and cross-zone traffic are the line items that surprise people.
- Migrate in slices with a tested rollback, never as one cutover weekend.
Mistake one: lifting and shifting, then stopping
Rehosting a virtual machine as it stands is a legitimate first step. Treating it as the destination is the expensive mistake. An application designed for a fixed server does not become elastic because it now runs on rented hardware. It runs the same, costs more, and you have added a network hop between it and its database.
The value of cloud comes from the things you can only do there: scaling to demand, managed data services, deployment automation. If the migration plan does not include a second phase that actually uses those, the business case is a rental agreement with extra steps.
Mistake two: no cost model before the first workload moves
On-premise costs are capital and predictable. Cloud costs are operational and continuous, and they respond to engineering decisions made daily by people who have never seen the invoice. Without a cost model and per-team visibility, the bill is discovered in month four by finance rather than managed in week one by engineering.
- Tag every resource by team and environment from the first deployment, not retrospectively.
- Set budget alerts per environment, and make non-production budgets deliberately tight.
- Schedule development and staging environments off outside working hours.
- Review reserved capacity or savings plans once usage has stabilised, not before.
Mistake three: ignoring data gravity and egress
Compute is easy to move. Data is not. A chatty application split across a cloud boundary from its database will pay for every one of those calls in latency and in transfer charges, and both scale with success. We have reviewed architectures where cross-zone traffic between services was a larger line item than the compute running them.
Decide where the data lives first, then place the services that talk to it most around it. Where a hybrid period is unavoidable, treat it as a dated phase with an end, not a permanent topology. The temporary bridges are what become unmaintainable.
Everything that crosses a boundary costs money and milliseconds. Design the boundaries before you design the services.
Mistake four: the big-bang cutover
A single weekend cutover concentrates every risk into the window where you have the least capacity to respond. Migrate in slices instead: one bounded service, one dataset, one customer segment. Run both systems in parallel with traffic split by percentage, and keep the ability to send traffic back for at least a full business cycle.
The rollback plan has to be tested, not documented. An untested rollback is a paragraph in a runbook, and it will be read for the first time at two in the morning by someone who did not write it.
Mistake five: assuming the provider handles security
The provider secures the infrastructure. Everything above it - identity, network rules, storage permissions, encryption keys, patching of what you deployed - is yours. Nearly every cloud data exposure that reaches the press is a misconfigured permission, not a breached hypervisor.
Codify the controls so they cannot drift: infrastructure as code with policy checks in the pipeline, least-privilege roles rather than shared administrative accounts, encryption defaults set at the account level, and an audit that runs on a schedule rather than after an incident.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
