Your team wants to move a large Next.js app's production builds from webpack to Turbopack. How would you validate that switch before you ship on it?

## Why this is a migration and not a flag Bundling is the step between your source and everything users execute. A different bundler resolves modules, splits chunks, orders CSS and emits source maps by its own rules. The output is *supposed* to be equivalent, and in a plain App Router app it is — but the surface where it might not be is exactly the surface teams have customized. So the validation plan is: find the customization, prove equivalence where it matters, keep an exit. ## Step one: audit the bundler-specific surface Before building anything, read `next.config` and the toolchain with one question in mind — what here talks to webpack? - A **`webpack()` function**. Turbopack never reads it. Every rule inside is a port to `turbopack.rules` or a deletion because Turbopack already handles it natively (CSS, CSS Modules, PostCSS, Sass). - **webpack plugins**. There is no plugin API in Turbopack, so these cannot be ported by configuration. This is the item most likely to block the whole migration, which is why it belongs at the top of the audit rather than in the middle of a failing build. - **Loaders that reach into webpack internals.** The loader subset Turbopack supports covers the common cases; a loader manipulating compilation objects does not survive. - **Anything that hooks the build for observability** — source-map upload to an error tracker being the classic case, because it is usually implemented as a plugin and because it fails quietly: the build is green, and three weeks later nobody can read a stack trace. ## Step two: build both ways on the same commit Run the production build with each bundler and compare artifacts rather than impressions: - **Route coverage.** Every route that built before builds now. Errors here are frequently *not* Turbopack's fault — dev compiled only the routes people opened, so a build is the first pass that touches everything. - **Output size.** Per-route JavaScript and CSS in the same neighbourhood. A large unexplained swing means a chunking or resolution difference worth understanding before shipping, not after. - **Styling.** CSS and CSS Modules emitted, and — the subtle one — cascade order preserved, since ordering bugs look like random visual regressions. - **Source maps.** Generated, uploaded if that is part of your pipeline, and actually resolving a symbol you can check by hand. ## Step three: exercise the built app Size diffs do not catch a component that renders differently because an asset import changed shape. Start the built application and run whatever smoke or end-to-end coverage you have against it, then walk the surfaces most sensitive to bundling by hand: routes with dynamic imports, anything importing SVGs or other non-JS assets, pages with heavy third-party libraries, and any code branching on environment variables. In a monorepo, confirm the workspace root Turbopack infers is the one you intend — a wrong root changes what is in scope for resolution and produces confusing misses. ## Step four: roll it out with an exit ```bash next build # Turbopack (default in Next 16) next build --webpack # documented fallback while the migration settles ``` Flip CI first, on a branch, and let it run for a while before it becomes how you ship. Keep `--webpack` documented as the rollback and make sure someone other than the migrator knows about it. Then watch two signals for at least a release: **build duration** in CI, which is the payoff you are buying, and **client-side error rate**, which is where a subtle bundling difference shows up. Delete the webpack configuration only after that window closes cleanly — and note the deletion is itself the point, since carrying two configured pipelines indefinitely is the expensive outcome. ## What good judgment sounds like here The weak answer is "we flipped the flag and the build was faster." The strong answer names the equivalence checks, admits that build-only failures are usually pre-existing bugs the demand-driven dev server never surfaced, and keeps a rollback until real traffic has validated the artifacts.