The Identity Apocalypse: When Growth Breaks Everything
Let me paint you a picture. You're the sysadmin who's kept the lights on for years. Your identity infrastructure—while not perfect—works. Then the acquisitions start. First one company, then another, then a third. Suddenly you've gone from 600 employees to 2400, and every single one of those new users comes with their own completely different identity stack.
Company A runs everything through Okta with AWS backend. Company B is all Microsoft with hybrid AD. Company C has some custom LDAP setup that looks like it was built by someone who read one blog post in 2003. And your original infrastructure? Entra ID with scattered on-prem systems that never got fully migrated.
Now the CFO wants consolidated reporting across all entities. The CISO needs unified access control yesterday. And you're sitting there wondering how you'll even get a complete list of user accounts, let alone manage them properly.
If this sounds familiar, you're not alone. I've seen this exact scenario play out multiple times. The business side celebrates the growth while the IT team faces an identity crisis—literally. But here's the thing: you can fix this. It won't be easy, but it's absolutely doable.
Why Acquisitions Break Identity Infrastructure
Before we dive into solutions, let's understand why this happens so consistently. In my experience, there are three main reasons acquisitions destroy identity management.
First, due diligence focuses on financials and customers, not technical debt. The acquisition team looks at revenue streams and market share. They might check if the software licenses are transferable. But nobody asks about the LDAP schema or how provisioning workflows work. Technical integration becomes an afterthought—something to figure out "later."
Second, every company has its own identity philosophy. Some organizations are cloud-first, some are Microsoft shops, some built custom solutions because they couldn't afford enterprise tools early on. When you merge these philosophies, you get conflict at the architectural level. It's not just different tools—it's different ways of thinking about identity itself.
Third, timelines are unrealistic. Business leaders want "synergies" (read: cost savings) immediately. They don't understand that migrating identities isn't like moving furniture. You can't just pick up an Active Directory domain and plop it somewhere else. The pressure to integrate quickly leads to shortcuts that create bigger problems down the road.
And here's the kicker: this problem compounds with each acquisition. The first integration might be messy but manageable. By the third, you've got so many moving parts that nobody understands the complete picture anymore.
Mapping the Mess: Your First 30 Days
Okay, you're in the thick of it. Where do you even start? The first step is always discovery—and I mean real discovery, not just checking boxes.
You need to answer some fundamental questions: How many identity sources do you actually have? What applications are tied to each? Where are the user attributes stored? How does provisioning work in each system? What about deprovisioning? (Spoiler: it probably doesn't work consistently anywhere.)
Start with the human element. Talk to the IT teams from each acquired company. Don't just look at documentation—ask how things actually work. That custom LDAP setup Company C has? There's probably one person who understands it, and they might not even be in IT anymore. Find them. Buy them coffee. Get the tribal knowledge before it disappears.
Then map everything. I'm talking physical diagrams on whiteboards or digital maps in tools like Lucidchart. Show how users flow through each system. Where do accounts get created? How do permissions propagate? What's the source of truth for each attribute?
Here's a pro tip: look for the exceptions first. Every identity system has them—the service accounts that were created manually, the applications that bypass normal workflows, the users with special permissions granted outside the standard process. These exceptions will break your integration plans if you don't find them early.
The Technical Reality: Okta, Entra ID, Hybrid AD, and Custom LDAP
Let's break down the specific technologies mentioned in that Reddit post, because each comes with its own integration challenges.
Okta with AWS backend is actually one of the cleaner setups you'll encounter. Okta's API is well-documented, and its provisioning capabilities are solid. The challenge here is usually around custom attributes and how they map to your existing systems. Also, watch out for Okta Workflows—if the acquired company built complex automation there, you'll need to understand it before migrating.
Microsoft with hybrid AD is a different beast. You've got on-prem Active Directory syncing to Entra ID (formerly Azure AD), plus potentially other Microsoft services. The sync tool (Azure AD Connect) can be temperamental, especially when you start changing source directories. And let's not forget about Group Policy objects that might be tied to specific OUs.
That custom LDAP setup? This is where things get painful. These systems are often poorly documented, with weird schema decisions and manual processes. The good news is that LDAP is at least a standard protocol. The bad news is that nobody implemented it correctly. You'll likely find attributes being used for purposes they weren't designed for, or worse—plain text passwords because someone didn't configure hashing properly.
And Google Workspace thrown into the mix? That's usually for email and collaboration tools, which means you've got another directory to sync. Google's Directory API works well enough, but you need to handle the mapping between Google user objects and your primary identity source.
The real headache comes when these systems talk to each other—or when they don't but should. You might find that Okta is provisioning users to some apps while AD handles others, with no consistency about which is the source of truth.
Consolidation Strategies: Rip and Replace vs. Federation
Now for the million-dollar question: how do you actually fix this? You've got two main approaches, and which one you choose depends on your specific situation.
Option one is the rip-and-replace method. Pick one identity platform as your standard (usually either Okta or Entra ID) and migrate everyone to it. This gives you a clean slate and unified management. But—and this is a big but—it's incredibly disruptive. You're asking 2400 people to change how they log into everything. Applications need to be reconfigured. Workflows break. Service accounts stop working.
I've seen companies try this and fail spectacularly because they underestimated the complexity. If you go this route, you need a phased approach. Start with low-risk applications. Create parallel systems during migration. Test everything. And have rollback plans for every step.
Option two is federation with a central identity provider. Keep the existing systems running but add a layer on top that handles authentication across all of them. This is less disruptive but creates its own complexity. Now you've got another system to manage, and you still have to maintain all those legacy directories.
Personally, I prefer a hybrid approach. Use federation for immediate needs while you work on a longer-term consolidation plan. This gets you unified access control (making your CISO happy) while buying time to do the migration properly.
Here's what that looks like in practice: Implement a central identity provider that can authenticate against all your existing directories. Use just-in-time provisioning to create users in applications from whatever source directory they originate from. Then, over the next 12-18 months, migrate groups of users to your target platform in batches.
Automating the Integration: Tools and Scripts That Actually Help
You're not going to fix this manually. With 2400 users across multiple systems, automation isn't just helpful—it's mandatory.
Start with data extraction. You need to get user information out of all those systems in a consistent format. For the well-documented systems like Okta and Entra ID, use their APIs. For the custom LDAP, you might need to write some Python scripts using the ldap3 library. The goal is to get everything into a central location where you can analyze it.
This is where a tool like Apify can save you time if you need to scrape data from legacy web interfaces or extract information from systems that don't have proper APIs. Their ready-made scrapers and automation tools can handle the tedious work of data collection so you can focus on the actual integration logic.
Once you have the data, you need transformation logic. This is where you normalize attributes, handle conflicting data (like when the same user has different email formats in different systems), and create mapping rules. I usually build this in Python with Pandas for data manipulation, but you could use whatever language your team knows best.
The real magic happens with provisioning automation. You'll want to build workflows that create users in the right systems based on business rules. For example: "If user is in department X, provision accounts in these three applications from this source directory." Tools like Terraform can help here, especially for cloud resources, but you'll likely need custom code for the legacy systems.
Don't forget about deprovisioning! This is where security gaps happen. When someone leaves, you need to ensure their access is removed from every system, not just the primary directory. Build automation that triggers off HR system events and propagates terminations across all your identity sources.
Giving the CFO What They Want: Consolidated Reporting
The CFO's request for consolidated reporting isn't just bureaucratic—it's actually a great forcing function for cleaning up your identity mess. But you can't give them accurate reports until you have a single source of truth.
Start by defining what "consolidated" actually means. Is it just user counts? License utilization? Access patterns? Once you know what metrics matter, you can build the pipelines to collect them.
My approach is to create a data warehouse specifically for identity information. Extract data from all your sources on a regular schedule (daily is usually sufficient). Transform it into a consistent schema. Then build reports on top of that warehouse. This gives you a single pane of glass without having to query each system separately.
The tricky part is handling discrepancies. When your Okta count doesn't match your AD count, which one is right? You'll need reconciliation logic that identifies these differences and either automatically fixes them or flags them for manual review.
For visualization, tools like Power BI or Tableau work well. But honestly, sometimes a simple CSV export is all the CFO actually needs. Don't over-engineer this—ask what format they prefer and deliver that.
One metric that always gets attention: orphaned accounts. These are accounts that exist in applications but don't have a corresponding user in your primary directory. Finding and cleaning these up not only makes your reports more accurate but also improves security. Build automated scans that look for these orphans and either remove them or flag them for review.
Security Implications: Unified Access Control Isn't Optional
Your CISO is right to be worried. Fragmented identity systems create security gaps you can drive a truck through. When you don't have a complete picture of who has access to what, you can't properly secure anything.
The first priority should be privileged accounts. These exist in every system—administrators in AD, super users in Okta, root accounts in AWS. You need to find them all and bring them under centralized management. Consider implementing a Privileged Access Management (PAM) solution that can handle all these different systems.
Next, look at authentication strength. Are some systems still using password-only authentication while others require MFA? You need to bring everything up to your security baseline. This might mean implementing a central authentication service that enforces MFA for all applications, regardless of what the individual apps support natively.
Access reviews become exponentially harder with fragmented systems. How do you review who has access to an application when the permissions are managed in three different places? You need to create unified access review workflows that pull data from all sources and present it in a single interface.
And then there's logging. Security incidents often require tracing user activity across multiple systems. If your logs are scattered and in different formats, you'll miss critical evidence. Implement a SIEM (Security Information and Event Management) system that can ingest logs from all your identity providers and normalize them for analysis.
Remember: the goal isn't just to check compliance boxes. It's to actually reduce risk. Every identity system you consolidate is one less attack vector for bad actors to exploit.
Common Mistakes (And How to Avoid Them)
I've seen teams make the same errors over and over when trying to fix broken identity infrastructure. Here's what to watch out for.
Mistake #1: Trying to do everything at once. You can't migrate 2400 users and hundreds of applications simultaneously. You'll overwhelm your team and create so many issues that you'll have to roll back. Instead, pick a pilot group—maybe one department or one application—and get that working perfectly before scaling up.
Mistake #2: Not involving the business early enough. IT can't do this alone. You need HR for user data, department heads for access requirements, application owners for integration details. Create a cross-functional team with representatives from each acquired company.
Mistake #3: Underestimating the custom applications. Every company has them—the homegrown apps with weird authentication code. These will break in unexpected ways during migration. Test them thoroughly, and be prepared to rewrite authentication modules if necessary.
Mistake #4: Forgetting about service accounts and APIs. These non-human identities often get overlooked during migrations, then break critical processes at 2 AM. Catalog every service account, understand what they do, and migrate them with extra care.
Mistake #5: No rollback plan. Something will go wrong. When it does, you need to be able to revert changes quickly. For every migration step, document exactly how to undo it. Test the rollback process before you do the actual migration.
If you don't have the in-house expertise to handle all this, consider bringing in outside help. You can find identity management experts on Fiverr who specialize in these kinds of consolidations. Sometimes a few weeks of consulting can save you months of pain.
The Long Game: Building an Identity Strategy That Scales
Fixing your current mess is important, but you also need to prevent it from happening again. The next acquisition is always around the corner.
Start by creating an identity playbook for future integrations. Document your standard identity platform, provisioning workflows, attribute mappings, and security requirements. When you acquire another company, this playbook becomes your integration checklist.
Build flexibility into your systems. Use standard protocols like SAML and OIDC whenever possible. Avoid vendor lock-in where you can. The goal is to make it easier to onboard new systems, not harder.
Create an identity governance framework. Define who owns user data, who approves access requests, how audits work. Make these processes consistent across all business units. This is boring work, but it's what prevents chaos from returning.
Invest in monitoring. You need to know when things break—not just catastrophic failures, but subtle issues like sync delays or attribute mismatches. Build dashboards that show the health of your identity infrastructure across all systems.
And finally, educate your leadership. Make sure they understand that identity isn't just an IT problem—it's a business enabler (or disabler). When they're considering another acquisition, identity integration needs to be part of the conversation from day one, not an afterthought.
You Can Fix This
Look, I know how overwhelming this feels. Three acquisitions in 18 months would break anyone's identity infrastructure. The Okta, Entra ID, hybrid AD, and custom LDAP combination is particularly nasty. But here's what I want you to remember: you're not the first person to face this, and you won't be the last.
The path forward starts with understanding what you have. Map everything. Talk to people. Get the data into one place. Then make strategic decisions about consolidation versus federation. Automate what you can. Build in security from the beginning. And create processes that will prevent this from happening again.
It's going to take time—probably 12-18 months to do it right. There will be setbacks. Applications will break at inconvenient times. Users will complain. But with each system you consolidate, with each workflow you automate, with each report you make accurate, you're building something better than what you had before.
Your identity infrastructure might be broken today, but it doesn't have to stay that way. Start with one small piece. Get it working. Then move to the next. Before you know it, you'll have a unified identity system that actually supports the business instead of holding it back.
And when the next acquisition comes? You'll be ready.
