7. Migration Strategy — Lift, Shift or Rearchitect?

Let’s be honest: you don’t migrate just to run the same thing somewhere else. If the only outcome is that your app runs in EC2 instead of on-prem, then you haven’t actually gained anything.

That’s why our default migration strategy is almost never a pure lift-and-shift. Instead, we lean toward replatforming — moving workloads to containers, using managed services, building pipelines, and setting the stage for autoscaling and self-healing systems. It's about building a better version of what you already have, not rewriting it entirely.

• Lift-and-shift: Move workloads as-is to EC2 or VMs

• Replatform: Update the infrastructure layer (e.g. containerize, move to EKS or RDS) but leave app logic mostly unchanged

• Refactor: Rewrite or restructure the application to take full advantage of cloud-native services

In our experience, replatforming is the most effective entry point. It balances progress with risk and avoids unnecessary complexity. We rarely recommend full lift-and-shift unless there’s a hard deadline (like a datacenter shutdown) or the application is completely opaque (e.g., closed-source, abandoned vendor software).

The problem with lift-and-shift is that it changes very little. If your application couldn't autoscale before, moving it to EC2 won't magically make it elastic. If you had fragile deployment scripts or hard-coded IPs, they follow you into the cloud.

There’s always a reason for the migration. And that reason is almost never "we want to pay more for the same thing in AWS."

• 🐳 Containerize the workloads

• ⚙ Move from custom VMs to EKS

• 📦 Replace hand-managed DBs with RDS or Aurora

• 🧰 Introduce proper monitoring and logging

• 🔐 Improve IAM, network security, and access control

• 🚀 CI/CD pipelines with rollback and testing

• 🔁 Autoscaling policies and resource limits

• 🔄 Break monoliths into autoscalable pieces

• ⏱ Remove fragile cronjobs with scheduled Lambda or EventBridge

• 🧪 Move toward service boundaries that reflect real product domains

Security and disaster recovery also improve as side effects. With centralized logging, IAM boundaries, and cross-region backup strategies, most teams end up safer by default.

Our position is simple: everything gets modernized eventually. The only question is what order makes sense for your team. We treat replatforming as a universal first step and phase in more changes as needed.

We don’t ask "Should we move this?" We ask "When should we move it, and how big should this step be?"

You don’t need a long matrix to decide which services get replatformed vs. refactored. If you build a standardized migration pipeline, everything eventually goes through it. Teams don’t have to guess or debate each case.

• Are easy to isolate

• Have real pain (e.g. downtime, ops load)

• Have clear ownership post-migration

Avoid starting with core stateful systems (like shared DBs) unless there's a strong reason. Complexity compounds fast.

• Try to refactor everything at once (months of planning, no value delivered)

• Start with the hardest part (monolith DBs, legacy auth systems)

• Keep fallback infra running too long (you pay double and slow adoption)

• Get stuck debating approaches instead of building them

• Overbuild CI/CD and infra tooling before moving a single workload

Pick a service, move it, own it. Learn. Repeat.

The right strategy isn’t about picking a label — it’s about building momentum. Every service you replatform is a step toward a system that scales, heals, and supports your team instead of dragging them down.