Open source CRM

The decisions that are hardest to reverse in a self-hosted CRM are made before the first record is imported: how accounts and contacts relate, how opportunities move through stages, who owns what, and which fields hold regulated customer data. Start by mapping your sales process to the core entities: accounts (companies or legal entities), contacts (people), leads (unqualified prospects), opportunities (deals with an amount, close date and stage), activities (calls, meetings, emails and tasks), products and owners (users, teams or territories). Each open source CRM names and joins these entities differently, and the entity list, relationship types and custom field options vary by product and version. Confirm the exact entities, custom module options and relationship types in the version you plan to deploy before you write the data model down.

Several choices should be settled and signed off by sales operations, finance and the compliance owner together. Define a unique account identifier that is independent of the company name, such as an internal customer number or a tax registration reference, so duplicates and renamed accounts do not fork your reporting. Decide whether a contact can belong to several accounts, which is common for advisers, parent and subsidiary relationships and partner staff, and whether that link is many-to-many or primary-plus-secondary. Write ownership and territory rules as data, not as convention: which role can reassign an account, how territories are assigned, and what happens to open opportunities when a rep leaves. Stage definitions need entry and exit criteria, because pipeline reports are only as reliable as the stage meaning behind them.

For regulated customer data, decide field-level access before go-live rather than retrofitting it. Identify fields such as national identifiers, bank details, health or credit information and restrict them through role or field permissions, then test those permissions with a non-administrator account. Keep sensitive values out of free-text notes and activity descriptions, which are harder to govern and often exported. Build a test set of records that covers multiple accounts per contact, reassigned owners and closed-lost deals, and check that reports, exports and API responses return only what each role should see. Ask your implementation partner to document this model as a reviewed artifact, since it becomes the basis for access reviews and migration mapping.

The migration succeeds or fails on the data model, not on the import tool. Before anything is extracted, agree a mapping sheet that pairs every source object with its target equivalent: accounts, contacts, opportunities, activities (calls, emails, meetings and tasks), attachments, and users. For each field, record the source name, the target name, the data type, and who owns the decision when the two do not line up. Pipeline stages are the usual friction point, because a stage list in Salesforce or HubSpot rarely matches the stages configured in SuiteCRM, EspoCRM or Twenty. Confirm with sales leadership how historical opportunities should be read, and keep the original stage label as a text field so reports can still explain past decisions. Confirm what each export actually contains for your edition and plan. Activity history, attachment binaries, and deleted or archived records are often exported differently or only through the API, so ask for a written inventory of what is included and what is not.

Owner and timestamp history need explicit handling. Map the source owner and creation date to the target owner and created-at fields, and preserve last-modified dates and opportunity close dates as data, not as system metadata that the new platform will overwrite on import. Deduplication should follow written matching rules, such as normalized email address plus company domain for contacts and legal name plus tax identifier where available for accounts, with a review queue for ambiguous matches rather than silent merges. Reconcile record counts per object before and after each load, and sample a set of accounts end to end, checking owners, open opportunities and the most recent activity. Plan the cutover around a test migration on a copy of production data, run in a non-production environment with the same configuration. Repeat that test until the counts and samples reconcile, then decide whether a parallel run, where both systems stay open for a defined window, is needed for users who depend on live activity sync. A parallel run doubles the number of places a record can be edited, so it should have a named system of record and an end date.

Start with evidence of experience, not promises. Ask which CRM products and versions the partner has deployed in production, and which of those were self-hosted in a regulated environment. Ask for the names of the platform modules they have configured (accounts, contacts, opportunities, pipeline stages, activity records) and whether they have built custom objects or fields on SuiteCRM, EspoCRM or Twenty specifically. Then ask how they would handle the data model: who approves new custom fields, how field-level permissions are set, and how changes are tracked so that a sales team's ad hoc field requests do not become an unreviewed schema. Confirm the current release of each candidate product on the vendor's own repository before accepting any version claim, because release numbers change often.

Next, ask how the partner runs migration rehearsals and where the environment will live. A credible answer names at least one full trial load into a non-production copy, reconciliation counts for accounts, contacts and open opportunities, and a written rollback plan. Ask who holds the administrative keys: the database credentials, the application administrator account, the hosting account and the mail relay credentials. The answer should be that your organization holds them, with named partner access that is time-bound and logged. For SSO and mail, ask how they test sign-in with your identity provider, how they test calendar and mailbox sync with real test users, and what happens to users whose accounts are disabled in the directory.

Finally, read the written scope and acceptance criteria closely, since most engagements are fixed-scope and are agreed in writing before work starts. Check that the document lists the modules in scope, the integrations, the data sources, the test cases used for acceptance, and the sign-off roles. Ask how security patches and upgrades are delivered, whether they are applied in a staging copy first, and what is included in hypercare and what moves to a separate support arrangement. Ask who answers a sales-ops change request in month six. Written answers to these questions will make a quote comparable across partners.