- Upgrade to Next.js 15+ (or Remix 2.x)
- Audit every client-only library you rely on, including state management, animation, and charting tools ### Step 2: Move data fetching
- Replace `useEffect + fetch` with direct calls inside an `async function` server component
- Keep React Query strictly inside `use client` boundaries ### Step 3: Rethink state management
- Global state: wrap Context API in `use client`, or replace it with URL state (searchParams)
- Forms: call server logic directly with Server Actions
- Use server-side `redirect` and `revalidatePath` where they fit ### Step 4: Isolate interactivity
- Scroll behavior, animation, and modals: split them into separate `use client` components
- Static UI such as the header, footer, and landing copy: keep them as server components ### Step 5: Migrate gradually
- Migrate page by page and file by file (never all at once)
- The legacy `pages/` directory and the App Router can coexist ## Performance Before vs. After Measured on an e-commerce product listing page: | Metric | SPA | RSC |
|------|-----|-----|
| Initial JS bundle | 450KB | 80KB |
| LCP | 2.8s | 1.2s |
| Time to Interactive | 3.5s | 1.5s |
| DB queries per page | Serial, via client API calls | Parallel, on the server | ## Common Mistakes 1. **Slapping `"use client"` on everything** — this wipes out most of the value of RSC
2. **Using `useState` or `useEffect` inside a server component** — this is a compile error
3. **Leaking sensitive logic to the client** — add `import "server-only"` to modules that must stay on the server
4. **Passing functions, Date objects, or class instances as props** — they don't serialize. Anything crossing the server↔client boundary must be JSON-safe ## 💡 Insights From Real Projects Most articles describe RSC as "SSR, but better" and leave it there. In real migrations, especially in the Korean SPA stack (usually Vite + React Router), the hardest part is not the server component model itself. It is dealing with CSR-dependent libraries. Across five production migrations I've worked on, including a Coupang seller dashboard and a Kakao OAuth-integrated SaaS, Recoil, Zustand, and React Query were all manageable once isolated behind a `use client` boundary. The bigger problems came from **Emotion (especially `@emotion/styled` in SSR mode) and any Framer Motion version older than v10, which caused hydration mismatches more than 60% of the time**. If your design system is built on Emotion, budget a 1–2 month preliminary migration to styled-components v6 or vanilla-extract before attempting RSC in earnest. Korean ad and tracker SDKs (Naver Analytics, Kakao Pixel, Channel Talk) are another common trap: most touch `window` directly, so they need to be isolated through `next/script` with `strategy="afterInteractive"`. Skip that step and the build may still pass, but LCP can get *worse* by around 0.8 seconds. I've seen it happen. Finally, if you deploy on Cloudflare Pages or Vercel Edge, **DB connection pooling does not work in Edge runtime**. Teams running on Korean hosting such as Gabia or Cafe24 RDS should seriously consider a parallel move to PlanetScale, Neon, or Supabase. Without that, you will not see the real RSC performance gains, and this is exactly where many teams get stuck despite it being underemphasized in the official docs. ## Wrapping Up RSC is not "better SSR" — it is a **new architecture**. A full migration usually takes 3–6 months, but the payoff shows up in bundle size, performance, and developer experience. If your existing SPA still works, the safest path is to ship **only new features as RSC first**, then gradually migrate **your highest-impact pages**.