Microsoft Entra app registrations and third-party integrations in tenant-to-tenant migrations

In a Microsoft 365 tenant-to-tenant migration, mailboxes and files are only part of the story. Identity-integrated apps, enterprise applications, SSO, provisioning, API permissions, secrets, certificates, and third-party SaaS integrations must be inventoried, rebuilt or reconfigured, re-consented, tested, and cut over with care.

What this migration really involves in 2026

Microsoft Entra ID, formerly Azure Active Directory, is the identity platform behind Microsoft 365 sign-in, application access, conditional access, SSO, workload identities, and many third-party integrations. During a tenant-to-tenant migration caused by a merger, acquisition, divestiture, rebrand, or tenant consolidation, Entra-integrated applications do not usually move as simple portable objects. Instead, you normally inventory the source tenant, decide what to keep, recreate or reconfigure app registrations and enterprise applications in the target tenant, grant consent again, rebuild assignments, update SSO and provisioning settings, and validate production sign-in behavior before cutover.

Important principle: app registrations and enterprise apps are not usually transferred as-is

A source tenant app registration, enterprise application, service principal, consent grant, user assignment, group assignment, secret, certificate, and object ID should be treated as tenant-specific unless you have confirmed otherwise. When an app is recreated in the target tenant, the application client ID usually changes. If the original app registration is multi-tenant and remains in use, the client ID may stay the same, but the target tenant still receives its own service principal, consent grants, assignments, and policies. Tenant IDs, object IDs, service principal IDs, group IDs, user IDs, SAML certificates, provisioning jobs, and Conditional Access targeting must be reviewed. Client secrets cannot be read back from Entra ID, so they must be replaced or rotated. Certificates and federated identity credentials must be exported, recreated, or replaced according to your security policy.

Prerequisites and access model

Start with established source and target Microsoft 365 and Microsoft Entra tenants, a domain and DNS cutover plan, validated identity strategy, and licensing aligned to the target-state services. Do not refer to this as an Azure AD subscription; depending on features used, you may need Microsoft Entra ID P1 or P2, Microsoft 365 subscriptions under the current NCE licensing model, Enterprise Mobility + Security, Microsoft Defender, Azure subscriptions, or third-party SaaS licenses. Use least-privilege administrative roles wherever possible. Common roles include Application Administrator, Cloud Application Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Hybrid Identity Administrator, Directory Readers, Reports Reader, and roles that can grant tenant-wide admin consent. Use Microsoft Entra Privileged Identity Management for just-in-time elevation where available. Reserve permanent Global Administrator access for tasks that truly require it.

Discovery checklist for every application and integration

Create a migration workbook before changing anything. For each app, capture: business owner, technical owner, criticality, sign-in volume, last sign-in date, supported account type, protocol such as SAML, OpenID Connect, OAuth 2.0, WS-Fed, SCIM, LDAP proxy, or custom API; app registration details; enterprise application details; redirect URIs; reply URLs; logout URLs; identifier and entity ID values; SAML metadata; signing and encryption certificates; claims and transformations; app roles; group and user assignments; delegated and application API permissions; admin consent status; OAuth permission grants; secrets and certificate expiration dates; federated identity credentials; managed identities; provisioning configuration; inbound and outbound webhooks; IP restrictions; Conditional Access policies; authentication context; named locations; token lifetime dependencies; custom domains; DNS records; firewall rules; and dependencies on on-premises systems.

Use Microsoft Graph and PowerShell for inventory

Portal review is not enough for a large tenant. Use Microsoft Graph PowerShell, Microsoft Graph API, or a trusted migration assessment tool to export application and service principal data. Useful discovery areas include applications, service principals, owners, passwordCredentials, keyCredentials, requiredResourceAccess, OAuth2 permission grants, app role assignments, group and user assignments, SAML single sign-on settings, provisioning configuration, audit logs, and sign-in logs. Example Microsoft Graph PowerShell discovery commands include Get-MgApplication -All, Get-MgServicePrincipal -All, Get-MgOauth2PermissionGrant -All, Get-MgServicePrincipalAppRoleAssignedTo, Get-MgApplicationOwner, and Get-MgAuditLogSignIn with appropriate permissions such as Application.Read.All, Directory.Read.All, AuditLog.Read.All, and Reports.Read.All. For sensitive data, store exports securely and treat them as migration evidence and configuration backup.

Decision table: keep, recreate, reconfigure, or retire

Classify every application before migration. Retire apps that are unused, duplicate, unsupported, or risky. Recreate single-tenant app registrations that must live in the target tenant. Reconfigure third-party SaaS applications that can switch their identity provider metadata, redirect URIs, SCIM token, or SAML certificate to the target tenant. Keep a source-tenant or multi-tenant app only when the business, security, and ownership model supports it, and when consent and access from the target tenant are explicitly designed. For each decision, document rollback, owner approval, testing scope, and cutover timing.

Migration guidance by integration type

