Identity cutover under a Transition Services Agreement.

2026-11-08 · TenantFlex

A Transition Services Agreement, or TSA, is the part of a divestiture that keeps the lights on. The seller agrees to keep running some IT for the business it has just sold, for a set period, usually between six and twenty-four months. That almost always includes email, the network and identity: the directory people sign in to and the single sign-on in front of every application. The buyer pays for those services month by month, and has to be fully off them by the date the agreement ends.

Email and the network are moved by the IT team on their own schedule. Identity is different. Every application that signs in through the seller's identity provider has to be recreated in the buyer's, and each one has an owner who has to switch it over. That makes SSO the long pole of most TSA exits, and the one most often still running when the end date arrives.

What a TSA covers, and what the end date means

The agreement lists the services, their monthly price and the end date. Extensions are possible but rarely cheap: the seller has no reason to keep supporting a business it no longer owns, and the price of an extra quarter is set accordingly. Some agreements step the fee up after the planned date. Either way, every month on the TSA is a line on an invoice, and the identity work is usually what decides how many of those lines there are.

The date is in the contract. The number of applications is not. Finding out the second one early is what makes the first one achievable.

You do not control the seller's tenant

Everything about a TSA exit follows from one fact: the identity provider you are leaving belongs to someone else. The seller's IT team has a business of its own to run, every change you ask for is a ticket on their side, and the most you can reasonably expect is read access. That is also all you should want. A migration that writes to the seller's tenant creates risk for both companies and a dispute if anything goes wrong.

TenantFlex connects to the seller's tenant with one read permission and never asks for more. It reads every SAML and OAuth/OIDC application, its claims, its assignments and its certificates, and recreates each one in the buyer's tenant. The seller's side is read-only from the first day to the last.

A plan built back from the end date

Most of the elapsed time in an identity migration is cutover coordination with application owners, not the migration itself, which takes minutes per application. So the plan is built backwards from the TSA end date, with the buffer at the end, because the last applications are always the hard ones.

When	What	Who
Day one of the TSA	Discovery on the seller's tenant: the real application count, a band for each, owners, last sign-in and credential expiry. In a six-month agreement this is week one, not month two.	Buyer IT, one read permission from the seller
Month one	Retire what nobody used in the last ninety days. Confirm the destination tenant and provider. Name an owner for every application that is left.	Buyer IT, application owners
Month two	Pilot wave: a handful of straightforward applications with willing owners. Prove the cutover steps and the hand-off bundle on them.	Buyer IT, pilot owners
Middle months	Remaining waves as scheduled jobs, straightforward applications first, needs-review ones after their claims have been checked. Each owner switches on their own date.	Application owners, with the bundle
Last month	The manual-work applications and anyone who missed their wave. Re-run discovery and keep the result as exit evidence.	Buyer IT
End date	Nothing signs in through the seller. The seller removes the applications on its side; you never touched them.	Seller IT

What moves, and what your team recreates

For a SAML application, the entity ID, reply and sign-on URLs, NameID format and the attribute statements are recreated in the destination, with the claims translated into that provider's own form. A new signing certificate is generated on the destination side. For an OIDC or OAuth application, the redirect URIs, grant types, scopes and API permissions move; client secrets cannot be read from any identity provider, so new ones are issued and handed to the owner once.

User and group assignments, conditional access or sign-on policies, and SCIM provisioning are read and reported, not moved. In a divestiture that is the right split: the people and groups in the buyer's tenant are different objects from the seller's, and the policies should reflect the buyer's rules, not the seller's. Discovery shows each owner what to recreate, so nothing is found out at cutover.

The users themselves, their mailboxes and their devices are a separate workstream. TenantFlex moves applications; it assumes the people already exist in the destination tenant by the time their applications do.

Choose the destination once

A TSA exit is a chance to pick the identity provider you want rather than inherit the seller's. The buyer's tenant can be on Microsoft Entra ID, Okta or PingOne regardless of what the seller runs, and the same read-only discovery, pilot and waves apply to every pair. Changing provider later would mean a second migration, so the decision belongs in month one.

Exit evidence

At the end date, the buyer has to show the dependency is gone, to the seller and often to its own auditors. TenantFlex leaves three things behind that do that job: an execution log for every migration job, a hand-off record for every application, and a final discovery report on the seller's tenant that lists what still signs in through it. When that last list is empty, the exit is done, and the seller can decommission with confidence.

TSA identity exit checklist

1. Find the end date and the monthly fee in the agreement. Both numbers decide how much buffer you can afford.
2. Ask the seller for one read permission, in writing, in week one. Application.Read.All on Entra ID, okta.apps.read on Okta, the Configuration Read Only role on PingOne. Nothing more.
3. Run discovery and fix the real count. Not the number in the data room; the number of applications that are federated and in use.
4. Retire before you migrate. Every application nobody signed in to in ninety days is one less owner to coordinate.
5. Decide the destination provider and tenant. Once.
6. Name an owner per application and book their cutover window. The plan is a calendar of owners, not a list of applications.
7. Pilot a wave, then schedule the rest. Straightforward first, needs-review after their claims are checked, manual work last.
8. Keep the seller read-only throughout. If a step would write to their tenant, it is the wrong step.
9. Re-run discovery before the end date and keep the report. An empty list is your exit evidence.

Other deal-driven moments with a date on them

The TSA is the clearest case of a migration with a contractual deadline, but it is not the only one.

• Spin-offs and IPOs. A unit spun out as its own company needs its own identity set-up before listing day. These are planned months ahead, so discovery can start early and the waves can follow the prospectus timetable.
• Private equity roll-ups. A platform company that buys five or ten smaller businesses folds each one into its tenant, and does it again with the next acquisition. The same read-only discovery and the same waves repeat per deal, with the previous one's lessons in the plan.
• Pre-close due diligence. Discovery works before the deal closes as well as after. A read-only scan of the target tells the IT due-diligence team how many applications there really are, which credentials are about to expire and how much integration work is being bought, while there is still time to price it.
• Joint venture unwinds and insolvency sales. Fast, untidy separations, often run by administrators who need the business standing on its own within weeks. The read-only approach matters most here, because nobody has time to negotiate write access to a tenant that is being wound down.

The same move without a deal

• Moves to a sovereign or government cloud. A defence supplier moving to Microsoft's GCC High, or a European firm under data-residency pressure, usually ends up in a brand-new tenant. TenantFlex runs on premises as well as as a service, so the migration tooling can sit inside the boundary it is moving you into.
• A clean rebuild after a breach. When a tenant is compromised, the remediation is sometimes a fresh one. The old tenant is read-only by policy at that point, which is the only access TenantFlex needs, and the incident-response team already on site can run discovery while containment is still under way.
• Tenant sprawl clean-ups. Several tenants left over from acquisitions that were never merged, each with its own licences, administrators and audit scope. There is no deadline, so the case is made on cost: discovery gives the application count per tenant, and the consolidation follows the same waves.
• Rebrands and domain changes. A new name sometimes forces a new tenant, and marketing has already fixed the launch date. The plan is built back from it in the same way as from a TSA end date.

In every one of these, the work is the same: read what is there, decide what moves, recreate it in the destination with a record of every step, and hand each application to its owner with what they need to switch.