AWS Cloud Migration: The Honest Founder's Guide (2026)

The Client Who Wanted to Migrate to AWS Before They Had 50 Users

It was 2023. I was brought onto a project — not mine, a client’s, the kind where I show up, look at the codebase, and try to stop people from setting money on fire. They had a Next.js app running on a $12/month VPS, a Postgres database on the same box, and eleven paying customers. Eleven. Real ones, real cards, real MRR.

The founder had just come back from a conference. Someone on a panel had said the word “scalable” four times in ten minutes, and now there was a Notion doc titled “AWS Migration — Q3” with a diagram that had EC2, an Application Load Balancer, auto-scaling groups, and a Multi-AZ RDS instance. For eleven customers. I asked him, gently, what problem this solved. He said “scale.” I asked what was actually breaking today. He said nothing was breaking today.

That’s the story I want to tell you before I teach you the tools, because I’m going to teach them properly — the six ways AWS categorizes a migration, the actual services you’d use, the real timeline and cost — and then I’m going to circle back to that Notion doc, because most of you reading this are that founder, and most of you don’t need any of it yet.

---

The Six Ways to Move Anything to AWS

AWS has a whole framework for this, and it’s genuinely useful once you strip the enterprise-consultant varnish off it. It’s called the “6 R’s,” and every migration — yours, a Fortune 500’s, a client’s legacy Rails app — fits into one of these buckets.

Strategy	What it means	When it makes sense
Rehost	Lift-and-shift. Move the app as-is onto EC2, no code changes	Fastest, lowest risk, the default if you must move
Replatform	Small swaps for managed services — your Postgres becomes RDS, your app server stays the same	You want a few operational wins without a rewrite
Repurchase	Drop the custom app entirely, buy a SaaS that does the same job	Your “app” was reinventing something that already exists
Refactor	Rebuild to actually use cloud-native patterns — Lambda, managed queues, the works	You genuinely need the elasticity and you have the budget
Retire	Turn it off. Nobody uses it	More common than people admit once someone actually audits
Retain	Leave it exactly where it is	Also a valid strategy, and the one nobody puts on a slide

Notice that two of the six options are “don’t move it” and “turn it off.” AWS’s own migration guidance tells enterprises a typical portfolio splits across all six — rehost the boring stuff, retire the dead stuff, refactor only the handful of apps that are the actual competitive edge. Most solo founders skip straight to “refactor” in their head because it sounds impressive, when the honest answer for almost everything they own is retain, or retire.

For a small SaaS, rehost and replatform cover 95% of real cases. Rehost means your app runs on an EC2 box instead of your VPS — same code, new landlord. Replatform usually means your database specifically moves to RDS so AWS handles the backups and patching. Refactor — actually rewriting your app to be cloud-native — is a multi-month engineering project in its own right, and it’s the one people reach for when they haven’t actually asked whether they need it.

---

The Tools AWS Gives You (And What They Actually Do)

If you do decide to move, AWS has three tools worth knowing, and they solve three different problems.

AWS Migration Hub is a dashboard, not a mover. It’s free to use — you only pay for whatever it’s tracking underneath — and its job is to give you one screen showing the status of servers and databases mid-migration, instead of five different tool consoles. Useful if you’re coordinating dozens of things moving at once. Pretty pointless if you’re moving one app and one database, because you don’t need a dashboard to watch a single spinner.

AWS Database Migration Service (DMS) is the one tool in this list I’ll actually compliment without a “but.” It replicates your database into RDS or Aurora while your old database keeps running and taking live writes, then does a final cutover with minimal downtime. Pricing is fair for a small job — an on-demand replication instance runs from around two cents an hour for a small box up into a few dollars an hour for something beefier, plus storage around $0.11–$0.23 per GB-month, so migrating a modest Postgres database usually stays a small line item next to the bigger question of whether you should. If you’re already committed to moving a database into AWS, DMS is the correct way to do it — it beats a risky pg_dump/pg_restore cutover for anything you can’t afford downtime on. (If “migration” made you think of the other kind — schema versioning, not moving providers — that’s a completely different post.)

AWS Application Migration Service (MGN), now folded into the broader AWS Transform branding, is for moving whole servers — it installs an agent on your source machine, continuously replicates it, and lets you cut over to an EC2 instance whenever you’re ready. It’s free for 90 days per server, then roughly $0.042/hour after that — call it $30/server/month if you let it linger. AWS Transform itself is the newer, splashier layer on top: an “agentic AI” service AWS launched to help enterprises modernize mainframes and VMware fleets faster. It’s aimed at companies with a “portfolio” of applications, a phrase that should never describe a solo founder’s stack.

