Feature-Flag Rollout vs. Immediate OAuth2 Cutover for a Zero-Downtime Passport Migration

We run a small Express application that authenticates users with Passport's local strategy backed by server-side sessions (connect-mongo). The plan is to move to an OAuth2 authorization-code flow without forcing any user to log out mid-migration, and I need to commit to one of two documented approaches before writing code.

Approach A is incremental: keep the local strategy active, add a feature-flag middleware that routes a growing percentage of traffic through the new OAuth2 guard, and share the existing session store between both guards. Approach B is an immediate cutover: issue tokens on first login, deprecate password auth once every active user has completed the flow, and keep refresh-token rotation disabled to limit the attack surface.

The unresolved decision is whether refresh-token rotation should be enabled during the overlap. Rotation improves safety if a credential leaks mid-migration, but it complicates the shared-session design and risks invalidating tokens for users still on the old path. We are on Passport v0.6.x and have not verified behavior against v1.x middleware signatures.

1. Given a shared session store, does enabling refresh-token rotation during a feature-flag rollout create race conditions when a request toggles between the old and new guards?
2. For a small user base, does the immediate cutover with rotation disabled carry materially more risk than the incremental approach?
3. Is there a documented way to keep both strategies mounted simultaneously without Passport's session serialization conflicting?