There are three options, and each fits a different situation.
When acquired companies run different CRMs and ERPs, there are three choices for each system: leave it alone, connect it to the platform company’s systems, or consolidate it onto a single platform. The right answer can differ by system and by company. A group might consolidate finance onto one ERP while leaving each business on its existing CRM, connected for shared reporting.
Leaving a system alone fits when the acquired business runs well on it, shares few customers or products with the rest of the group, and needs little more than financial results rolled up. Connecting fits when the group needs shared customer records, cross-selling, or consolidated reporting now, but the target platform is not yet settled or ready.
Consolidating fits when the businesses do substantially the same work, the target system is proven in the platform company, and the processes are standard enough to share. It produces the least complexity over the long run, but it asks the most of the people involved. The question is less which option is best in general and more which fits each business at its current stage.
Forcing every company onto one system too early has real costs.
Consolidating systems right after close is tempting, because one ERP and one CRM look simpler on a diagram. In practice, an early migration asks the acquired company to change its tools, its processes, and often its leadership at the same moment. Staff who are already uncertain after a sale are asked to learn new software while keeping customers satisfied.
Early migrations also tend to move processes nobody has examined. The acquired business may price, schedule, or invoice differently for good reasons tied to its customers or market. Forcing its work into the platform’s configuration can break those processes, and the workarounds that follow, usually spreadsheets, erase the benefit the consolidation was meant to deliver.
There is also a sequencing problem. If the platform company’s systems are not documented or standardized, each migration copies an undefined target, and consolidating onto a moving standard means repeating work with every add-on. It is usually better to settle and document the standard first and to connect the acquired systems in the meantime.
Integrate first to get shared records and reporting while the larger decision is made.
Connecting systems gives the group much of what it needs early without asking the acquired business to change how it works. Integration can share customer and product records, pass orders or invoices to group finance, and feed a reporting layer that combines results. Each business keeps working in the tools its people know while the group gains visibility.
Start with the flows that matter most to the thesis: financial results for consolidated reporting, shared customer records if cross-selling is part of the plan, and orders or jobs if work moves between companies. For each flow, decide which system is authoritative for each record, map identifiers between them, and make failures visible so someone can fix them.
Integration is not wasted if the group later consolidates. The mapping tables, cleaned records, and documented definitions it produces are exactly what a later migration needs. Connecting first often turns a risky migration into a smaller step, because the data has already been reconciled and the differences between the businesses are already understood.
Choose the target system based on process fit, not on which company is larger.
When consolidation is the goal, choose the target system deliberately rather than inheriting it by default from the platform company. Compare the candidates on how well they support the group’s standard processes, how they handle more entities and locations, their integration options, their licensing terms as the group grows, and the depth of support available for them.
Involve the people who run the processes. Finance should weigh in on the ERP’s handling of multiple entities, intercompany transactions, and consolidation. Sales and service leaders should weigh in on the CRM’s account structure and pipeline stages. A target chosen only by the fund or by IT tends to meet resistance that shows up as low adoption after migration.
Sometimes neither incumbent is the right target, and the group is better served by a new platform or by a packaged system extended with custom workflows where the business is distinctive. Write the decision down with its reasons and assumptions, so later add-ons are measured against the same criteria instead of reopening the debate each time.
Migrate one company at a time and run both systems until the numbers match.
Once the target is set, move companies one at a time rather than all at once. Start with a business whose processes are closest to the standard, so the first migration tests the approach without the hardest exceptions. Each migration then improves the data mapping templates, training material, and cutover checklist for the next one.
Run the old and new systems in parallel through a full financial close. Compare balances, open orders, receivables, and key reports between them, and keep the old system available in read-only mode until every difference is explained. Parallel running takes effort, but it is how problems surface while they are still inexpensive to fix.
Baybloom Software builds integrations and migrations between CRMs, ERPs, and the systems around them. Whatever the approach, the durable pattern is the same: connect first for shared records and reporting, settle the standard deliberately, and consolidate one company at a time with evidence that the numbers match before the old system is retired.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project