Merging Two CRMs After an Acquisition With a Regulatory Reporting Deadline

Why should the regulatory report come before the CRM consolidation?

Because the two pieces of work have different kinds of deadline. The report is due on a date nobody inside the business can move. A CRM consolidation is a migration, and a migration carries unknowns that only surface once the data is loaded: duplicates nobody knew about, fields that meant different things in each company, history that will not map cleanly. Put the report at the end of that chain and every surprise in the migration becomes a compliance risk.

The regulator does not need one CRM. It needs one consistent, reconcilable set of figures for the combined entity, with a clear line from each figure back to its source records. That can be built over two live systems far faster and with far less risk than it can be built by first moving everything into one. So the sequence we recommend is: make the report safe first, with both CRMs untouched, then consolidate on a timetable set by the business rather than by the filing date.

What is a thin canonical reporting layer, and what goes into it?

It is a small, purpose-built data store that sits beside both CRMs, reads from each, and holds only what the report needs, in one agreed shape. It is not a data warehouse programme and it does not replace either system. "Thin" is the point: every table in it exists because a reported figure depends on it, which keeps it buildable before the deadline and auditable after it.

Where the combined business already runs on Microsoft, Dataverse data can be exported continuously with Azure Synapse Link for Dataverse or Link to Microsoft Fabric; the other CRM is read through its API or scheduled exports. For organizations outside the Microsoft stack, the same layer is a PostgreSQL or SQL Server database with a small loader, built the way we build custom CRM back ends.

How do you conform customer and entity keys across two CRMs?

Neither CRM's record id can be the master key. Both are internal, both will change meaning when one system is retired, and a crosswalk keyed on one of them quietly makes that system the winner before anyone has decided. Issue a new canonical key in the reporting layer and map every source record to it.

Build the mapping on identifiers that mean the same thing in both companies, strongest first.

• Legal entities and organizations: company registration numbers, tax or VAT numbers and any other official identifier either CRM already holds. These are the anchors; everything else is supporting evidence.
• Individuals: a verified email address, then name combined with an organization that has already been matched. Keep the rule conservative, because a false merge of two people is harder to undo than a missed one.
• Group structure: parent and subsidiary relationships, with effective dates, so an account that moved between entities during the deal is reported against the right one for the right period.
• Reference data: countries, industries, product lines and statuses mapped to one agreed list, with the mapping table kept in the layer rather than in a personal spreadsheet.
• Unmatched records: kept, flagged and reported as unmatched, never dropped. An unexplained gap in the totals is worse than a visible exception list.

Who defines the reporting entity, and how do you reconcile both CRMs into it?

Your compliance team does. Solzet does not interpret regulations or advise on what a specific regulator expects, and we would be wary of any CRM partner who offered to. What we do is take the definitions your compliance team writes down - what counts as a customer for this report, which entity a relationship belongs to, which date a record is reported on - and implement each one exactly once, in the reporting layer, so both CRMs are measured by the same rule.

Reconciliation is then a routine rather than a scramble: every load compares record counts and totals per entity with the source systems, every record that failed a rule lands in an exception list with a reason, and the compliance team signs off the exceptions before the figures are used. The validation thinking is the same one we use for migrations, set out in detail in our data migration guide.

What part of a post-merger consolidation does Solzet deliver?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. In a consolidation that means the CRM side of the work: Dynamics 365 Customer Engagement (Sales, Customer Service, Field Service, Customer Insights), the Power Platform and Dataverse, custom CRM on React, Node.js, PostgreSQL and .NET, the reporting layer over the CRMs, the integrations between them and the eventual migration.

We are plain about the edges. Solzet does not implement Dynamics 365 Finance, Business Central, Dynamics NAV, Finance and Operations or any ERP. If some of the reported figures live in a finance system, we read from it and reconcile against it rather than touching it. We also do not replace your legal, audit or compliance advisers; the page you are reading describes the data engineering that lets their definitions be applied consistently across two companies.

How should duplicate customers be matched once the deadline is met?

