RSC Is Cheap in Greenfield. Expensive in Retrofit.

React Server Components are cheap when they’re the default.

They can get very expensive when they’re the retrofit.

In a greenfield Next.js app, you can design the architecture around the server from day one:

• Fetch data close to where it’s rendered
• Keep client components small and intentional
• Avoid unnecessary global client state
• Let the server/client boundary shape the application

But take an existing application that was built around client-side state, effects, providers, and API calls, and:

“Let’s move this to RSC.”

becomes a very different project.

The difficult part usually isn’t converting components.

It’s untangling the data flow.

A client-oriented codebase often assumes something like:

page
  ↓
provider
  ↓
effect
  ↓
API
  ↓
state
  ↓
children

Move pieces to the server without redesigning that flow and you can easily replace client-side complexity with server-side waterfalls.

One component waits for data.

Its child discovers it needs something else.

That data unlocks another request.

And suddenly an architectural change that was supposed to improve performance has simply moved the latency somewhere less visible.

This is why I think teams adopting RSC in an existing application should document one thing very clearly:

Where does the server/client boundary actually fall?

Not where the framework allows it to fall.

Where your application architecture says it should fall.

Document:

• What owns data fetching
• What state genuinely needs to live in the browser
• Which components require interactivity
• Which requests can run in parallel
• Where providers are still necessary
• Where "use client" begins? And, more importantly, why

RSC is a very good default when the architecture grows around it.

In a mature client-heavy codebase, though, the migration cost is often just architectural debt becoming visible.

And that’s usually the part worth solving first.