Plan Identity Consolidation After an Acquisition

An acquisition can create duplicate identities, conflicting access policies, and uncertain ownership before teams are ready to unify every system. A solutions engineer should not assume consolidation means one immediate migration. Learn which access decisions are causing the most practical friction.

Ask which population, application, or approval workflow must work across both organizations first. Then ask who owns identity data on each side and who can approve a pilot. This reveals whether the first task is data cleanup, review design, or access policy alignment.

At a fictional software acquisition, contractors from the acquired company may need limited time access to a shared development environment. The engineer can plan a bounded review with both identity owners and the application team. The customer chooses the environment and success criteria.

Do not promise that a technical control resolves employment, legal, or integration decisions. Data quality, change management, and customer policy remain material. Record the known ownership gaps before proposing a broader roadmap.

Have the buyer say, “We need one identity system now.” The engineer should ask which access journey is most urgent and what disruption the team must avoid. They should not begin with a full migration diagram.

DealSpeak can coach whether the engineer narrows the initiative to a first workflow the customer approves. Score the plan for both identity owners, a test population, evidence reviewer, and a clear date to decide next scope. Customer teams can use this record to prepare the next review with shared facts.