After a merger or acquisition, AI adoption becomes a decision about inherited work. Two companies may already have useful assistants, different data permissions and people who know how to catch their mistakes. Decide which workflows should temporarily coexist, which should move and which should retire. A shared company name or a successful account migration doesn't establish that a shared AI workflow is ready.
For an integration lead, the practical starting point is one task that both companies need to keep doing. Compare how each side completes it before choosing a common tool. Otherwise, a technically tidy consolidation can remove the local context that made the work reliable.
Find the business meaning behind the inherited workflow
Suppose Alex Morgan manages fleet operations for an equipment-rental company acquiring a regional depot. Both businesses use an approved assistant to draft a morning brief of equipment due back and rentals needing attention. A depot manager checks the brief before using it to plan the day. The assistant doesn't contact customers, change bookings or apply charges.
The acquiring company records approved extensions in its booking system. The depot records them in a separate, access-controlled extension register linked by its own booking identifiers. In the depot's current workflow, the summary preparer checks both sources. The proposed combined brief reads only the booking export.
An excavator can now appear overdue even though the depot has approved its extension. The sentence is plausible, the original due date is real and the data transfer may have completed correctly. The combined workflow is still missing a business fact.
The approved extension disappears between the two briefs
Booking plus extension register
Match the booking identifier to the approved revised return date before drafting the manager’s brief.
Booking export alone
The original date survives, but the approved extension is absent. A plausible overdue label can still be wrong.
Alex needs the depot manager to explain how an extension becomes authoritative and where that decision is recorded. The answer may require a source mapping, a change to booking practice or a narrower scope for the first combined brief. It doesn't follow that the acquired company's method should win, either. Compare both against the work the joined business must perform.
For each inherited task, establish:
- The output and its user. What does the morning brief help a depot manager decide?
- The sources and their meaning. Where are due dates, approved extensions and booking identifiers maintained?
- The action boundary. Is the assistant drafting an internal summary, or can it change a record or send a message?
- The people who make it dependable. Who checks exceptions, maintains the instructions and handles a missing record?
Keep this inventory focused on work that matters during integration. A complete catalogue of every employee's prompts can wait. Losing the person who understands the extension register cannot.
Choose what can coexist while integration proceeds
Consolidation can be a sensible destination without being the first safe step. In Microsoft's April 2026 customer account of W1M, the company formed by the London & Capital and Waverton merger had two Microsoft environments and long-standing integrations. It first enabled collaboration through a multitenant arrangement while aligning identity, governance and security, then consolidated. Business-as-usual support ran alongside the phased move. The account describes Copilot expansion after consolidation, with role-specific enablement.
This is a supplier-published company account, not a controlled comparison of integration strategies. Its useful detail is the sequence: people could collaborate before the final consolidation. It doesn't establish that every acquisition needs a single platform or that consolidation itself produces AI value.
Choose a disposition for a particular workflow, with an owner and a reason to revisit it.
| Disposition | When it makes sense | What must be explicit |
|---|---|---|
Keep separate for now | Both workflows serve their current users, but a required source or permission mapping is unresolved | Allowed users and data, support owner, and the dependency that ends the temporary arrangement |
Move to a common workflow | The receiving workflow can preserve the needed business meaning, controls and task checks | What changes for employees, how open work continues, and the evidence required before switching |
Retire one workflow | Its work is no longer needed or a checked replacement covers it | What happens to new requests, unfinished work, retained records and recovery |
For Alex, temporary coexistence could mean each depot continues its checked local brief while the team resolves the extension source. It must not mean quietly copying the extension register into a broader shared folder to make the combined assistant work. The people responsible for the information must approve its intended use and audience.
A temporary arrangement needs a concrete review trigger, such as completion of booking-identifier mapping and the extension check. “After the merger settles down” leaves the support burden and the uncertainty indefinitely in place. Equally, a target date is not evidence that an unresolved dependency has disappeared.
Check what employees can use after the move
An integration plan often describes objects being moved: accounts, mailboxes, files and groups. The employee's question is different: can I complete the task with the right context and the right authority in the receiving environment?
Microsoft's tenant-to-tenant planning guidance, updated June 2026, treats identity mapping, workload dependencies and coexistence as planning concerns. That supports checking dependencies separately. It isn't proof that every AI conversation, agent configuration or connected source will move as a usable whole.
A September 2026 Reddit discussion about Copilot chat history makes the distinction concrete. A Reddit user conducting a tenant migration said employees wanted their existing chats to appear normally in the new environment. The user could find export routes but was asking about restoring the conversations. Another Reddit user suggested they might travel with the mailbox, while explicitly saying they hadn't tried it. The questioner planned a test; the thread reported no result.
That is an unresolved experience, not evidence that a particular migration method works or fails. It is a useful acceptance question: does the employee need an archived record, or a conversation they can continue using? Confirm the actual requirement and test the supported route. Don't promise one because you can deliver the other.
Permissions deserve the same attention. Microsoft's Copilot privacy documentation, checked October 21, 2026, says organizational information is surfaced according to the user's viewing permissions, including permissions enabled through intertenant collaboration. Joining companies doesn't by itself decide who ought to see the acquired depot's information. Review intended access and actual access rather than treating the assistant as a remedy for an overbroad share.
For Alex's task, the receiving-workflow check must cover the booking identifiers, the extension source, the ordinary manager account and the destination of the generated brief. Training someone to use a new prompt doesn't repair a missing data relationship.
Test the handover against work already in progress
Use a bounded sample that represents both inherited practices, with approval for the information involved. Don't test only clean new bookings created after the move. The open rental with a locally approved extension is precisely the case a merger can strand between systems.
- Choose the receiving user's account. Run the proposed brief with the access a depot manager will actually have. An administrator's successful test doesn't establish that the manager can see the required source.
- Trace the approved extension. Find the booking, its matching extension record and the authority for the revised return date. If a match is ambiguous, the brief should expose the unresolved case for human review rather than confidently label it overdue.
- Compare the resulting work. Check both the original due date and the approved extension against the draft. Confirm that bookings aren't omitted or duplicated when identifiers change.
- Exercise the interruption. Make the extension source unavailable in a controlled test. Check that the manager can recognize the missing check and use the agreed manual process. Don't let a partial brief masquerade as a complete one.
- Hand over support. Have the receiving support person follow a reported mismatch back to its source and responsible owner. Record who can correct the booking, the source mapping and the AI instructions.
A failure should change the disposition. Alex may keep local briefs running, restrict the combined brief to bookings it can interpret, or postpone its introduction. The integration sponsor should see which dependency remains and what would clear it. A successful migration dashboard is useful evidence about the move; it cannot substitute for these task checks.
When a replacement is accepted, use the separate guide on retiring the old process without stranding open work. It distinguishes stopping new work from finishing existing cases, preserving records and maintaining a usable recovery route. Those dates need not be the same.
Tell employees which decisions have changed
After an acquisition, a request to adopt a new assistant can also raise questions about authority and continuity. Can the depot manager still approve an extension? Who owns the register now? Will the local checker remain responsible for a brief produced elsewhere?
Perceptyx's July 2026 discussion of M&A and AI adoption emphasizes uncertainty about identity, autonomy and status. It is a commercial workforce-listening perspective, rather than a test of this rental workflow. It usefully challenges an easy diagnosis: hesitation about a new tool needn't be a lack of interest in AI. Employees may be asking about a real change to their work or authority.
Alex's announcement should name the affected task, the current arrangement, the reason for any restriction and the person who can resolve a mismatch. If authority over extensions is unchanged, say so. If it is changing, explain the responsible decision and the handover. Don't ask a training session to imply an organizational decision nobody has made.
Update the company's practical AI acceptable-use rules where the permitted information, audience or action changes. Keep unresolved questions visible. It is better to tell a depot manager that cross-company extension access is still being checked than to distribute a prompt that depends on access they shouldn't grant themselves.
For the next integration meeting, bring one inherited task with its proposed disposition, unresolved dependency and ordinary-user test. That makes AI part of the company's adoption strategy through a decision about real work. It also gives both companies a fair chance to preserve what already works.
Questions about AI adoption after an acquisition
Must everyone move to the same AI assistant after a merger?
A common assistant may reduce support and administration, but it isn't an automatic requirement for every inherited workflow. Decide whether a shared arrangement can preserve the required sources, permissions, checks and ongoing work. Temporary coexistence can be reasonable while a specific dependency is resolved. Give it an owner and a review trigger so it doesn't become an unexplained permanent exception.
What should an integration lead review first?
Start with an important task that must continue across the integration, such as a depot's morning equipment-return brief. Identify what each company uses as its authoritative source, who checks the output and what the assistant is allowed to do. Then choose whether to keep, move or retire that workflow. Buying licenses or comparing prompt libraries before this review can miss the local knowledge that makes the task dependable.
Does moving company data also move AI chat history?
Don't assume that a data export or mailbox migration restores AI conversations as usable history in the receiving environment. Define whether employees need an archive, continued conversations, saved instructions or connected sources, and verify each requirement against current supported methods. Test with an approved sample in the intended account. Tell employees about any gap before they lose access to the old route.
What if the acquired company's workflow is better?
Evaluate the acquired workflow against the joined company's actual task and safeguards, just as you evaluate the acquirer's. Ask the people who run it to show its sources, exceptions and support needs. Keep useful practices when they can be supported, and test any proposed common version with both sides' cases. Ownership of the transaction isn't evidence that one company's summary or checking method is more reliable.
When can we switch off an inherited workflow?
Switch off an inherited workflow when its work is no longer required or the receiving arrangement has passed the relevant task checks, and the treatment of unfinished cases is clear. Decide separately when to stop new requests, finish open work, preserve records and end recovery support. For an equipment depot, accepting new bookings in a shared system doesn't establish what should happen to rentals still governed by an old extension record.
How do we distinguish resistance from a genuine integration problem?
Ask an employee to show the step they cannot complete or the decision they believe changed. A missing extension register, conflicting approval authority or unavailable history is a specific issue to investigate. Explain the proposed change and test the reported case before classifying the concern as resistance. Some questions will be about role or organizational choices rather than software; assign them to the person who can answer them.
