A route-by-route migration path, the boundaries that matter, and the mistake that forces a rewrite.
Executive Summary
- Server Components are adopted route by route; a whole-app migration is what turns an incremental change into a rewrite.
- The client boundary is the design decision. Push it as far down the tree as the interactivity actually requires.
- Data fetching moves up to the server component, which is where most of the bundle savings come from.
Where teams usually start
Most teams arrive at this problem from the same direction: something that worked at one scale stopped working at the next, and the fix that used to be obvious no longer is. This guide walks the path we take with clients, in the order we take it.
The approach
Work in slices that can each ship on their own. A slice that cannot be deployed independently is not a slice, it is a phase – and phases are where migrations go to die.
What to measure
Decide the numbers that say it worked before you start, and instrument them first. Retrofitting measurement onto a finished migration tells you nothing about what the migration changed.
Conclusion
None of this is exotic. It is the discipline of small, reversible steps applied to a problem large enough that skipping the discipline is tempting.