For OpenID Connect and OAuth apps, recreate or update app registrations, redirect URIs, logout URLs, API permissions, exposed APIs, app roles, secrets, certificates, and admin consent. For SAML apps, recreate enterprise applications or gallery apps, export or regenerate metadata, update entity IDs and reply URLs, validate claims, rotate signing certificates if needed, and upload new identity provider metadata to the SaaS provider. For SCIM provisioning, create a new provisioning configuration in the target tenant, generate new tokens, confirm attribute mappings, define matching rules, and test create, update, disable, and delete behavior. For Microsoft Graph and custom API apps, review delegated versus application permissions and remove over-privileged scopes before granting consent again. For Azure-hosted workloads, review managed identities, automation accounts, Key Vault access policies or RBAC, Azure DevOps service connections, GitHub workload identity federation, certificates, and environment variables. For third-party SaaS, check whether the vendor supports tenant switching, SAML metadata rollover, parallel identity providers, staged user matching, or whether a vendor-side migration ticket is required.

Modern Microsoft Entra features that can help

Not every scenario requires an immediate hard cutover. Microsoft Entra cross-tenant access settings can control inbound and outbound B2B collaboration, trust MFA and compliant device claims from another tenant where appropriate, and reduce friction during transition. Cross-tenant synchronization can automate creation and maintenance of B2B users from one tenant into another, which is useful during coexistence but is not a full app migration tool. Multi-tenant organizations can improve collaboration and people search across related tenants. Entitlement management and access packages can help govern temporary or ongoing access. Lifecycle workflows can assist with joiner, mover, and leaver processes in the target tenant. These capabilities support coexistence and governance, but they do not replace the need to rebuild app registrations, service principals, SSO, consent, and provisioning where the application must be owned by the target tenant.

Hybrid identity and directory synchronization considerations

Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync synchronize identities from Active Directory Domain Services into Microsoft Entra ID. They are not tenant-to-tenant migration tools for app registrations, enterprise applications, cloud-only identities, consent grants, or third-party SSO settings. In hybrid environments, plan sourceAnchor or immutable ID strategy, UPN and SMTP namespace changes, domain move timing, group writeback or cloud sync requirements, and decommissioning of legacy synchronization only after the target tenant is validated. If applications depend on on-premises LDAP, Kerberos, RADIUS, AD FS, custom claims, or legacy agents, include those dependencies in the application cutover plan.

Security and governance improvements during migration

A tenant migration is a good time to reduce identity risk. Review excessive API permissions, remove unused app registrations, enforce publisher verification where applicable, restrict user consent, require admin consent workflow, rotate long-lived secrets, prefer certificates or workload identity federation over client secrets, and document credential ownership. Rebuild Conditional Access policies carefully and validate MFA, authentication strengths, device compliance, named locations, session controls, and break-glass access. Review Microsoft Entra ID Protection, Privileged Identity Management, access reviews, app governance, audit logs, sign-in logs, and provisioning logs. Do not simply copy every legacy exception into the new tenant without business justification.

Testing and cutover approach

Test with pilot users, pilot groups, and non-production app instances where possible. Validate interactive sign-in, mobile and desktop clients, refresh token behavior, app role assignment, group-based access, admin consent, Graph/API calls, SCIM provisioning, deprovisioning, claims, Conditional Access outcomes, and audit logging. For SAML apps, plan a metadata swap or parallel identity provider configuration if the vendor supports it. For OAuth apps, plan redirect URI updates, secret or certificate replacement, and application configuration changes. For public-facing apps, coordinate DNS, custom domains, app URLs, firewall rules, and vendor-side changes. Monitor sign-in logs, provisioning logs, application logs, Graph errors, and support tickets during and after cutover. Maintain a rollback plan that defines what can be reverted, who can approve it, and when rollback is no longer practical.

Common issues to avoid

The most common problems are incomplete inventory, missing application owners, expired secrets discovered during cutover, unrecreated SAML claims, forgotten SCIM provisioning jobs, admin consent not granted in the target tenant, hard-coded tenant IDs or object IDs in code, group IDs embedded in authorization logic, Conditional Access policies blocking service accounts, DNS domains moved before apps are ready, and SaaS vendors requiring advance notice. Another frequent issue is assuming that user migration automatically preserves application access. In reality, app assignments, groups, roles, and permissions must be mapped and rebuilt.

Related Microsoft 365 workloads

Identity-integrated application migration should be coordinated with Exchange Online, SharePoint Online, OneDrive, Microsoft Teams, Viva Engage, Microsoft Forms, Microsoft Entra users and groups, Microsoft Entra B2B guest accounts, and Microsoft Entra joined devices. The application plan must align with mailbox cutover, file permissions, Teams collaboration, device enrollment, domain movement, licensing assignment, and end-user communications.

Key takeaways

• Microsoft Entra app registrations, enterprise applications, SSO settings, SCIM provisioning, service principals, consent grants, and assignments are usually rebuilt or reconfigured, not directly moved.
• Inventory must include owners, protocols, API permissions, secrets, certificates, redirect URIs, SAML metadata, claims, app roles, provisioning, Conditional Access, and sign-in activity.
• Use least-privilege Microsoft Entra roles and Privileged Identity Management instead of relying on permanent Global Administrator access.
• Cross-tenant access settings, cross-tenant synchronization, multi-tenant organizations, entitlement management, and lifecycle workflows can support coexistence, but they do not replace app migration work.
• Use the migration as an opportunity to remove unused apps, reduce over-privileged permissions, rotate credentials, improve consent governance, and strengthen Conditional Access.

Planning a merger, divestiture, or Microsoft 365 tenant consolidation? IT Partner can assess your Microsoft Entra ID applications and third-party integrations, build a tenant-to-tenant migration plan, and help execute testing, security hardening, and cutover with minimal disruption.