Migrating a live SaaS from Linode to AWS — without stopping school
Every weekday morning, 210+ institutions log in expecting attendance, fee vouchers and gradebooks to just work. This is the story of moving the entire platform underneath them.
When we started the school platform, Linode was the obvious choice: simple, cheap, predictable. For an early-stage product it was exactly right. But by the time we crossed a hundred institutions, the cracks were structural, not cosmetic — vertical scaling ceilings, manual failover, and an infrastructure that couldn't keep up with a product that had outgrown its first home.
The hardest part of a migration isn't the technology. It's that the business cannot pause while you do it.
Why we moved
Schools are an unforgiving customer segment in the best way: their day starts at 7:30 AM sharp, and the platform must be ready. Our reasons for AWS came down to three things:
- Elasticity — school traffic is spiky (morning attendance, result days, fee deadlines). Fixed-size servers meant paying for the peak all month.
- Managed services — RDS, S3, and load balancing replaced a growing pile of hand-maintained infrastructure scripts.
- A platform for microservices — we were re-architecting the monolith anyway; it made no sense to build the new architecture on the old foundation.
The migration plan
We treated it like a school exam schedule: everything mapped, dated, and rehearsed. The playbook, roughly:
- Inventory everything. Every cron job, every environment variable, every "temporary" script someone wrote two years ago. The undocumented pieces are what take you down.
- Move state last. Stateless services went first behind a load balancer. Databases moved in the final window, with replication running from Linode to RDS for days before cutover.
- Rehearse the cutover. We did full dry-runs against staging until the checklist had no surprises left in it.
- Cut over on a school holiday. Know your customers' calendar better than they do. Our lowest-traffic windows were school breaks — that's when DNS flipped.
What I'd do differently
Two honest lessons. First, we underestimated egress and data-transfer costs in the first month — model your bill before the migration, not after. Second, we should have built the CI/CD pipelines before the migration rather than alongside it. Deploying to new infrastructure with old deployment habits doubles your risk surface.
The payoff was worth every rehearsal: faster page loads for every school, infrastructure that scales with result-day spikes instead of falling over, and an engineering team that ships to production without holding its breath.