Engagements - Rebuild a crumbling legacy app with a staged, tested cutover
The legacy app still runs the business, but every change is terrifying, the original dev is long gone, and the framework's been out of support for years. You can't freeze it and you can't keep patching it. A rebuild does it the safe way: the new system gets built and proven feature by feature while the old one keeps running, and traffic moves over in stages — no big-bang rewrite, no weekend where everything's supposed to just work.
- Teams stuck on legacy
- Post-acquisition cleanups
- Agencies
What you'll have at launch
A modern app on a maintainable stack, cut over in stages — the old system live until the new one is proven, no big-bang rewrite.
- A modern app on Next.js and PostgreSQL replacing the unmaintainable stack, feature-for-feature where it counts.
- A staged cutover: the old system stays live as a fallback until each slice of the new one is proven in production.
- The data migrated and reconciled, so nothing's lost and the numbers still add up after the move.
- A codebase your team can actually change without holding its breath.
How we build it
A build runs 8–12 weeks typical, shipped week by week in increments you review and merge.
Weeks 1–3 · Map & strangle
We map what the legacy app actually does (not what the docs claim), stand up the new stack, and put a routing layer in front so new and old can run side by side. The first slice gets rebuilt and shadowed against the old system to prove parity before anything real moves.
Weeks 4–9 · Rebuild feature by feature
Features get rebuilt and cut over in priority order, shipping weekly. Each slice runs against real traffic with the old system still available as a fallback, and the data migration is validated as we go — so risk stays contained to one feature at a time, never the whole app at once.
Weeks 10–12 · Final cutover & decommission
The last features move, the data migration is reconciled end to end, and once the new system's proven we retire the legacy app. You end on a modern, tested codebase with the old one gone — not two systems you now have to maintain.
What's included
- A strangler-fig migration: a routing layer so the new app and legacy system run side by side, with traffic moved feature by feature.
- A rebuild on Next.js and PostgreSQL (or the right modern stack for your case), matched to how the business actually uses the app.
- Data migration with validation and reconciliation, so records move cleanly and the numbers still tie out afterward.
- Parity checks: new features shadowed against the old system before cutover, so you're not discovering gaps in production.
- A staged rollout with the old system as a live fallback, so no single change can take the whole business down.
- Deploy, backups, and a documented handover, so the modern app is genuinely yours to run and change.
Stack
- Next.js
- PostgreSQL
- Docker
- VPS
How it runs on the subscription
A rebuild is the definition of month+ work — staged, validated, feature by feature — so it runs as a build: the board dedicated to modernizing your app, cutting over a slice every week. Same flat monthly subscription, from $6,900/month, most rebuilds landing in eight to twelve weeks. Because it's staged you reprioritize which feature moves next and pause between slices, with the old system live the whole time as your safety net.
Frequently asked questions
- Do we have to freeze or shut down the old app during the rebuild?
- No. The rebuild uses a staged, strangler-fig approach: the legacy system keeps running and serving real users while the new one is built and proven feature by feature. Traffic moves over in slices, with the old system as a live fallback, so there's never a freeze or a big-bang switchover.
- How do you avoid a risky big-bang rewrite?
- By never doing one. Each feature is rebuilt, shadowed against the old system to check parity, and cut over on its own — so risk is always contained to a single slice, not the whole app. If a slice isn't right, the old path is still there to fall back to while we fix it.
- What happens to our existing data?
- It's migrated with validation and reconciliation as part of the build. We move records into the new schema, check them against the old system, and make sure the totals tie out before a feature depends on them — so the migration is proven, not hoped.
- The original developer is gone and there are no docs. Is that a problem?
- That's the normal starting point for a legacy rebuild. Part of the early work is mapping what the app actually does by reading the code and watching real behaviour, rather than trusting missing or stale docs. A senior engineer inheriting an undocumented system is exactly what this build is for.
- How long does a legacy rebuild take?
- Most take eight to twelve weeks, depending on how much the app does and how tangled the data is. It runs on the flat monthly subscription — from $6,900/month — so you pay for the active weeks rather than a fixed total, can pause between slices, and keep the old system running the entire time.
Got a project? Let's ship it.
3 spots open. Subscribe today, hand off the first outcome, and we'll ship it in weekly increments. Smaller tasks still usually land in 48 to 72 hours. No call required.