Replacing a login provider usually needs agreement from five groups: finance (the cost model and the current contract), security and compliance (where data lives and what evidence you can show), legal (data processing terms and notice periods), support and customer success (what customers will notice), and the engineering lead of every application that signs in through the current provider. The technical plan is rarely what delays the project. What delays it is discovering one of those approvers late, after the work has been scheduled, so the practical fix is to list them first and talk to them in a sensible order.
This post is for a CTO or VP of Engineering at a B2B SaaS company that already knows its hosted identity provider has to change, whether because per-user pricing is climbing, the provider has stopped taking new customers, or its limits are blocking an enterprise deal. It is only about who needs to agree and in what order. For the cost side, see what it costs to move off your identity provider, and for the document you will eventually circulate, see a decision memo for replacing your identity provider.
Why does replacing a login provider need more than an engineering decision?
Login touches every customer, every internal application and several contracts at once, so a change to it is closer to changing a payment processor than to changing a library. An engineer can swap the code behind a sign-in button in days, but nobody can change who holds customer personal data, or what customers see on their next sign-in, without other people agreeing first.
What changes for people who are not developers?
Finance sees a different bill and possibly an overlap period where you pay for two systems. Support gets questions from customers who see a new sign-in page or are asked to reset something. Security has a vendor to assess, and legal has a contract to read. Each of those is ordinary work, but each also has a queue, which is where the calendar time goes.
What usually delays the project?
Late approvals are the usual cause. A typical pattern is that engineering finishes a proof of concept, asks for budget, and then learns that the security team needs a vendor review that takes weeks, or that the current contract renews automatically unless notice is given a set period before renewal, often several months. Neither fact is hard to find in advance, which is why the order of conversations matters.
Who needs to agree, and what does each person need to see?
Finance
Finance needs the current annual cost and its trend, the date the current contract ends and what notice is required, the expected cost of the new setup, and any overlap period. They will also ask what happens to the current bill if the move takes longer than planned. Bring a range rather than a single figure, and state the assumptions behind it. The cost-at-scale post on per-MAU pricing shows how to model the current side.
Security and compliance
Security wants to know where user data will live, what evidence the new provider can supply (an independent audit report, a penetration test summary, a list of data locations), and how the change interacts with customer security reviews you have already passed. If enterprise customers have your login described in their own vendor files, they may need notice. Our post on the login evidence enterprise buyers ask for is a good checklist for what the new setup has to keep supporting.
Legal
Legal reads the new provider’s data processing agreement and checks the subprocessor list, and also reads the notice and termination terms of the current contract. For a provider that processes personal data on your behalf, the EU’s General Data Protection Regulation sets requirements for that arrangement in Article 28, including a written contract and conditions for engaging subprocessors (Art. 28(2) and 28(3)), so expect legal to ask for the provider’s standard terms early. If you have customers who were promised notice of subprocessor changes, legal will also need to tell them.
Support and customer success
Support needs to know what customers will notice: a new sign-in page, forced password resets, changed SSO setup steps, or nothing at all. They also need a short list of answers for the first week. Our post on telling customers you are changing your login system covers the customer-facing side, and this group is the one who will be answering the replies.
Engineering leads of every connected application
Anything that signs in through the current provider is affected, including internal tools, admin panels, partner integrations and mobile apps that nobody has touched for a year. Ask each owner how their app validates tokens, which claims (the fields in a token that describe the user) it reads, and who can test a change. A missed application is a common cause of an outage during cutover, so make this inventory before you ask anyone for a date.
In what order should you have the conversations?
Start with the facts that can cancel the project, then the ones that unlock money, then the ones that touch customers.
What should be settled before asking for budget?
First, the contract end date and notice period, because they set your real deadline. Second, a rough list of connected applications, because it sizes the work. Third, a first look at the security vendor review for the candidate provider, since a review that takes a month should start while the budget conversation is still happening. A move off a provider that has already announced an end date, such as Azure AD B2C, which is closed to new customers and supported until at least May 2030, gives you a fixed outer limit to plan around.
What should be settled before telling customers?
The migration approach (all users at once, or in waves), the cutover date, and the support script. Only then should customer success contact customers who have SSO set up with their own identity provider, since those customers have the most to test.
A one-page approval summary you can adapt
Keep the summary to a table with four columns: the decision, the owner, the evidence needed, and the date it is needed by. For example:
| Decision | Owner | Evidence needed | Needed by |
|---|---|---|---|
| Budget for new setup and overlap | Finance lead | Cost range, contract end date, notice period | Before vendor selection |
| Vendor passes security review | Security owner | Audit report, data locations, subprocessor list | Before contract signature |
| Data processing terms accepted | Legal | Provider’s standard terms, notice obligations to customers | Before contract signature |
| Customer communication plan | Support lead | Cutover date, customer-facing wording, support script | Before cutover |
| Application inventory confirmed | Each engineering lead | Token claims used, test owner | Before migration waves |
If you work from a specific provider, the pages for Azure AD B2C, Auth0 and Okta describe what a move off each of them involves.
What do approvers usually ask?
How long does the review usually take?
It depends mostly on the security review and on legal’s queue. Both can take from a few days to several weeks depending on the size of the organisation and whether the provider has standard documents ready, so start them in parallel instead of waiting for budget approval.
What if one approver says no?
Ask what evidence would change their answer, because a no in this process is usually a request for something specific, such as a report, a contractual term or a longer overlap. If the objection is a real blocker, such as a data location requirement, it is better to learn that before the proof of concept than after.
Should the CTO collect all approvals personally?
The CTO should own the list and the order, but each approver should sign off on their own area in writing, even if that is one email. A named owner per decision is what keeps the project from stalling when someone is on leave.
What to do next
List the five groups above with a named person for each, find the contract end date and notice period this week, and send each approver the single row of the summary that concerns them. Once the dates are known, the technical plan can be scheduled around them.