Tailwind CSS and Legacy PostCSS Stylesheets: Coexistence Strategy for Incremental Migration

A small production application is introducing Tailwind CSS v3 as a PostCSS plugin alongside an existing hand-written stylesheet, with the goal of migrating feature-by-feature without a full rewrite or downtime. The immediate boundary is between legacy global CSS class names and Tailwind utilities compiled in the same pipeline. Because Tailwind's JIT engine scans content files to generate only used utilities, we need to confirm how dynamic class names are handled and whether the prefix option is the right guard against accidental collisions with legacy selectors during the overlap period.

Before relying on JIT defaults, the installed major version must be verified. Assuming Tailwind v3 defaults, the content array must cover every template that constructs class strings at runtime, but uncertainty remains about whether safelisting is required for classes assembled from variables in JavaScript-driven components. There is also a coordination cost: applying a prefix to Tailwind utilities changes every utility reference, which may conflict with the desire to keep legacy CSS untouched while new components adopt utilities.

How should the content globs and prefix setting be configured so that both legacy CSS and Tailwind utilities coexist safely during incremental migration? What is the recommended approach for dynamic class names that are not statically present in templates? Are there documented trade-offs between using a prefix versus relying on specificity and cascade order to separate the two systems?