The Identity Consolidation Problem: What 47,000 Identities Actually Teaches
In 2024, a global asset management firm acquired three regional competitors over 14 months. The integration team’s initial identity count estimate: 8,400 users.
The actual number, discovered during ACQI’s deployment in Week 1: 47,312 identities across four Azure AD tenants and three Active Directory forests.
The 5.6x gap wasn’t a planning failure. It was structural. Here’s why.
Why Identity Counts Are Always Wrong
1. People count users. Systems count identities.
A human Resources team counts employees. A human Resources system counts people with records in Workday or SAP. Neither counts service accounts, shared mailboxes, functional accounts, or the test accounts that someone created in 2019 and forgot about.
When ACQI scans an environment, it finds every object in Active Directory and Entra ID. This includes:
- User accounts (employee, contractor, service, functional)
- Computer accounts (servers, workstations, domain-joined devices)
- Service accounts (group MSA, standalone, virtual account)
- Application identities (service principals, app registrations, managed identities)
- Guest accounts (B2B, external, collaborative)
Most of the 38,000 identity gap in the asset management case was service accounts and application identities. Nobody had counted them because nobody had a central registry.
2. Every acquired entity has ghost accounts
Employees leave. Accounts stay.
Every mature organization has disabled accounts that were never deleted. Service accounts created for a project that ended. Test accounts that were converted to functional accounts. Shared credentials that became individual accounts when someone decided to “make it more secure” but never migrated the dependencies.
In a normal environment, these don’t cause problems. In a migration, every one of them has to be evaluated, resolved, or explicitly deprovisioned. You can’t migrate an account you don’t know exists.
3. Cross-tenant identities are invisible until you’re merging tenants
When an organization runs its own Azure AD tenant, Entra ID becomes the identity provider for M365, Azure, third-party SaaS, and any application configured for SSO.
When you acquire a company that has its own tenant, you discover:
- M365 users in the acquired tenant
- Azure users in the acquired tenant
- Application registrations owned by the acquired tenant’s service principals
- Conditional access policies scoped to the acquired tenant’s users
- Power Platform environments owned by the acquired tenant’s identities
- SaaS applications licensed through the acquired tenant
None of these appear in the acquirer’s identity inventory. They’re invisible until the deal closes.
Where the Complexity Actually Lives
Identity relationships are the hard part
Moving a user from Forest A to Forest B is straightforward. Moving a user whose access depends on a group in Forest A, where the group has a nested membership in a group in Forest B, where one of those memberships is through a service account in a cross-forest trust, and where the application they use for daily work authenticates through a service principal in Tenant C — that’s the actual problem.
The number of identities is a planning number. The dependency graph of those identities is the actual complexity.
The consolidation matrix problem
When you’re merging four tenants and three forests, you need to answer one question for every identity across all environments:
What happens to this identity post-consolidation?
Options:
- Migrate (move to target tenant/forest, update all references)
- Consolidate (merge with existing identity, maintain access)
- Deprovision (disable, archive, revoke)
- Convert (change type — turn a user into a shared mailbox, a service account into a managed identity)
Most identities can be handled automatically. The problem is finding the exceptions — the identities that look like they can be automatically handled but have hidden dependencies that will break production systems if they’re resolved incorrectly.
License implications
Every identity in Entra ID that has a license assigned has a cost. Every identity with a license assigned that has never signed in is pure waste. Every identity with a license assigned that has a second, duplicate license in a different tenant is double waste.
Post-merger identity consolidation is the moment when you discover:
- How many people are paying for M365 E5 when they only need E3
- How many shared mailboxes have per-user licenses assigned instead of shared mailbox licenses
- How many contractor accounts have full-time employee licenses
- How many licenses were assigned on the day an employee left and have been sitting unused ever since
The license reconciliation alone can pay for the discovery platform.
The Discovery-First Approach to Identity
What to scan
A complete identity discovery sprint should cover:
Active Directory
- All user objects: name, UPN, sAMAccountName, objectSID, whenCreated, whenChanged, lastLogon, lastLogonTimestamp, logonCount, distinguishedName, memberOf (all groups)
- All computer objects: name, OS, OS version, lastLogon, distinguishedName
- All service accounts: type (group MSA, standalone, virtual), password last set, SPNs, owned by, delegated to
- All group objects: groupType, memberOf, members (expanding nested groups), Group Managed Service Account links
- All OU structure with ACL delegation
- All AD trusts: direction, type, transitivty, Selective Authentication settings
- All group policy links by GPO name and applicable OUs
Entra ID
- All users: userPrincipalName, displayName, accountEnabled, assignedLicenses, lastSignInDateTime, creationType
- All groups: groupTypes, membershipRule, assignedLicenses, dynamicMembershipRules
- All application registrations: appId, displayName, owner, requiredPermissionAccess
- All service principals: appId, displayName, servicePrincipalNames, appOwnerOrganizationId
- All managed identities: objectId, type, tenantId
- All conditional access policies: conditions, grantControls, sessionControls, state
- All PIM assignments: roleDefinitionId, principalId, assignmentEndDateTime, memberType
The cross-environment correlation
The most valuable analysis is cross-environment correlation:
- Which AD user accounts have Entra ID counterparts that are not already linked?
- Which Entra ID users have no corresponding AD account (cloud-only)?
- Which service principals have permissions across multiple tenants?
- Which application registrations are orphaned (no owner)?
- Which groups have members in both source and target tenants?
Dependency mapping
For every identity flagged as business-critical, trace:
- What applications does this identity authenticate to?
- What is the authentication path for each application?
- What happens to each application if this identity’s UPN or SID changes?
- What groups does this identity belong to, and what do those groups grant access to?
What Most Teams Get Wrong
Wrong: Plan the migration, then run discovery
Discovery-first means discovery first. Every migration plan built without verified discovery data is a guess. The guess will be wrong. The only question is how late in the project you find out.
Wrong: Focus on user accounts, deprioritize service accounts
Service accounts represent 10-30% of total identity volume in a typical enterprise. They also represent 80% of the access that will break your migration if you move them incorrectly. Treat service accounts as first-class citizens in your planning.
Wrong: Assume the target’s identity data is clean
It isn’t. Every identity environment has duplicates, inconsistencies, stale data, and orphaned objects. Plan for data cleansing as part of the discovery phase. The cleansing work you do pre-migration determines how smooth your cutover will be.
Wrong: Consolidate licenses after migration
License rationalization should happen during discovery, not after migration. The license waste you identify pre-close is negotiating leverage. The license waste you identify post-close is just a bill.
The 47,312 Identity Resolution
For the global asset management firm, the 47,312 identities resolved as follows:
- 12,847 active employee accounts → migrated, UPN updated to acquirer domain
- 8,234 active contractor accounts → migrated under new naming convention
- 14,891 disabled/departed accounts → deprovisioned and archived
- 3,442 service accounts → evaluated individually: 2,103 migrated, 1,239 decommissioned
- 4,892 application identities → consolidated or converted to managed identities
- 3,006 guest/B2B accounts → reviewed, 2,841 revoked, 165 retained for active projects
Resolution took 6 weeks. The migration was delivered on schedule with zero P1 incidents.
The 6 weeks of discovery upfront prevented what the team estimated would have been a minimum of 3 P1 incidents during cutover — each carrying a conservatively estimated £200K-400K in remediation cost.
ACQI’s identity modules scan Active Directory, Entra ID, and cross-tenant identities in parallel. Get your complete identity map before your next consolidation. Request a demo →