The deal closes on Friday. The service obligation does not.

The awkward Monday

Imagine a recently acquired advice firm arriving at its first group operations meeting. The acquisition is complete. The migration timetable is colourful. Nobody can yet produce one agreed list of reviews due over the coming quarter.

Legal completion and operational control are different milestones. In this example, the business belongs to the group before the group can reliably see the work it has inherited.

The FCA's October 2025 consolidation review examines acquisition governance, risk and integration. It warns that poorly managed growth can damage client service and continuity. Our practical conclusion is to put service continuity at the front of the integration plan.

Build the obligation register

Before selecting a migration date, identify what the acquired business has promised, to whom and on what terms. Connect each active service arrangement to the responsible adviser, the next expected activity and the evidence available for prior delivery.

Do not reduce this to a list of client names and fee rates. An obligation register should help an operator decide what happens next. Where terms are unclear, mark that uncertainty and give someone responsibility for resolving it.

Use a small sample of real files to test the register against underlying evidence. A successful export proves that rows moved. It does not prove the buyer understood the service represented by each row.

The FCA's separate February 2025 review of ongoing advice examined whether paid-for services were delivered, with a focus on suitability reviews. Read alongside the consolidation review, it gives the buyer two distinct tests: can the group integrate the business, and can it evidence the client service it inherits? One should not be used as a proxy for the other.

A handover record someone can use

Consider a fictional client, Case A, whose next review is approaching. The seller's export says review complete, but the file contains a meeting record and an outstanding request for information. A buyer who migrates only the status may remove the case from the queue. A buyer who treats every complete case as unfinished creates unnecessary work. The missing element is the meaning of the source status.

A usable handover entry would record: source client identifier; receiving client identifier; agreed service and evidence reference; source status and its definition; next obligation and timing basis; outstanding dependency; responsible person; and the evidence needed to close it. Where the buyer cannot substantiate a field, record unknown and name the resolution owner. Do not make a guessed value look settled because the destination requires one.

For Case A, the interim record could say meeting held, follow-up evidence outstanding, administrator to obtain the document, adviser to determine the next step once it arrives. The timing should come from the actual service arrangement and case evidence. The migration team should not manufacture a due date merely to make a dashboard sortable.

Use that entry as a rehearsal script. Ask a receiving-team member who has never seen the case to locate the evidence and explain the next action. If they need the departing firm's administrator to interpret it, record that dependency and fix the handover before relying on the migration. The test is deliberately practical: another person can continue the work without a private explanation.

Preserve distinctions during migration

Acquired firms may use the same status label differently. One team's completed review might mean the meeting happened. Another's might require the follow-up work to be finished. Mapping both to completed can erase unfinished work.

Write a translation table before merging those statuses. Keep the source status available alongside the destination value until reconciliation is finished. Where there is no clean equivalent, retain an exception rather than forcing a neat answer.

This is also a reason to preserve original evidence and its access controls. Staff investigating an inherited issue should be able to distinguish the acquired firm's record from later corrections. A migration should not rewrite the history it is meant to carry.

Rehearse the service, not just the import

Run a rehearsal around an end-to-end client journey. Can the receiving team identify the next task, find the supporting documents, contact the right person and record the result? Can it do the same when a file is incomplete?

Include the people who actually handle those cases. They can expose dependencies that a data mapping workshop misses: a mailbox monitored by one administrator, a spreadsheet explaining legacy arrangements, or a provider login attached to a departing employee.

Inventory those dependencies while the people who understand them are available. An export cannot capture an explanation that was never written down.

Set a harder completion test

Our suggested integration exit criteria are straightforward: obligations reconcile; material exceptions have owners; staff can complete representative journeys; access is appropriate; and there is a workable fallback if the destination system fails.

Make an explicit go/no-go decision for each migration wave. A material unresolved service obligation need not halt every unrelated record, but it should have an agreed route and owner before its original context disappears. Record who accepted the remaining exceptions and when they will be revisited.

Keep two scoreboards. One tracks migration tasks. The other tracks client work at risk. If the first turns green while the second worsens, the integration is progressing technically and failing operationally.

The buyer's first technology win need not be a common CRM. It may be the ability to answer one plain question across the combined business: whose promised service needs attention today?