Every few years a business is told, usually by a vendor, that it needs to "move to the cloud." It's presented as a single decision with an obvious answer. It's neither.

For engineering and enterprise teams especially — where systems are specialised, data is heavy, and downtime is expensive — the cloud is not a destination. It's a series of decisions, made system by system. A good cloud strategy is mostly about knowing which decision applies where.

At DZDSoft we do cloud-native development and consulting, which means we're paid to say "don't move that" as often as "move this." Here's how we think about it.

The cloud is not one decision

"Migrating to the cloud" hides at least three very different choices, each with a different cost and payoff.

The mistake most teams make is applying one of these to everything. Lift-and-shift the whole estate and you've moved your problems to a more expensive address. Rebuild everything and you'll spend two years re-writing software that worked fine. A real cloud strategy assigns the right approach to each system.

What to move, what to keep

Not everything belongs in the cloud, and saying so isn't nostalgia — it's engineering.

Good candidates to move:

• Systems with variable or spiky load that waste money on always-on hardware.
• Anything needing geographic reach or fast scaling.
• Workloads where managed services (databases, storage, queues) remove real operational cost.

Often better kept on-premise or hybrid:

• Systems bound by data residency rules — where KVKK, GDPR or contracts dictate where data physically lives.
• Steady, predictable workloads where owned hardware is simply cheaper.
• Deep integrations with legacy equipment that isn't going anywhere soon.

The hidden costs nobody budgets

The headline cloud price is rarely the real one. The bills that surprise teams come from the parts the sales deck skips:

• Egress fees — moving data out is where clouds quietly charge the most.
• Over-provisioning — lift-and-shift usually carries the same oversized servers, now rented monthly.
• Vendor lock-in — the more managed services you adopt, the harder and costlier it is to leave.

This is why cost discipline (what some call FinOps) belongs in the strategy from day one, not as a cleanup exercise after the first alarming invoice. Infrastructure as code — Terraform and similar — matters here too: infrastructure you can read, version and rebuild is infrastructure you can actually control the cost of.

When rebuilding cloud-native pays

Rebuilding is the most expensive option and the most powerful. It's justified when a system is core to the business and its current architecture is the ceiling on growth or cost.

Cloud-native — containers, orchestration, managed data services, autoscaling — earns its rebuild cost when: load genuinely varies, the team needs to ship changes often and safely, or the current cost curve gets worse as you grow. Outside those cases, a rebuild is usually an expensive way to reach the same place.

Do you need a cloud strategy, or just a migration?

If a vendor is quoting you a migration, ask first whether you have the strategy that migration should serve. You probably need the strategy when:

How we approach it

We start by refusing to treat the cloud as a single yes/no. Our work is per-system: which to lift-and-shift, which to re-platform, which to rebuild, and — importantly — which to leave exactly where it is. Then we build the parts that should be built, with infrastructure as code so the result is controllable, not a black box.

The same discipline runs through it as our other work: the engineers who advise on your cloud strategy are the ones who'd build the migration, so the advice is shaped by what it actually takes to ship — not by what sounds good on a slide.