A multi-product company must unify authentication across products that each built their own login. What is the migration risk, and how is it sequenced?

The risk

Authentication is the single most availability-critical path in any product. A migration defect does not degrade a feature; it locks every user out of everything. And because it is a one-way door for user credentials and sessions, rollback is far harder than for an ordinary service.

The secondary risk is subtler: each product's login encodes assumptions nobody wrote down — session lifetimes, multi-factor policy, account-linking behaviour, what happens on email change, how service accounts authenticate. Unifying them means choosing one behaviour and silently changing it for some users.

The sequencing

1. Build the identity service and run it alongside, serving no traffic. Establish operational maturity — monitoring, capacity, failover — before anything depends on it.

2. Migrate a low-risk product first, ideally an internal one, and keep the old path available.

3. Dual-run per product with a feature flag, moving a percentage of users and watching authentication success rate, not just error rate. A drop in successful logins with no error-rate change is the characteristic signature of a broken migration — users failing at a step that returns 200.

4. Migrate account linkage before migrating login. Users with separate accounts per product must be linked deliberately, with their consent where identities differ. Doing this after cutover means resolving duplicate identities under time pressure.

5. Keep sessions valid across the cutover. Forcing every user to re-authenticate simultaneously creates a login stampede against a service with no production track record, and it generates a support event.

6. Decommission the old paths explicitly. Otherwise the organisation operates several authentication systems permanently, which is the worst of both worlds — the complexity of the migration without the consolidation benefit.

The properties that must not regress

• Session revocation must work everywhere immediately. A unified login with per-product session caches that ignore revocation is a security regression disguised as a consolidation.
• Multi-factor enrolment must carry over, or users are silently downgraded.
• Rate limiting on the authentication path, because it is now a single high-value target for credential stuffing across every product.
• Availability sized for the aggregate, since a shared identity service is now a hard dependency for every product simultaneously — the availability arithmetic changed and must be recomputed.

The strategic benefit worth the risk

One place to implement multi-factor, session policy, anomaly detection, device trust and revocation. Per-product authentication means every improvement is implemented several times, at different qualities, and the weakest one defines the organisation's actual security posture.