Enterprise IT Consolidation After M&A
Enterprise Migration · IAM · IT Operations
Supported consolidation across identity, Google Workspace, SaaS applications, internal tools, access and migration validation when two companies' technology environments became one.
The problem
Following a merger or acquisition, two organizations can have completely different identity platforms, collaboration tools, SaaS applications, user accounts, groups, permissions and operating processes — and the people in both still need to work on Monday.
I have supported multiple consolidation initiatives where these environments needed to be analyzed, migrated, standardized and validated while normal business operations continued. The environments below are generic — Company A, Company B, a target environment — because the real ones are confidential.
The approach
Treat consolidation as a sequence of verifiable states rather than a single migration event: discover both environments, map identities one-to-one, migrate collaboration data, consolidate overlapping applications and internal tools, recreate access and the SSO path, validate per person, then clean up legacy access under approval.
My contribution sits on the operational and identity side of that sequence — mapping, migration support, access consolidation, troubleshooting and post-migration validation. Program ownership and target-platform selection sat with broader integration leadership; this page is careful to present the former, not the latter.
My role — Hands-on IT operations, IAM and SaaS administration across multiple initiatives — user and access mapping, account migration, application consolidation, permissions validation, troubleshooting and post-migration verification. Program ownership and target-platform selection sat elsewhere.
How it works
Workflow A — The consolidation pipeline
Two environments become one, in seven stages. Select a stage: each movement is a real consolidation step, not decoration. Company A and Company B are placeholders.
Swipe or scroll to explore the full diagram →
01Discovery & inventory
Before anything moves, both environments are reviewed: who the users are, which applications and groups exist, how access is granted, which domains and collaboration platforms are in play, and what depends on what.
Select any node in the diagram to inspect it.
- Connected system
- Internal layer
- This project
- Success
- Info
- Pending
Workflow B — Identity mapping
Two source identities, one target directory. Dummy identities only — alex@example-a.com is illustrative; no real employee data appears.
Swipe or scroll to explore the full diagram →
01Existing user check
Does this person already exist in the target? Matching on work email and employee attributes decides whether an identity is reused or created.
Select any node in the diagram to inspect it.
- Connected system
- Internal layer
- This project
- Info
- Success
Workflow C — Application & internal-tool consolidation
Overlapping SaaS and internal tools become one standardized set. App A–E are placeholders; the target platform is an organizational decision I supported, not made.
Swipe or scroll to explore the full diagram →
01Inventory overlapping tools
Both organizations bring their own SaaS applications and internal tools. The first job is a shared inventory: what exists, who owns it, who depends on it, and where the two overlap.
Select any node in the diagram to inspect it.
- Connected system
- Internal layer
- This project
- Info
- Pending
- Success
Workflow D — Access & SSO consolidation
Moving the account is only part of the migration. Groups, roles, application assignments and the authentication path have to arrive too — and be tested.
Swipe or scroll to explore the full diagram →
01Map groups & roles
Source groups and roles are translated into their target equivalents so access can be granted by role, not rebuilt by hand per person.
Select any node in the diagram to inspect it.
- Connected system
- Internal layer
- This project
- Pending
- Info
- Success
Example output
Post-migration validation — one user, illustrative
Migration is not complete because data has moved.
- Identity
- Target account exists — alex@example.com
- Authentication / SSO
- Signs in through the target identity provider; MFA enrolled
- Mail present and routing to the target address
- Files
- Migrated content located by the user
- Groups
- Membership recreated from the mapping
- Applications
- One assignment recreated manually with the owner
- Permissions / ownership
- Shared-resource ownership under review
- Open issues
- Tracked with the user until resolved
Illustrative checklist for one dummy user. Real validation runs per person and per system; outcomes vary by initiative and are never summarized here as a percentage.
Architecture
Two environments, one target
The sanitized shape of a consolidation: two source estates, the workstreams between, and the standardized environment they become. Generic by design.
Swipe or scroll to explore the full diagram →
- Connected system
- Internal layer
- This project
- Connected system
- Internal layer
- This project
This diagram describes the shape of the work, not any specific organization. Program ownership and target-platform selection sat with broader integration leadership; my contribution was the hands-on operational and identity work between the two source estates and the validated target — mapping, migration support, access consolidation, troubleshooting and post-migration verification.
My contribution
My role in these initiatives has primarily been on the operational and identity side of consolidation — hands-on work across multiple initiatives, not ownership of the overall integration program.
Identity & access
- User and account mapping
- Access validation
- Group membership
- Application assignment
- SSO troubleshooting
- Lifecycle alignment
Workspace & collaboration
- Google Workspace migration support
- User migration
- Email and data validation
- Groups and shared resources
- Permissions and ownership review
SaaS & internal tools
- User transition between platforms
- Access consolidation
- Internal-tool migration support
- Application-owner coordination
- Post-migration troubleshooting
Operations
- Migration validation
- User support
- Issue resolution
- Documentation
- Post-cutover support
Key engineering decisions
- M&A integration
- Identity consolidation
- SaaS migration
- Google Workspace
- Access management
- Application consolidation
- User migration
- Post-migration validation
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- Every company, domain, application and identity on this page is a placeholder: Company A, Company B, App A–E, alex@example.com. No acquired-company names, internal domains, migration volumes or timelines appear, by design.
- This is hands-on contribution across multiple consolidation initiatives — identity, Workspace, SaaS, internal tools, access and validation — not ownership of a merger integration program. Target-platform and tool-selection decisions were organizational; I supported the transition toward them.
- Initiatives differed: not every one used the same discovery tooling or included every data type, and automation depth varied by application. Some access was recreated manually with owners.
- No zero-data-loss, cost-saving or percentage claims are made. Validation was per user and per system; this page describes the discipline, not a statistic.
What I learned
Consolidation succeeds or fails at the level of one person trying to sign in on Monday. The program view says 'migrated'; the operational view asks whether that person can authenticate, find their files, reach their applications in the right role — and who fixes it when they can't. That second view is where I worked.
Project status
Hands-on IT operations, IAM and SaaS-administration contribution to post-merger technology consolidation initiatives, presented fully sanitized: generic company, application and identity names only, and no volumes, dates or outcome metrics.