Plan Identity Consolidation After an Acquisition

An acquisition places two identity environments beside each other long before either team agrees on a shared operating model. Duplicate person records surface. Group names overlap. One application accepts people from both directories, while another accepts only one. Leaders hear a request for one identity system and want speed. A solutions engineer should start narrower. Ask whose access is blocked today, where work stops, and during which approval journey.

Start from an access journey rather than a migration diagram. Request one population, one destination, and one work outcome. A useful answer sounds like this: contractors from an acquired company need controlled entry to a shared development environment for a scheduled code review. “Everyone needs one login” offers no workable boundary. Such a request bundles identity records, worker status, application ownership, policy choices, and change planning into one large demand.

Name both identity owners early. One owner often manages source records for an acquiring organization. Another manages records for an acquired organization. Neither person receives an implied mandate during a sales discussion. Ask each owner which fields establish a person record, which fields arrive late, and who approves corrections. Listen for differing definitions of active worker, contractor, manager, and end date. Those definitions shape access review work before any system selection enters discussion.

Ask an application team how access arrives today. Some teams receive groups from an identity source. Others use local roles. Some rely on a person who reviews requests through email. Do not treat those paths as interchangeable. A review group needs answers for requester, eligibility reviewer, approval owner, and evidence reviewer. Write every response as an observed fact. Mark unknown details as unknown instead of filling gaps through an assumption.

In a fictional software acquisition, Nora, a solutions engineer, meets Priya from identity operations, Elias from an acquired company, and Morgan from a shared development environment. Priya says, “Our directory lacks records for several contractors.” Elias replies, “Our records show end dates, though extensions sometimes arrive after project work begins.” Morgan adds, “My team needs eight named people for a code review next month.” Nora does not offer a full consolidation plan. She asks Morgan for eight names, expected review dates, and each person’s needed activity.

Nora asks Priya and Elias to compare source fields for those eight fictional people. The group finds one record without a manager and two records carrying end dates before a planned review. Those findings do not prove a product problem. They point toward a data review. Priya agrees to verify manager assignments. Elias agrees to confirm current engagements through an authorized internal contact. Morgan agrees not to grant standing access while open checks exist.

Use words which hold pilot scope steady. Nora says, “Let us examine access for this named review group, then hold a decision meeting after evidence arrives.” Avoid a promise to merge both environments through a pilot. A small review tests a workflow. A small review does not quietly become an enterprise architecture commitment. State exclusions with equal care. Payroll records, organization wide application roles, and long term directory retirement stay outside this review unless customer owners add them later.

Define success through observable evidence chosen by customer owners. Morgan wants every approved person in a fictional review group to reach a shared environment before a review date, with a record naming each approval owner. Priya wants no open source conflict among approved people. Elias wants an owner named for every rejected record. Those measures describe activity and evidence. They do not predict security outcomes, integration speed, or future migration results.

Timing needs equal attention. Ask when a code review begins, when an approver expects availability, and when a rejected request needs a response. A date without an owner has little value. In Nora’s fictional meeting, Morgan sets a code review for the fourteenth. Priya offers source review by the ninth. Elias plans confirmation by the eleventh. The group reserves the twelfth for a decision meeting. Each date connects a named task with a next decision.

Ask who reviews evidence after access arrives. Without an evidence reviewer, a pilot might appear complete once a person enters an application. Morgan volunteers a team administrator to compare approved names against active access after a review. Priya requests a copy of every mismatch so identity operations knows whether a source record or application assignment needs attention. This review turns vague concern into a limited learning loop.

Treat exceptions as useful information. A contractor with an expired record might need a corrected source record, a different approved path, or exclusion from a current review. The engineer should not choose among those paths. Ask customer owners which path fits their policy and operating process. Record decision owner, supporting evidence, and scope. A choice affecting one named person differs from a choice affecting an entire population.

Be precise around employment, legal, and integration issues. Identity data often reflects decisions outside an engineering discussion. Do not present a technical setting as a resolution for worker classification, acquisition terms, or an internal authority dispute. When one issue surfaces, name a dependency plainly. Ask customer owners who should resolve a question and whether an access review pauses or proceeds for unaffected people.

A focused conversation protects against premature claims. When a buyer says, “We need one identity system now,” Nora replies, “Which access journey creates your nearest operational problem, and which disruption do you most want avoided?” The buyer answers, “Our shared code review needs a controlled path before two teams begin work.” Nora now has an immediate workflow, a relevant stakeholder group, and a sound reason to defer a larger architecture request.

Prepare a brief working record after every meeting. Include population, application, purpose, source owners, approval owner, evidence reviewer, open data questions, and next decision date. Keep observations separate from proposals. “Two contractor records show earlier end dates” is an observation. “Review those records before access” is a proposal. This separation lets customer owners correct facts without feeling pushed toward a solution.

For practice, use Nora’s fictional eight person code review. Take an engineer role and ask Priya, Elias, and Morgan one question at a time. Establish which people need access and why. Identify each source record. Ask who approves, who checks evidence, and when a group decides whether broader scope deserves discussion. Leave a complete migration map offscreen until those answers exist.

Finish with a message for this fictional team: “Morgan, send eight review names and dates today. Priya and Elias, confirm source record questions by the eleventh. We meet on the twelfth to review approvals and access evidence, then decide whether another application belongs in scope.”