When executives say, “We’re moving to the cloud,” engineers hear something very different: years of unwinding legacy systems, unknown dependencies, and Friday‑night cutovers. I’ve lived through that journey more than once as a software engineer, and each time I’ve learned that a successful cloud migration is much more about strategy and sequencing than tools or services.
I’m Phong Lee, and this is the playbook I wish we’d had the first time we tried to move a monolithic, on‑prem stack into a modern cloud environment.
Why enterprises really move to the cloud
The slide-deck reasons are familiar:
- Lower infrastructure costs
- Better scalability and reliability
- Faster experimentation and innovation
But on the ground, I’ve seen three deeper motivations:
- Escaping operational pain: hardware failures, manual deployments, fragile environments.
- Modernizing the architecture: breaking monoliths into services, APIs, and event-driven systems.
- Unlocking data and AI: centralizing data so analytics and ML become realistic, not aspirational.
A cloud migration strategy that ignores these real motivations usually degenerates into “lift-and-shift and hope.”
Mistake #1: Treating migration as a one-time project
In one enterprise, leadership set an ambitious target: “100% in the cloud by the end of the year.” It sounded decisive—but it pushed teams to prioritize speed over design.
We ended up with:
- VMs in the cloud running the same clunky monolith
- Manual deployments just happening on someone else’s servers
- No clear ownership of cost, performance, or reliability
Technically, we were “in the cloud.” Practically, nothing important had changed.
What finally worked was reframing migration as a multi-year transformation, with clear phases:
- Phase 1: Assess and map – inventory systems, dependencies, and data flows.
- Phase 2: Stabilize and standardize – CI/CD, logging, monitoring, environments.
- Phase 3: Migrate and modernize – move workloads with intentional redesign.
- Phase 4: Optimize and innovate – refactor for cloud-native patterns, cost, and performance.
Cloud migration is not a destination; it’s a continuous operating model.
Step 1: Start with a brutally honest assessment
When I help plan a migration, my first question is not “AWS, Azure, or GCP?” It’s:
“What do we actually run today, and who depends on it?”
You need:
- A list of applications and services
- Their upstream and downstream dependencies
- Data stores and their consumers
- Release cycles and critical business dates
One trick that has saved me countless headaches: generate dependency maps from actual traffic logs, not just documentation. The docs always miss that one integration someone hacked together three years ago.
Step 2: Pick the right migration pattern per system
Not every system deserves the same treatment. For each workload, I usually consider:
- Rehost (lift-and-shift) – fastest, minimal changes. Good for low-risk, time-sensitive moves.
- Replatform – small changes to leverage managed services (databases, queues, storage).
- Refactor / re-architect – bigger redesign to follow cloud-native patterns.
- Retire – some systems simply don’t need to exist anymore.
- Retain – a few might stay on‑prem for regulatory or latency reasons.
On one project, we tried to refactor everything at once. It nearly broke the team. The winning strategy came when we:
- Lifted and stabilized the highest-risk systems first.
- Gradually introduced managed services to offload undifferentiated heavy lifting.
- Refactored only where we had clear ROI: performance, scalability, or developer experience.
Step 3: Design for observability from day one
Moving to the cloud without observability is like flying a plane with the windows painted black.
We made it a rule: every migrated service must have:
- Centralized logging
- Metrics and dashboards for latency, errors, throughput
- Alerts tied to business SLAs, not just CPU thresholds
During one cutover, an obscure background job started hammering a database with inefficient queries. Because we had tracing and metrics in place, we spotted it within minutes instead of waiting for users to complain Monday morning.
In the cloud, you don’t just deploy code—you deploy insight into that code.
Step 4: Plan cutovers as products, not events
The scariest part of cloud migration is the moment you switch real traffic from old to new. I’ve learned to treat cutovers like mini‑products:
- Define success metrics (latency, error rate, conversion, throughput).
- Use gradual traffic shifting (canary releases, blue‑green deployments).
- Prepare rollback plans that are realistic and tested.
- Communicate clearly with business stakeholders about timelines and risks.
In one migration, we shifted 5% of traffic to the new environment, watched metrics, then incrementally ramped up. When a hidden edge case appeared at 20% traffic, we rolled back quickly, fixed the issue, and tried again. No all‑nighters, no war rooms, no panicked emails.
Step 5: Control cost before it controls you
Cloud bills have a way of surprising teams who are new to pay‑as‑you‑go infrastructure. I’ve seen costs spike because:
- Non‑production environments were never turned off
- Overprovisioned instances and databases were left running “just in case”
- Logging and monitoring were left at maximum verbosity
To keep things sane, we:
- Set budgets and alerts per environment and team
- Tagged resources by owner, environment, and application
- Reviewed cost reports during regular engineering check‑ins
Optimizing cloud cost is not just about saving money—it’s about designing systems that are efficient, observable, and maintainable.
Cloud migration from an engineer’s perspective
As an engineer, the most fulfilling migrations I’ve been part of share the same traits:
- Clear business goals beyond “be in the cloud”
- Realistic timelines and phasing
- Strong collaboration between infra, app teams, and business owners
- A culture that treats setbacks as learning, not blame
I, Phong Lee, now think of cloud migration less as a technical project and more as an organizational upgrade. The cloud is just the infrastructure layer; the real transformation is how your teams build, deploy, observe, and improve software.
If you treat your cloud migration strategy as a long‑term journey—with honest assessment, smart prioritization, observability, and cost discipline—you’ll end up with more than new servers. You’ll have a platform where your engineers can move faster, your products can scale further, and your business can respond to change with confidence.