14. Real-World Migration Journeys

No two migrations are the same. But the patterns, pain points, and turning points often are. In this section, we share two real-world AWS migration journeys that highlight how strategic migrations solve more than just infrastructure issues.

These aren’t sanitized case studies — they’re stories of real constraints, imperfect setups, executive pressure, and the messy-but-meaningful work of making things better.

A mid-sized e-commerce company was collapsing under its own growth. Every time a marketing campaign was launched, the platform would buckle. Customers disappeared at the worst time: peak buying moments. Meanwhile, ad budgets burned in the background.

The infrastructure was modern-ish, but brittle. Applications ran on VMs with manual Kubernetes deploys. There was no formal infra team, just a CTO trying to keep it all glued together. Developers didn’t touch the stack — they relied on a black box maintained by an external vendor. The system had observability in name only: some logs, a few Datadog agents, no usable dashboards.

The company wasn’t unprepared. They had a load balancer and CDN. But the app itself couldn’t handle bursts. The monolithic database couldn’t scale. Marketing and engineering were in silent conflict. Migration became a necessity.

Before anything moved, the team had to observe. Real observability had to be built from scratch — only then could they simulate the spikes that were causing problems. Load testing took time to get right, because even testing required a scalable environment.

• Application services were containerized

• Configurations were externalized and secrets pulled from AWS-native tools

• Aurora MySQL was set up to replicate from the old on-prem database to avoid downtime

• Environments were split into dev and prod with two sub-environments each

• Deployment tooling was replaced: Jenkins out, GitLab CI in

Within three months, the company moved to full autoscaling. Availability rose to 99.95%. Costs initially spiked to $60K/month, then were optimized down to $35K/month — with better performance.

On-call responsibilities shifted from the CTO to a real ops team. Teams started owning observability for their services. Developers had access to logs, traces, and metrics. For the first time, the people building the product could see it run.

And the culture shifted too. Deployment became routine. Marketing teams no longer feared Friday. The infrastructure no longer had to be explained every week — it worked. The migration didn’t just scale the system, it stabilized the business.

In the energy sector, one company had a different kind of fragility: their data platform.

It was critical. It was used for analytics and regulatory reporting. And it was fragile.

Everything was built around shell scripts and cronjobs, strung together by a small team. No dashboards. No monitoring. No alerts. Just a set of unwritten expectations that things would run — until they didn’t.

Only two people truly understood how the platform worked. They weren’t always available. Sometimes fixes took hours. Other times they didn’t come.

Migration here wasn’t just a lift-and-shift. It was about removing mystery.

• Build observability and make things visible

• Replace shell logic with orchestrated pipelines

• Reduce cost without sacrificing redundancy

• Eliminate risk of platform lock-in to specific people

Terraform and reusable AWS modules standardized the stack. Prefect replaced cron. Spot instances and simplified environments reduced waste. Redundancy wasn’t achieved by duplication, but by design: failover by region, not instance.

Knowledge moved from shell scripts into version-controlled pipelines. The entire system became visible, inspectable, and ownable. There were still things to fix. But now the team could fix them.

• Developers could deploy without stress

• Systems scaled as needed without manual effort

• Costs became predictable and manageable

• Teams understood what they ran

• Incidents became rare and resolvable

Most importantly: migration stopped being discussed. The teams moved on. The platform became infrastructure again, not an existential risk.

That’s how you know a migration worked.