AI Features

Migrating to RSC Incrementally

Learn about React Server Components as an architectural shift that can be adopted gradually, without rewrites, while preserving correctness, performance, and team velocity.

Most large React applications reach a point where performance problems become difficult to reason about. Pages feel slow, but it is unclear why. A route transition may block entirely, even though only a small part of the screen depends on slow data. Teams add spinners, skeletons, and memoization, yet the UI still feels fragile: loading states flicker, waterfalls appear, and small changes unexpectedly affect unrelated parts of the page.

Traditionally, React encouraged us to treat the component tree as a single client-side execution model. Even when data was fetched on the server, the rendered UI was rebuilt in the browser, forcing JavaScript to parse, execute, and hydrate everything before the page felt usable. Over time, applications accumulated complex client-side data fetching logic, duplicated shaping of server data, and large bundles that shipped far more code than the user actually needed to interact with.

When teams first encounter React Server Components, they often assume the solution requires a clean break: a new app router, a rewritten data layer, and a wholesale move away from client components. This assumption creates resistance. Most production systems cannot stop feature development to perform a full rewrite, and partial adoption feels risky without a clear mental model of what is safe to move and what must remain.

React 19 introduces Server Components not to force a rewrite, but to correct a long-standing mismatch between where work happens and who owns it. The real problem is not that components live on the client it is that data ownership, rendering responsibility, and interaction logic are tangled together. Incremental migration exists to let us untangle those concerns gradually, reclaiming performance and clarity without breaking the app or the team.

Incremental RSC migration is about shifting ownership across stable boundaries, not rewriting the tree
Incremental RSC migration is about shifting ownership across stable boundaries, not rewriting the tree

The diagram shows a UI tree divided horizontally into layers. The top layer is a server-rendered shell responsible for layout and data preparation. Beneath it sit multiple client islands that remain interactive and unchanged. Over time, arrows indicate ownership moving upward: data fetching and shaping migrate into the server layer, while client components shrink to focused interaction roles. Suspense boundaries mark stable seams where this transition can occur without blocking the whole screen.

Incremental migration with server and client components

React Server ...