Tell people about a login change in three tiers and in this order: your own support and account teams first, then the customer administrators and account owners who depend on your login most (personally, well before the date), then end users (with a plain notice shortly before the change, only if they will notice something). The notice itself should say the date, what changes, what stays the same, and where to get help, and it should not promise anything you have not rehearsed. A login change is a customer event as much as an engineering project, so the plan for who hears what and when deserves the same attention as the technical cutover.
This post is for the CTO, VP of engineering or IT director at a B2B SaaS, EdTech or non-profit platform that has decided to move off a hosted identity provider such as Azure AD B2C, Auth0, Okta or Amazon Cognito, and is more worried about what customers and their users will notice than about the technical work. It ends with a one-page plan you can copy.
Why is a login change a customer event and not only an engineering project?
Login is the one part of your product that every user touches, every time. If it changes, even when the change is meant to be invisible, a share of users will notice something: a new look on the sign-in page, a request to sign in again, a password reset, or a different domain in the address bar. Customers who have connected their own directory or single sign-on will notice more, because their configuration may need to change.
Without a plan, the effects arrive as support tickets and a few pointed calls from the accounts that matter most. With one, the people who need to act know early and the people who do not need to act are not alarmed.
What will users notice, and what will they not?
That depends on how you migrate. If you move accounts and keep the same sign-in address and passwords working, most users see no difference apart from possibly a new sign-in page style. If passwords cannot be carried over and users need to set a new one, every user notices. Multi-factor methods deserve a check of their own: passkeys are tied to the domain they were registered on, so a change of sign-in domain means users register them again, and the secrets behind authenticator-app codes often cannot be exported from a hosted provider. Where either applies, plan for users to enrol their second factor again. Write down, per user group, what they will actually see, because the rest of the plan hangs on it. Our post on dual-run migrations with zero downtime explains the technical approach that keeps both systems working side by side and gives you the facts for this step.
Which customers carry the most risk if something goes wrong?
Rank customers by what a bad login day would cost you: the largest contracts, customers with their own single sign-on connection, customers in a renewal or a security review, and any with a contractual uptime commitment. These get a personal conversation, not a mass email.
Who needs to be told, and when?
Customer admins who have connected their own directory or single sign-on
If the migration changes anything their identity provider depends on, such as a metadata URL, a callback address, a certificate or an attribute mapping, they need the new values, a test window, and a date by which to change them. Give them as much time as their own change process needs. For many companies that means a ticket and an approval cycle, so weeks and not days.
End users who may be asked to sign in again or reset a password
Tell them only what concerns them: that a sign-in will be requested on a given date, whether they need to do anything, and where to find help. Send the notice a few days before, because an earlier one tends to be forgotten and a later one gets missed, and send it again on the day if action is needed. If nothing changes for them, a short in-product note may be enough.
Your own support and account teams
They hear first, because they will take the questions. Give them the date, the talking points, a list of the customers getting a personal call, and the rollback criteria, in a short session before any customer is told.
What should the notice say?
The date, what changes, what stays the same, and how to get help
Keep it short and put these things in order:
- The date and time window of the change (and the time zone).
- What will be different for the reader, in one or two sentences.
- What will not be different, such as the address they sign in at and their data.
- What they need to do, if anything, and by when.
- Where to get help, with a named contact for administrators.
What should you avoid promising before the cutover is rehearsed?
Avoid “no downtime,” “no action required,” or a precise time before you have run the cutover on a copy of the real data. State the plan as the current expectation and say you will confirm after the rehearsal. If a customer asks for a guarantee, be honest about what you have tested. Do not describe automated migration tooling you do not have; moving accounts between providers is largely a guided, project-by-project effort, and the notice should reflect your actual process.
If you are leaving Azure AD B2C, note that Microsoft has said it supports existing customers until at least May 2030, so the date you choose can come from your own readiness. We cover what Microsoft said in our Azure AD B2C end of sale and support timeline.
How do you prepare support for cutover week?
What questions will you get, and who answers them?
Expect: “Why do I have to sign in again?”, “My password does not work,” “I did not get the reset email,” “How do I set up my authenticator or passkey again?” “Is this a phishing email?” (a real risk, since notices about login changes are exactly what phishers imitate), and administrators asking whether their single sign-on connection still works. Write answers in advance, name who answers each type, and agree how engineering is reached quickly if a pattern appears. Tell users the notice only comes from your official domain and never asks for a password.
What is the rollback plan, and when do you decide to use it?
Decide the trigger before the day: for example, an error rate above a threshold on sign-ins, or a failure for the top accounts on your risk list, measured over a fixed period. Name the person who makes the call and what rolling back means in practice. Having the old system available in parallel is what makes this possible, which is the point of the dual-run approach above.
What should you put in the migration budget for communication and support?
The budget should include people-time as well as tooling. The items to estimate are account-manager time for personal conversations, support hours during and after cutover week (usually higher than normal for a short period), engineering hours on call, and the cost of running two systems in parallel while customers move. Our posts on what it costs to switch identity providers, the decision memo for replacing an identity provider and whether waiting is cheaper cover the larger cost picture. Give communication its own line in the budget so that it is visible when costs are reviewed.
A one-page communication plan to copy
| When | Audience | What happens | Owner |
|---|---|---|---|
| Weeks before | Support and account teams | Briefing, talking points, risk list | Head of support |
| Weeks before | Customers with their own SSO | Personal call, new configuration values, test window | Account manager and engineering |
| Days before | All users who will notice | Short notice with date, change, help link | Product |
| Cutover day | Support and engineering | Watch sign-in errors, apply rollback criteria | Engineering lead |
| Days after | Affected customers | Confirmation, a note on anything that changed | Account manager |
| Week after | Internal | Review tickets and what to fix next time | CTO |
Our migration pages for Azure AD B2C, Auth0 and Okta describe the technical side of each move.
Frequently asked questions
How far in advance should you tell customers about a login change?
Administrators who must change their own configuration need weeks. End users who only need to sign in again need a few days. Support and account teams need to hear before anyone.
Do you need to tell users if the change should be invisible?
Not always, but have a short note and a support answer ready, because small differences such as a new session or a changed sign-in page will still produce questions.
Should the notice come from support or from the CEO?
For administrators and key accounts, a named person they know. For end users, a product or support address on your own domain. The point is that readers can recognize it as genuine.
What if a customer objects to the change?
Ask what they depend on and whether a delayed date for their account is possible. Keeping them on the old system a little longer is cheaper than a failed login for their staff, if your parallel setup allows it.
How do you stop phishers using the announcement?
Say in the notice that you will never ask for a password, link only to your own domain, and tell support to treat reports of suspicious login emails as a priority.