At some point, most growing businesses hit the same wall: the server infrastructure that worked fine at ten employees starts causing problems at fifty. Downtime during traffic spikes. Backup processes that no one really trusts. IT costs that scale badly. Security posture that relies more on hope than policy.
The answer is almost always some form of cloud migration — moving workloads from on-premise hardware to managed cloud infrastructure. AWS, Google Cloud, and Azure are the most common destinations. But the process itself is where most migrations go wrong.
Here’s a practical framework for thinking about it, based on migrations we’ve executed for businesses across Bali and Southeast Asia.
Start with the inventory, not the destination
The first mistake most organizations make is picking a cloud provider before they understand what they’re migrating. Cloud platforms have different strengths, and the right choice depends on what you’re actually running.
Before you evaluate any platform, document:
- Every application that runs in your current environment
- What it does, who uses it, and how critical it is
- Its technical dependencies (databases, APIs, file storage)
- Its usage patterns (constant load, batch processing, traffic spikes)
- Its current cost (power, hardware, maintenance, licensing)
This inventory typically takes one to two weeks for a medium-sized organization. It’s the most underestimated part of any migration project — and the one that prevents the most problems later.
The lift-and-shift misconception
“Lift and shift” — moving applications to the cloud without changing them — is appealing because it sounds simple. You’re just running the same thing somewhere else.
The problem is that applications built for on-premise hardware often don’t behave the same way in cloud environments. Networking assumptions change. Storage is accessed differently. Licensing may not transfer. What works when you move it may cost three times more than expected because it wasn’t designed for cloud pricing models.
A better approach for most organizations is lift, shift, and then optimize. Move first to reduce risk and urgency, then refactor the most expensive or problematic components once you’re stable and have real usage data from the cloud environment.
Zero-downtime migrations are possible but require planning
The biggest fear in any migration is downtime — particularly for customer-facing applications. Zero-downtime migrations are achievable, but they require:
- Database replication set up before the cutover, so both environments are in sync
- Traffic routing control — typically via DNS TTL reduction and load balancer rules
- Rollback procedures documented and tested before the migration day
- A maintenance window even if you’re not planning downtime, in case you need one
The worst migrations we’ve seen tried to do everything at once on a tight deadline. The best ones gave themselves two parallel environments running simultaneously for at least two weeks before cutting over.
Security doesn’t get easier by default
Moving to the cloud doesn’t automatically make you more secure. In some ways, a poorly configured cloud environment is more exposed than a well-maintained on-premise server, because the attack surface is larger and public by design.
The non-negotiables before you go live:
- IAM policies with least privilege — every user and service should only have access to exactly what it needs
- Encryption at rest and in transit — most cloud providers make this easy; make sure it’s actually turned on
- VPC configuration — your databases and internal services should not be publicly accessible
- Audit logging — you need to know who accessed what, when
- Automated vulnerability scanning — build this into your CI/CD pipeline from day one
Security is one of those things that’s much easier to implement from the beginning than to retrofit later. Plan for it before you start.
What cloud migration actually costs
Cloud providers quote compute costs. The real costs include:
- Egress fees — data leaving the cloud can be expensive, especially if you have large file transfers or your applications are chatty across regions
- Managed services — RDS, ElastiCache, etc. are convenient but carry a significant premium over running the equivalent yourself
- Engineering time — the actual migration work, plus the ongoing learning curve
- Unexpected licensing — some software licenses don’t transfer to cloud environments
Get a realistic cost model before you commit to a provider or architecture. Run it past an engineer who has actually seen cloud bills at scale.
When to bring in outside help
Some migrations are genuinely simple — a small application, a predictable workload, an experienced internal team. Do those yourself.
The cases where outside help pays for itself:
- Mission-critical applications where downtime has direct revenue impact
- Environments with complex compliance requirements (payments, healthcare, data residency)
- Teams without prior cloud experience who would spend significant time learning as they go
- Situations where the migration needs to happen on a tight timeline
The cost of a well-managed migration engagement is almost always lower than the cost of an incident caused by a poorly managed one.
We’ve run cloud migrations for businesses across Bali and the broader Southeast Asian market — from simple application moves to complex, multi-environment architectures. If you’re thinking about a migration and want an honest assessment of what it would involve, talk to us.