Your team is upgrading a Next.js App Router codebase from Next 14, where `fetch` in Server Components was cached by default, to Next 15 or later, where it is not. How do you decide which fetches to opt back into the Data Cache?

## Why "restore the old default" is the wrong instinct The temptation is to make the upgrade a no-op — script `cache: 'force-cache'` onto every server `fetch` and move on. It is fast, it is reversible, and it is a mistake for three reasons. First, the old default was itself a known source of bugs: content frozen at build time, dashboards showing yesterday's numbers, and teams reaching for `no-store` as a superstition rather than a decision. Reinstating it globally re-buys those bugs. Second, and more seriously, it re-buys any *cross-user* sharing that was happening implicitly. Under the old default a fetch of a per-user endpoint was cached unless someone thought to opt out. The upgrade is the one moment when that class of bug surfaces as a behaviour change you can actually observe. A blanket script buries it again. Third, it leaves the codebase with no expressed intent. Every fetch carries the same annotation, so a reader still cannot tell which data is genuinely shareable. ## The classification that drives the decision Two questions, asked per fetch: **Is this response the same for every user?** Not "is it usually the same" — is it *by construction* independent of who is asking. Catalogues, published content, reference data, feature configuration: yes. Profiles, carts, entitlements, anything the authorisation layer touches: no. **How stale may it be, from the product's point of view?** Expressed in the units the business uses — "an editor should see their change within a minute", "pricing must be correct at checkout", "this changes twice a year". That grid gives you the policy: - **Shared, immutable or invalidated on write** → `cache: 'force-cache'`, plus `next.tags` so the writing side can invalidate by name. - **Shared, tolerant of a known staleness window** → `next: { revalidate: N }`, with N derived from how often the *source* changes rather than from how fresh you want the page to feel. - **Not shared** → leave it uncached. The new default is correct here, and adding `cache: 'no-store'` is worth it as documentation on the ones a future reader might be tempted by. - **Shared but expensive and rarely changing, with no invalidation hook** → a long interval is usually better than `force-cache`, because an unbounded entry with no invalidation path is a page nobody can correct without a deploy. ## Sequencing the work A migration that tries to classify every fetch up front stalls. A more reliable order: 1. **Ship the upgrade with the new default**, changing nothing. Correctness improves immediately: personal data stops being shared, and stale-content complaints stop. 2. **Watch the origins.** Request volume per endpoint is the signal that separates fetches that genuinely needed caching from the ones nobody missed. Most codebases find the list is far shorter than the number of call sites. 3. **Opt in the hot, shared ones**, one at a time, with a stated interval and a tag. Each is a small reviewable change with a visible before/after. 4. **Write the rule down** so new code does not re-litigate it, and so "why is this cached?" has an answer other than the framework's default. Step 1 is the part that needs organisational courage: it temporarily costs origin traffic. Naming that cost in advance — with a rough estimate and a rollback plan for the two or three heaviest endpoints — is what makes it acceptable, and it is usually far cheaper than the alternative of shipping a leak. ## Guarding against the next flip The deeper lesson is that this codebase had its data-freshness policy encoded in a framework default, which is why a version bump could change product behaviour. The durable fix is to make caching intent explicit at every call site that has one, so the default becomes irrelevant. When every shareable fetch says what it is and why, the next major version's default is a footnote instead of an incident. A secondary guard is a small number of shared data-access modules rather than `fetch` scattered through components. Centralising means the classification happens once per data source instead of once per call site, and it gives you somewhere to put the tag vocabulary. ## What a strong answer sounds like Name the trap (blanket restore), give the two-axis classification, sequence the rollout so correctness lands first and performance is restored on evidence, and finish on the structural point: the goal is not to reproduce Next 14 behaviour but to stop depending on any default at all.