The crosswalk built for the report already tells you which records are the same customer, which is why doing the report first is not wasted work: it is the first draft of the consolidation. Turning it into an operational merge needs stricter rules, because now records will actually be combined and users will see the result.

Match in tiers and treat each tier differently. Deterministic matches can be merged automatically; probable matches go to a review queue owned by the people who know the customers; anything weaker stays separate. In Dataverse, duplicate detection rules stop new duplicates from being created during the transition, and the built in merge handles accounts, contacts, leads and cases, but a bulk cross-system resolution belongs in staging before the load, not in the live system one pair at a time. If the goal is a unified customer profile for analytics and marketing rather than a single operational record, Dynamics 365 Customer Insights has its own unification step with deduplication and match rules.

What survivorship rules decide which value wins in a merged record?

When two records become one, every field needs a rule for which value survives, written down before the merge rather than argued about after it. "The acquirer's system wins" is not a rule; it discards the acquired company's better data wherever it had it. Decide attribute by attribute, and keep the losing values in the layer with their source so a wrong choice can be reversed.

Which of the two CRM process models should survive?

Not automatically the acquirer's, and not automatically the larger one's. The surviving model should be the one that fits how the combined business will sell and serve customers, judged on a short list: the target sales and service process, how much customization debt each system carries, which integrations the combined business must keep, licensing fit for the combined user count, and which system the reporting definitions map to most naturally.

Sometimes the honest answer is that one CRM is sound and the other should be retired into it. Sometimes both carry enough debt that the consolidation is the moment to move to a clean Dynamics 365 design, or, where per-user Microsoft licensing does not fit the combined organization, to a custom CRM that the business owns outright. The framework below is the decision rule we use.

How do you handle two sales teams that will not change process on the same day?

You do not ask them to. Sync first, migrate later. Both CRMs stay live as front ends, and a two-way synchronisation through the canonical key keeps shared customers consistent between them, so each team keeps working in the system it knows while the surviving process is designed, built and trained. Teams then move in waves, one region or product line at a time, instead of in one weekend.

• One owner per field: for every synchronised attribute, decide which system is allowed to change it. Two-way sync without field ownership produces update loops and silent overwrites.
• Sync the shared core only: accounts, contacts and ownership. Opportunities, quotes and activities usually stay in their home system until that team moves, with visibility of the other side where accounts overlap.
• An account conflict rule: when both teams are working the same customer, the territory rule decides who owns it, and the other team sees that the account is owned rather than discovering it from the customer.
• One pipeline view: combined pipeline and forecast reporting comes from the canonical layer, so leadership gets one number without either team changing tools early.
• Replay-safe integration: upsert on alternate keys, failure alerts and a scheduled reconciliation, so a sync failure shows up in a day rather than at quarter end.
• Training on the surviving process before each wave moves, not after, with the old system read-only for that team from the day they switch.

How do you retire one CRM at a time without losing history?

Retire systems one at a time, and retire each one by object rather than all at once. For each object in turn: stop new writes in the retiring system, run the final delta into the surviving CRM through the same crosswalk, repoint the integrations and the reporting layer at the survivor, and keep the retired system read-only for an agreed period before it is archived and switched off. Only then start on the next system, if the group has more than two.

The mechanics of moving the data itself - preserving original created dates, the tool choice, attachments, the load order and the validation pack that proves nothing was lost - are the same as any CRM migration and are covered step by step in our Salesforce to Dynamics 365 data migration guide, including its section on migrating during a partner transition. The reporting layer stays in place throughout, so the regulatory figures never depend on the day a system is switched off.

What if the consolidation has already stalled and the deadline is close?

Then the sequence matters even more. A stalled consolidation usually has both systems live, users entering the same customer twice and a cutover date that keeps moving. Pausing the migration long enough to stand up the reporting layer over both systems takes the deadline off the migration's critical path, and the migration can then be recovered on its own terms.

Our Dynamics 365 project rescue and takeover service covers how we take over stalled work, including stalled data migrations, from another partner or an internal team. Microsoft partners running a post-merger programme can also bring us in white-label for the data and integration work.