None of these three tools do the hard part for you. They move bytes. The hard part — deciding whether your app’s assumptions still hold on new infrastructure, testing that nothing silently broke, cutting over without losing a write — is still entirely on you, whichever tool you pick.

---

What a Real Migration Actually Costs and Takes

Here’s where the marketing glosses over the truth, so let me give you numbers instead of vibes.

For a small operation — think 10 to 30 people, a handful of servers, a database, some file storage — outside estimates for a full migration project land somewhere between $3,000 and $40,000, with the lower end covering something simple like moving email and file storage, and the higher end covering multiple applications with a real re-hosting effort. Timelines for that size of job usually run two to six weeks of calendar time if it’s clean, stretching to a couple of months if there’s real complexity — legacy dependencies, custom integrations, data that doesn’t want to move.

If you bring in AWS’s own consultants instead of doing it yourself, expect $300+ an hour for AWS Professional Services, or $100–$250/hour through an AWS partner — meaning even a modest three-month engagement can run six figures before you’ve paid a cent for the AWS resources themselves. Not a scare number I invented; that’s what migration agencies quote in public, because “we’ll move your infrastructure” is an expensive service to buy, not just an expensive one to run.

And that’s the part that never makes it into the AWS keynote: the migration is a project, with a project’s budget and a project’s timeline, separate from whatever you pay AWS every month afterward. You’re not paying to “be on AWS.” You’re paying an engineer or a firm to carefully move something that currently works into a different place where it also has to keep working, under load, with real customer data, with a rollback plan in case it doesn’t.

---

The Broken-Engineer Take: You’re Migrating a Problem You Don’t Have

Now back to that Notion doc. Here’s what actually happened with that client: I asked him to write down, specifically, what would break at 50 users, at 200 users, at 1,000 users, on the $12 VPS he already had. He couldn’t answer past 50. Nothing was going to break. His actual bottleneck was that four of his eleven customers had asked for a feature he hadn’t built yet, and he’d spent the previous two weeks reading about auto-scaling groups instead of building it.

I see this constantly, and it’s always the same shape: an engineer-founder, above-average at the craft, uses “scalability” as a socially acceptable excuse to avoid the scarier work of talking to customers and shipping features. Migrating to AWS feels like progress. It has diagrams. It has a Q3 label. It is, for almost every solo founder I’ve met, a very expensive way to procrastinate.

Here’s the math that actually matters. Say the migration itself — your time, or an agency’s — costs $8,000 and three weeks, conservatively, for even a modest app. What did you get for that $8,000? Not more customers. Not a faster product. The same app, running on infrastructure that costs more per month and needs more of your attention, in exchange for a scalability ceiling you were nowhere near hitting. I made this exact mistake in a different costume with Kubernetes — orchestrating a cluster for a product with zero users — and the disease is identical here. (Same story, different tool, in the advanced database guide.)

Compare that to the alternative: stay on the VPS, or move to a PaaS built for someone your size — Vercel for the frontend, Railway or Koyeb for a backend that runs 24/7 on a flat fee, Neon for Postgres with branching and a real free tier. That “migration” takes an afternoon, not a quarter, because you’re moving toward simplicity instead of away from it. If you outgrow that setup, you’ll know, because something will actually be on fire — and only then does a real migration project start paying for itself instead of just feeling productive. I ranked where I’d put a growing app in 7 cheap places to deploy your SaaS, and laid out why AWS is the wrong first move — and the wrong security posture for a team of one — in AWS cloud security for founders. And if a free trial is what’s pulling you toward AWS, read what the free tier actually is in 2026 here before it steers a real infrastructure decision.

To be fair to AWS: none of this is a knock on the platform. DMS is a well-built tool. The 6 R’s framework is solid thinking, borrowed from real enterprises solving a real problem — a hundred-application portfolio, a decommissioned data center, a compliance deadline. That is not your problem. Your problem, at eleven customers, is that four of them are waiting on a feature.

---

The Bottom Line

If you’re reading this because a client, a job, or a board actually needs a migration — the 6 R’s are the right mental model, DMS is the right database tool, and budget real weeks and real dollars, not a weekend and goodwill. Do it properly, because a rushed cutover is how you lose data or an afternoon of uptime.

But if you’re reading this because you, solo, with a small and happy user base, are wondering whether it’s “time” to move to AWS — it almost certainly isn’t. The tell isn’t your growth chart. It’s whether you can name the thing that’s actually breaking today. If you can’t, close the Notion doc and go build the feature your customers are actually waiting on. That’s the migration that pays you back.

This is the Broken Engineer Guide — I over-engineer everything, fail at business, and once watched a man plan a Multi-AZ RDS cluster for eleven customers. Go build the feature instead.