Product migration

Move each product to the owned issuer without changing its local account IDs, records, roles, or tenant boundaries. The previous provider remains a migration and rollback artifact until the owned engine and each product pass acceptance. A client record or matching email is not a migration of a person.

Inventory first

Record current product accounts and role assignments, the exact central issuer and subject previously linked to each, Institution mappings, active sessions, callbacks, service identities, and revocation behavior. Identify accounts with duplicate or changed emails. Review every proposed new issuer and subject binding against local credential proof and current sponsorship; never bulk-link by email.

Pilot one product

Complete owned-engine admission, client registration, logout, recovery, and key rotation gates in staging.
Register the product’s web or native client and separate lifecycle consumer for the exact environment.
Link a small set of existing local accounts through the reviewed proof and sponsor flow. Require exact product acknowledgement after durable installation.
Test sign-in, local role refusal, cross-Institution isolation, suspension, rehire, stale lifecycle, session revocation, and account recovery.
Enable mandatory central sign-in only after the product’s own acceptance record is complete.

Support must keep agent and visitor identities separate. Sign retains recipient passcodes, consent and local document authorization. AI keeps explicit provisioning and its separate machine keys. Mail retains its delivery credential and checks local officer and mailbox authority after workforce login. Product-specific protocols must not be weakened to fit a shared sign-in page.

Roll back safely

Keep the guarded database and audit history. A rollback must not revive a person or role revoked after cutover. Contain affected sessions and clients, apply the latest central lifecycle state, and use a reviewed operator decision for ambiguous bindings. Never write previous-provider database tables directly. Do not treat a deployed old login screen as permission to restore a legacy bypass.