Why merging two CRMs after an acquisition is a control question, not only a data move
CRM consolidation after a merger is a controlled migration with financial reporting, privacy and permission consequences, not a simple import of two address books. When two sales teams sit on two CRMs and the deal timeline is already running, the surviving system has to hold the pipeline, the forecast history, the customer communications and the access rules of both businesses. SuiteCRM, EspoCRM and Twenty can all serve as the surviving platform, and the choice among them should follow from how each business models accounts, opportunities, teams and record-level access, with licensing a secondary factor. The acquired business's controls matter to the acquirer's compliance program from the day the deal closes. The SEC lets management exclude a newly acquired business from its internal control assessment for a limited period, but that exclusion ends after one year and must be disclosed, so the acquirer needs to know which IT general controls govern the acquired CRM and who owns them. Program changes, access to programs and data, and computer operations are the control areas the SEC names, and a CRM that feeds revenue or forecasts falls within scope if those figures reach financial reporting. Privacy questions follow the data: if customer or prospect records include EU personal data, a non-EEA acquirer's staff who open those records remotely is a transfer under the GDPR, and that needs a documented basis before anyone logs in. For that reason, the first decision is not which product has the lower per-seat price. Map the permission model before the data model: which teams see which accounts, how territories are assigned, who can export, and which roles can change stages or owners. Ask the implementation partner to document the access matrix of both CRMs, the retention and legal hold rules, and the audit trail that will exist in the surviving system. Confirm the supported authentication methods for each candidate (SuiteCRM 8 supports LDAP and SAML, EspoCRM supports OpenID Connect and LDAP) so that the identity provider can enforce the same sign-in and removal process for both populations during transition.
Which regulatory and contractual requirements shape a merged CRM
This table maps the regulatory and contractual regimes that most often reach a CRM consolidation after a merger to what each one means for the build: access model, logging, retention and change control. Read each row against your own listing status, licensed activities and customer geography, because a regime applies to the acquirer, the target or both depending on the facts. Treat the build implications as design questions to settle with counsel and your assessor, not as proof of compliance.
| Requirement | What it means for the merged CRM build | Evidence an assessor or regulator will expect |
|---|---|---|
| SEC ICFR exclusion for an acquired business | Staff may exclude a newly acquired business from the ICFR assessment for a limited period, so decide early whether the target's CRM feeds revenue or receivables data that the acquirer's controls depend on | Documented scope decision, disclosure of the excluded business and its significance, and a dated plan to bring it into scope |
| IT general control areas (SEC Release 33-8810) | Program changes, computer operations and access to programs and data apply to CRM systems that feed financial reporting; define administrator roles, change approvals and job scheduling for the merged instance | Access review records, change tickets with approvals, backup and restore logs, and evidence that only relevant ITGCs were evaluated |
| SEC Rule 17a-4(b) record retention (broker-dealers) | Client emails, notes and communications logged in the CRM may be business communications that must be preserved for at least three years, with the first two easily accessible, so migration must not drop activity history | Retention schedule mapped to CRM objects, preserved migration reconciliation counts, and proof that archived records remain retrievable |
| FTC Safeguards Rule (16 CFR 314.4) | Encrypt customer information in transit and at rest, require MFA for anyone accessing the CRM, apply change management and log authorized user activity, so configure identity and audit logging before users are merged | Encryption configuration, MFA enforcement settings, change management records, and user activity logs retained for review |
| Annual penetration test and six-monthly vulnerability assessment (16 CFR 314.4(d)(2)) | Unless continuous monitoring is in place, schedule penetration testing and vulnerability assessments against the merged CRM, including the new integration endpoints and API users | Dated test reports, remediation tracking and retest evidence covering the consolidated environment |
| NIS2 and DORA where they apply | NIS2 requires notifying the competent authority of changes to registration details within two weeks, and DORA requires a register of ICT arrangements and tested exit strategies for critical functions, so the CRM vendor and hosting entries must be updated after the merger | Updated registration and ICT register entries, documented exit and transition plans, and records of when each change was notified |
| GDPR Article 28 instructions and transfers | If a non-EEA acquirer's staff can view EU personal data in the merged CRM, remote access counts as a transfer, so access must rest on a Chapter V transfer tool and documented processor instructions | Records of processing updated for the merged entity, transfer assessments, role-based access lists by country, and written instructions to the processor |
| HIPAA business associate terms (45 CFR 164.314(a)) | CRM records that hold patient or referral data make the CRM host and any support provider business associates, requiring Security Rule compliance, subcontractor flow-down and incident reporting terms in the contract | Executed business associate agreements covering the merged hosting and support chain, and subcontractor lists |
| PCI DSS scope where payment data appears | Card data or payment references stored in CRM notes or quotes can bring the CRM into PCI scope, so the merged design should keep card data out of CRM fields and confirm scope with the payment brands or acquirer | Scope statement agreed with the acquirer or assessor, data discovery results, and the validation documents the relevant payment brand requires |
What data and systems move in a sales CRM merger
The objects that matter in a merger are accounts, contacts, opportunities, activities, email and calendar history, attachments, territories, owners, teams and custom fields from both organizations. Each one needs a named source, a target and a rule for what happens when the two records disagree. Duplicates usually come from the same company existing under two spellings, a parent and a subsidiary both holding contacts, or one person who bought from both businesses. Conflicting ownership arises when two reps hold an open opportunity on the same account, or when territory assignments overlap after the sales teams are combined. Confirm with each sales leader which owner wins for every shared account before the first import runs, and record that decision so it can be defended later.
Activity history deserves more care than most teams give it. Logged calls, meetings, emails and notes are often the only evidence of what was communicated to a customer and when, so they may be subject to records retention obligations that apply to the business, not only to the CRM. Regulated firms should confirm with their compliance function which retention rules govern these records before deleting or merging anything. Integrations are the second risk. ERP invoices, billing subscriptions, telephony logs and marketing lists usually reference CRM identifiers such as record IDs or account numbers. If those IDs change during the merge, downstream links break silently, so keep a crosswalk table that maps old IDs to new ones and test one billing and one telephony record end to end before cutover.
The target's data may also carry a different consent and privacy basis from the acquirer's. Marketing opt-ins collected under one privacy notice may not cover email to contacts who came from the other company, and some records may have been gathered for a purpose the combined business no longer pursues. Ask for the legal basis or consent evidence recorded for each marketing-related field, and map those fields explicitly in the import specification, with a rule for records that lack evidence. Where the target sits in another jurisdiction, confirm with counsel whether transferring or granting access to its contact data needs a documented legal mechanism before the data moves. Mapping consent and privacy fields first prevents the merged CRM from quietly inheriting obligations nobody has reviewed.
Which open source CRM fits a post-merger consolidation
Consolidating two sales organizations onto one CRM forces trade-offs between migration effort, licensing, identity integration and extensibility. The cards below compare SuiteCRM, EspoCRM and Twenty on the points that tend to decide a merger, along with when an ERP-embedded or partner-built CRM is the better route.
SuiteCRM: migration path and support timing
SuiteCRM 7 and SuiteCRM 8 are different products. Moving from 7 to 8 is documented as a migration into a new environment, not an in-place upgrade, so a merger that already runs 7 should plan a full data move, staging tests and a review of customizations, since the migration may remove non-core files under the public/legacy folder. SuiteCRM 7.15 is an extended support release with security fixes until January 2028, and no SuiteCRM 8 extended support release had been nominated at the time of writing. Confirm which 8.x minor line matches your PHP and database versions before you commit.
EspoCRM: scripting, workflows and the Advanced Pack
EspoCRM handles merger logic with Formula Script in before-save scripts, API hooks, workflows and BPM. Reports, Business Process Management and workflows come from the Advanced Pack, which is included in all EspoCRM Cloud plans, so confirm whether a self-hosted deployment needs it licensed separately. Identity consolidation is well covered: OpenID Connect sign-in supports user creation on first login and mapping of identity provider groups to teams, though EspoCRM's own 2FA is not compatible with OIDC. For integrations, HMAC is the strongest API authentication option, and basic authentication is not recommended.
Twenty: open core and feature checks
Twenty describes itself as an open alternative to Salesforce and is mostly licensed under AGPL-3.0. Files marked as Enterprise sit under a commercial license, so the features your merger depends on, such as advanced permissions, audit or certain integrations, may fall on either side of that line. Read the license for each module you plan to use and get written confirmation from the vendor about which capabilities are included in the self-hosted build. Its data model and interface suit teams that want a modern front end, but validate the import and deduplication tooling against your own account volumes before selecting it.
ERP-embedded or partner-built CRM
If the merged company already runs Odoo or ERPNext for finance and operations, a CRM module inside that ERP can keep quotes, orders and invoices in one database, which reduces integration work after the merger. Odoo Enterprise adds features such as Studio customization and version upgrades, while Odoo Community is the LGPL-3.0 core, so compare licensing before choosing. A partner-built CRM on SuiteCRM or EspoCRM is also an option when pipelines are highly specific. Either path shifts cost toward configuration and integration work, so ask any partner for a written scope covering deduplication, field mapping, permission changes and parallel-run support.
Rollout phases for a merged CRM, with the output of each phase
The sequence moves two sales organizations onto one self-hosted CRM in controlled stages, with a named output at each gate so that legal, sales operations and security can confirm the merged system is complete before the retired CRM is switched off.
Inventory both systems and legal hold needs
Document each CRM's version, hosting location, custom objects, fields, workflows, integrations, user counts and permission model. Legal counsel identifies records under litigation hold, regulatory retention or contractual obligations, and privacy staff flags personal data subject to access or erasure requests. The work is led by the platform owner of the acquiring company with input from both sales operations teams. It is done when the inventory has been signed off by both sales operations leads and counsel has confirmed which records must be preserved in their current form. Output: a system inventory and a legal hold register.
Choose the surviving system and data model
Decide which CRM and which configuration will survive, based on fit with the pipeline stages, territory logic and integrations that the combined sales organization needs. Document where each object and field from the retired system will land, including fields that will be merged, renamed or retired. Confirm the choice with the product, finance and security owners before any data moves. Output: a signed field-level mapping that lists source field, target field, transformation rule and owner for every object in scope.
Define deduplication rules and run trial imports
Agree match keys for accounts, contacts and leads, such as normalized domain, tax identifier and email, and define survivorship rules that decide which record's values win when two records conflict. Build the import in a staging copy of the surviving CRM, then run trial imports and review sample records by hand with both sales teams. Repeat the trial until the error rate and merge decisions are accepted. Output: a deduplication log showing match counts, merge decisions, exceptions and the rule version used for each run.
Redesign permissions and territories
Map each legacy role, team and sharing rule to the surviving system, then redesign territory assignments for the combined organization. Confirm which users keep access to records from the other organization, and remove access that the merger does not justify. Connect identity sign-in through the organization's identity provider where the chosen CRM supports it, and confirm how logout and deprovisioning behave. The step is complete when the access matrix has been reviewed by the business owners and the security team. Output: an access review with approvals for every role and territory.
Run both systems in parallel and reconcile
Keep the retired CRM live for reference while sales teams work in the surviving system, and sync or re-import changes made during the transition period according to an agreed method. Compare record counts, open opportunity values, stage totals and owner assignments between the two systems on a regular schedule. Investigate every difference and record the cause. Output: a reconciliation report that states each difference, its root cause, and whether it has been corrected or accepted.
Cut over and record the decision
Freeze edits in the retired system, run the final delta load, and confirm that the surviving system holds the agreed record set. Switch integrations, email capture, telephony and reporting to the new system and test each one with real users. Sales leadership and the platform owner sign the cutover, and the record states the time, the delta counts and any open issues with owners. Output: a signed cutover record with a list of accepted residual issues.
Decommission the retired CRM and archive
Export the retired system's data, attachments, activity history, audit logs and configuration into an archive that meets the retention and legal hold requirements confirmed in the first phase. Test that the archive can be opened and searched by someone outside the project, then disable user access and shut down the instance only after the archive has been accepted. Output: an archive manifest listing contents, checksums, storage location, retention period and the person accountable for access to it.
Questions buyers ask about CRM consolidation after a merger
What drives the cost of consolidating two sales CRMs after a merger?
The cost is driven mainly by how much data and configuration must be reconciled, not by the software license, because the open-source core is free to download and self-host. The main cost components are hosting and infrastructure in your environment, configuration of the surviving system, deduplication and data mapping work, integrations with email, calendar, ERP and telephony, permission redesign, testing, training and support after go-live. Costs rise with the number of duplicate accounts, the number of custom objects and fields in each CRM, the count of integrations and the amount of history that must be preserved. Ask any partner for a quote that lists these components separately, marks which items are one-time and which recur, and states what is excluded. If you use a hosted per-seat product, the subscription recurs by user, so the cost depends on the seat count you keep after consolidation.
How long does a CRM consolidation take and what sets the timing?
Timing depends on the number of systems involved, the volume and quality of records, and how many business processes must be reconciled before cutover. The main drivers are the readiness of the two data sets, the decision on the surviving system, the number of pipelines and custom fields that need mapping, the sign-off process for territory and permission changes, and whether both sales teams must keep working in their current system during transition. Your own environment and staffing also set the pace, so no fixed duration is reasonable without a written scope. Ask for a plan with named milestones, dependencies and the decision points where the business must sign off, and confirm which of those steps depend on your legal or finance calendar.
What does the acquirer's team need to provide before the work starts?
The acquirer's team must provide decisions and access, because a partner cannot choose the surviving system or define what a won deal means for your business. Typical inputs include the target's CRM exports or read-only access, data dictionaries, pipeline and stage definitions for each organization, the list of custom objects and fields, sales territory and account ownership rules, user lists with roles, and the integrations each CRM uses. You also need named owners for finance, sales operations, legal and security who can approve data handling, retention and access changes. Confirm early whether the target's data includes personal data of EU residents, since that affects processor terms and transfer rules, and whether any access by the acquirer's staff to the target's systems counts as a transfer under the GDPR.
Can our internal IT and sales operations staff run a CRM consolidation alone?
Internal staff can often handle parts of the work, but a consolidation usually requires skills that are scarce in a merger period: data migration, CRM configuration, integration engineering, security hardening and testing. Sales operations can usually own pipeline definitions, field decisions and owner mapping, while IT owns hosting, identity integration and backups. Work that often needs outside help includes duplicate matching across two schemas, rebuilding permissions, setting up single sign-on, and running a trial import with reconciliation reports. Decide which parts you will keep in-house and which you will contract, and ask a partner to state which tasks it will perform, which it will only review, and which need your staff. Fixed-scope contracts make the division of work explicit before anyone starts.
Does the SEC ICFR exclusion period change when we can change CRM systems?
Yes, the timing of IT changes can be shaped by internal control reporting, but the rule is set by your auditors and counsel, not by the CRM. SEC staff allow management to exclude a newly acquired business from its internal control assessment, but not beyond one year from the acquisition date and not from more than one annual report, and the exclusion and the business's significance must be disclosed. Because CRM data can feed revenue and receivables reporting, the systems and their IT general controls may still need evaluation where they support financial reporting risks. Confirm with your external auditor which CRM data flows affect reporting, and plan access, change management and logging controls for the new system before it touches those flows. Also check whether a material cybersecurity incident during the migration would trigger Form 8-K Item 1.05 obligations.
How do we keep sales history for records retention after the merger?
Keep the original exports, the migration mapping and the full activity history in a retained archive before you retire the old system, because the consolidated CRM may not carry every legacy record in the same form. Records retention obligations depend on your sector. For example, broker-dealers face the SEC Rule 17a-4(b) requirement to preserve certain business communications for not less than three years, the first two in an easily accessible place, so the archive must remain searchable for that period. Ask the partner to produce a record inventory, a reconciliation report showing counts of accounts, contacts, activities and attachments before and after import, and a retention schedule that legal approves. Test restores from the archive so you know the history can be read later.
What happens to the retired CRM after the consolidation is complete?
The retired CRM should be read-only for a defined period, then decommissioned under a written plan that covers data disposition, access removal and evidence. Before shutdown, confirm that integrations, email sync and scheduled jobs no longer write to it, revoke user and API access, take a final verified backup, and record where the archived data is stored and who may access it. Retention rules may require you to keep the database for a fixed period, so legal must decide whether the backup is kept or securely deleted. Also confirm that any vendor hosting or support contract ends on the agreed date, and that the old system's credentials, certificates and DNS records are removed. Ask the partner to include this decommissioning step in the written scope.
What to ask an implementation partner before a CRM merger project
Start by asking how the partner maps two pipelines and stage models onto one. Ask for the stage-by-stage crosswalk from each legacy system, who agreed each mapping, and how stages with different exit criteria will be handled so that forecasts from both teams stay comparable after cutover. Ask how custom fields are reconciled, including fields that exist in only one organization and fields that share a name but hold different values. Ask which fields the surviving system will require, and whether the partner will show you the mapping in a trial import before any production data moves. On deduplication, ask how account and contact matching rules are defined, which keys they use (for example, email domain, tax ID or parent account), and who signs off each merge rule and each merge that cannot be automated. Ask for the merge log and how a wrong merge is reversed. Next, ask how activity history, notes, calls, meetings and attachments are carried over, and whether the partner has tested that files are linked to the correct records and that the original timestamps and owners are preserved. For owner and territory changes, ask how reassignments are decided, who approves them, and how orphaned accounts are handled when a rep leaves. Ask how role-based permissions and record-level access are rebuilt for the combined organization, and whether the partner will provide a written list of access changes with the approver, date and reason for each, so that your team can use it as audit evidence. If your acquirer or any staff sits outside the EU, ask how the partner will prevent non-EEA staff from reaching EU personal data during setup, support and testing, and whether they will tie that access to a documented transfer tool and to your instructions as controller.
Finally, ask how the two systems will run in parallel and how they will be reconciled. Ask who owns the reconciliation, what is compared (record counts, open opportunity value, owner assignments), how often, and what threshold stops cutover. Ask for the rollback plan and for the written exit path if the surviving system later needs to be replaced. Ask the partner to name the controls they will test after cutover, including multi-factor and single sign-on settings in the identity provider, and whether they will confirm that a AUTH_TYPE setting or an OIDC group mapping gives the expected access before users are switched over. Where the source systems are SuiteCRM 7 or another release, ask whether the partner treats the move as a migration, how staging tests are run, and how customizations are reviewed. Ask for a quote built on a written scope that names each data object, each integration and each sign-off step, because the number of legacy systems, the volume of attachments and the number of approval rounds are the main drivers of effort.
Evidence the consolidation should produce for auditors and regulators
A merged sales organization on one self-hosted CRM should be able to show what moved, what was removed, who approved access changes, and how configuration changed. Each item below maps to a record that auditors, regulators or the acquirer's own control testers may ask for, and each needs a named owner and a retention decision before cutover.
Field and pipeline mapping sign-off
Before any record is imported, the source-to-target map for accounts, contacts, opportunities, stages and custom fields should be approved by named owners from both sales organizations and, where revenue reporting depends on it, finance. The signed map is the reference every later reconciliation tests against. Confirm that the approval is stored with the version of the map that was actually used, since trial imports often change field choices. Ask your implementation partner to version the map alongside the configuration repository.
Deduplication log
A deduplication log records each merge or retained duplicate, the surviving record, the discarded record and the rule or person that decided it. Without it, a later question about where an opportunity or contact went cannot be answered. Confirm whether your chosen CRM's audit log captures merges as events or whether the partner must export a separate log from the match run. Keep the discarded record identifiers so the log can be reconciled against the archive.
Source and target reconciliation
Reconciliation compares record counts, owner assignments, open pipeline value and activity totals between the legacy systems and the surviving CRM, by object and by sales team. Export reports from both sides at the same cut-off time, then document each variance and its cause. Confirm that the cut-off timestamp, time zone and currency handling are agreed in writing, because differences in these settings produce most unexplained gaps in pipeline totals.
Access and permission change records
Territory moves and new role assignments change who can see customer data, which matters for access control evidence in regulated firms. Each change should carry a request, an approver and a date, and the identity provider log should show when the matching group membership changed. Confirm whether your identity provider keeps these logs long enough for your audit period, and whether the CRM audit log records role and team changes separately from record edits.
Change management records for configuration and scripts
Merged configurations usually add custom fields, workflows, validation rules and scripts that change how records are saved. Each change should have a ticket, a reviewer who is not the author, a test result on staging and a deployment date. In EspoCRM, Formula scripts and workflows are configured in the admin interface, so the partner should export them to version control and tie each export to a ticket. Confirm how your team will review changes made directly in the admin interface.
Archive manifests for retired data
When a legacy CRM is retired, the archive manifest lists every exported file, its record counts, checksums, storage location, retention period and deletion date. This manifest is what you show when a regulator or litigation hold asks where a retired customer communication went. Confirm which retention rules apply to the legacy data in each jurisdiction and whether the archive has been tested for restore, since an archive that cannot be read does not satisfy a retention obligation.
How DeployOpen scopes and supports a CRM merger
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted CRM inside the client's own infrastructure, whether that is a cloud account, a data center or an isolated network. For a merger, the first deliverable is a written, fixed scope that names the surviving system, the source CRMs in each organization, the account and contact deduplication rules, the pipeline and custom field mapping, the activity history to be carried over, and the territory and permission changes that take effect at cutover. Each item is agreed in writing before work starts, so the acquirer and the target can see what is moved, what is archived and what is retired. Ask any partner to show how the scope covers both sales organizations, including the team that owns each territory after the change.
Delivery covers the parts of a consolidation that usually fail: the migration runs, the single sign-on and role mapping, the integrations with email, calendar, telephony and the ERP or billing system, and the transition period when both CRMs run side by side. Integrations are where a merged CRM most often exposes new attack surface, so DeployOpen can include security testing of those integrations, such as the API and webhook paths that carry account and contact data between systems, as a separate, scoped workstream. Hardening, backups and a runbook for the transition period are delivered with the platform, not left for later. Confirm with any partner which of these items is in the fixed scope and which would be a change request.
DeployOpen also prepares systems, configuration records and evidence that a compliance assessor or auditor can review, such as access role exports, change records for configuration and migration steps, and the reconciliation reports from cutover. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ongoing support, upgrades and continuous testing after go-live are available as retainers, which is useful when the combined organization still needs fixes to fields, permissions or integrations months after the merger closes. Ask for the retainer terms in writing, including who handles upgrades to the chosen CRM version and how security fixes are applied.
