Engagements - Migrate to the Next.js App Router, route by route, no code freeze
Your App Router migration is either half-done and scary or hasn't started because nobody has weeks to freeze the roadmap for it. Meanwhile the hydration errors pile up, the caching model bites you, and the Pages Router code rots. A build takes the whole migration off your team's plate and does it the safe way — route by route, both routers running side by side, nothing frozen — by someone who lives in Server Components.
- Product teams
- Agencies
- Scaling startups
What you'll have at launch
Your app on the App Router — Server Components, correct caching, green Core Web Vitals — migrated incrementally with nothing frozen.
- Your app running on the App Router, with Pages and App Router coexisting cleanly during the transition and no big-bang cutover.
- The rendering strategy right per route: SSR for dashboards, SSG for marketing, ISR for content, instead of everything client-side.
- Hydration mismatches and caching bugs fixed, not papered over — the ones that stall most migrations.
- Core Web Vitals moved into the green as a side effect of doing the migration properly.
How we build it
A build runs 4–8 weeks typical, shipped week by week in increments you review and merge.
Weeks 1–2 · Map & de-risk
We audit the app, get Pages and App Router running side by side, and migrate a couple of low-risk routes end to end to prove the pattern — layouts, data fetching, caching tags. You come out of week two with a repeatable playbook and zero routes frozen.
Weeks 3–6 · Route by route
The real routes get migrated in priority order, shipping in weekly PRs you review and merge. Each one moves data fetching to the server, fixes its hydration and caching, and lands independently — so value ships continuously and you can pause the moment priorities change.
Weeks 7–8 · Cutover & cleanup
The last routes move over, the Pages Router scaffolding comes out, and we do a caching and Core Web Vitals pass across the app. You're left on a clean App Router codebase with the migration cruft gone, not a half-and-half app you're afraid to touch.
What's included
- Incremental migration with Pages and App Router side by side, so the app keeps shipping and nothing freezes for the duration.
- Per-route rendering decisions — SSR, SSG, ISR with on-demand revalidation — instead of the everything-client-side default.
- Server Components, server actions, and route handlers wired properly, with the data layer moved off the client.
- Hydration mismatches killed and the caching/revalidation model made correct, including the tags that quietly break these migrations.
- A Core Web Vitals pass: bundle trimming, LCP/CLS/INP fixes, and Lighthouse back in the green on the routes that rank.
- Clean PRs matched to your conventions, reviewed and merged by your team — no black-box rewrite dropped on you.
Stack
- Next.js
- React
- TypeScript
- Vercel
How it runs on the subscription
A migration is weeks of careful, incremental work — the exact opposite of a task — so it runs as a build: the board dedicated to moving your app across, shipping migrated routes every week. Same flat monthly subscription, from $6,900/month, most migrations landing in four to eight weeks. Because it's incremental you can pause between batches and reprioritize which routes go first whenever the roadmap demands it.
Frequently asked questions
- Do you have to freeze our app during the migration?
- No — that's the whole point of doing it route by route. Pages and App Router run side by side, and each route migrates independently, so your team keeps shipping features the entire time. There's no multi-week freeze and no single terrifying cutover day.
- Our migration is already half-finished and broken. Can you take it over?
- Yes, that's common. We start by auditing what's done, stabilising the routes that are already moved, and re-establishing a clean pattern, then continue route by route from there. Inheriting a messy half-migration is a normal starting point, not a problem.
- Will this fix our hydration and caching bugs?
- Those usually get fixed as part of migrating each route properly — moving data fetching to the server, setting revalidation tags correctly, and eliminating the client/server mismatches that cause hydration errors. The caching model is exactly where most self-done migrations go wrong, so it gets deliberate attention.
- How long does an App Router migration take?
- Most take four to eight weeks, depending on how many routes there are and how much each one leans on client-side data fetching and old caching assumptions. Because it's incremental, you see migrated routes landing every week rather than waiting for one big finish.
- Who reviews the changes?
- Your team does. Everything ships as PRs into your repo, matched to your conventions, and your engineers review and merge each one. Nothing is dropped on you as an opaque rewrite — you watch the migration happen route by route.
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.