Get started Talk to us about your tenants.
Tell us which providers you run and what is coming up. We will show you what discovery finds, read-only.
[email protected] · www.tenantflex.comThe protocol is the easy part. The time goes on claims, assignments and the change the application owner has to make.
Ask someone who has moved a SAML application between identity providers what the work was, and they will not say "the SAML". They will tell you about the certificate that was uploaded to the wrong slot, the claim that was called email on one side and mail on the other, the group filter nobody knew was there, and the Friday afternoon spent on the phone with an application owner who had already gone home. The protocol is the easy part. This is a list of what actually moves, and where each one goes wrong.
Every SAML application has an entity ID and an assertion consumer service URL, and usually a sign-on URL, a logout URL and a NameID format. These copy cleanly, with one trap: identity providers add defaults you did not set. Entra ID's enterprise applications and Okta's app integrations each fill in fields the other has no equivalent for, so a faithful copy is not the same as the same configuration. The question to ask of each setting is not "does the destination have this field" but "does the application care".
The destination signs assertions with its own certificate, never the source's. That means every application has to be told about a new certificate at cutover, which is the single change the application owner cannot avoid. Two things follow. First, the migration tool must generate or select the destination certificate before anything is handed off, so the owner receives the right one. Second, the certificate's expiry starts a clock that someone has to watch; a migration is the moment most organisations discover they have no expiry tracking at all.
A SAML assertion carries attributes about the user, and each provider describes them differently. Okta writes ${user.email}, Entra ID writes user.mail, PingOne maps an attribute through its own attribute mapping. For the standard set, name, email, given name, surname, groups, the translation is mechanical, and a tool can do it. The problem is the other twenty percent:
The useful discipline is to classify each claim before moving anything: standard, needs a mapping decision, or needs the owner. A migration that does this up front turns a hundred small surprises into one review meeting.
Who can see the application in the portal and who is allowed to sign in. Users and groups exist in the destination directory under different object IDs, so assignments must be matched by a stable attribute, usually the group name or the user's UPN, and the unmatched ones listed. In an acquisition, where the directories are being merged at the same time, this is the step that depends on someone else's project.
Conditional access in Entra ID, sign-on policies in Okta. These are not part of the application, but they govern it, and an application that was behind MFA on the source and is not on the destination is a regression nobody will notice until an auditor does. The policy itself usually should not be copied; the fact that one applied should be in the hand-off so the destination's policy owner can decide.
If the application also receives users through SCIM, that configuration lives beside the SSO configuration and has its own credential. It can be migrated separately, but the cutover has to be coordinated, because an application that authenticates against the new tenant and provisions from the old one will drift within a day.
None of the above makes a user able to sign in. Until the application owner replaces the identity provider's login URL, entity ID and certificate in their own configuration, users keep going through the source tenant. This is the step that sets the elapsed time of any migration, because it happens in a hundred different change windows owned by a hundred different people. The best a migration tool can do is make the owner's job a five-minute copy from a bundle rather than a ticket back to the identity team.
Recreating an application in the destination takes minutes with a tool and a few hours by hand. The elapsed time is set by items 3, 4 and 7: the claims that need a decision, the assignments that need a matching directory, and the owners who need a change window. So the plan should be built back from a date, with discovery first, so the decisions are known; a pilot wave, so the owner process is rehearsed; and the rest in scheduled waves with logs. That is also, not by coincidence, how TenantFlex runs it.
Get started Tell us which providers you run and what is coming up. We will show you what discovery finds, read-only.
[email protected] · www.tenantflex.com