Choose an open-source CRM by evaluating the application and the operating responsibility together. Confirm the supported release, deployment path, update owner and recovery process, then test whether your records can be moved in a usable form. Access to source code is valuable, but it does not replace a maintainable installation or a demonstrated exit route.
A shortlist should answer who keeps the CRM working after the first screen appears. That includes dependencies, security updates, backups, integrations and changes to the customer workflow. Compare managed and self-operated arrangements through those responsibilities rather than assuming one licence model settles the whole decision.
This guide uses Frappe CRM and its framework installation documentation as a concrete example. Its original deployment-and-exit dossier produces a reviewable decision about ownership, recoverability and data portability without requiring a change to a live customer system.
What exactly are you proposing to run?
Frappe CRM is built on the Frappe Framework. The project repository identifies the framework underneath the application. Record both the CRM release and its compatible framework version. A deployment note that says only “latest” cannot explain which combination was selected or how a later update changes it.
The repository marks its develop branch as unstable. Inspect the compatibility table and select the appropriate supported release for the intended use. Keep experimental evaluation separate from a production proposal. Record the branch, image or package reference actually reviewed rather than copying a setup command whose target may move later.
The Frappe installation guide lists macOS and Debian or Ubuntu as officially supported distributions. The framework installation guide supplies operating-system context. The installation guide’s dependency requirements differ between Frappe release families. Compare the prerequisites for the selected release family; do not combine a command from one version with dependency assumptions from another.
The guide provides bench version as an installation check. Retain installation and version evidence in the dossier. This is a reproducibility check, not proof that the application is ready for your users. The operating proposal still needs access, updates, recovery and support responsibilities.
| Responsibility | Decision to record | Evidence to request |
|---|---|---|
| Release selection | Application and compatible framework | Exact selected versions and compatibility reference |
| Hosting | Who operates each service? | Environment and responsibility diagram |
| Updates | Who reviews and installs changes? | Test procedure and recovery route |
| Backups | What is included and who checks recovery? | Isolated restore demonstration |
| Integrations | Who maintains each connection? | Mapping, credentials owner and failure handling |
| Exit | What records and files must move? | A tested, usable sample extraction and reconciliation |
Does the CRM fit the actual sales work?
Frappe CRM’s lead and deal page brings together activities, comments, notes and tasks. Frappe CRM documents a drag-and-drop Kanban view for leads and deals. These are useful documented features to evaluate through one specific opportunity. Create a fictional enquiry, assign its next action and inspect whether another colleague can understand the current state without reconstructing it from separate notes.
Frappe CRM custom views can use filters, sorting and selected columns. Ask for a view that answers a real working question, such as which fictional deals lack a next action. Record its filters and included columns. A flexible view is valuable when its definition is understandable and maintained; the existence of a configuration screen is not the acceptance evidence.
The Frappe CRM repository documents an ERPNext integration extending into invoicing and accounting. Treat an integration as another owned component. Demonstrate the proposed handoff with linked fictional references and inspect failure handling. Do not infer that installing the CRM also configures the operational system, resolves shared-field ownership or supplies every connection your business needs.
Keep application fit and deployment fit in the same decision record. A strong sales interface may still require operating work the organisation has not assigned. Conversely, an easy installation does not establish that the chosen workflow suits the people using it.
Who maintains the installation after launch?
Map the components in the proposed environment and assign an owner to each. Include the application, framework, database, background jobs, certificates and any external integration. Record where alerts and support requests go and who can approve a configuration change.
Frappe’s installation guide describes cron jobs for certificate renewal and scheduled backups. A scheduled backup job is a starting mechanism, not evidence of a successful recovery. Specify the records, files and configuration that recovery needs. Demonstrate restoring an approved fictional fixture into a separate environment, then inspect the application and relationships there.
Define an update review using the selected version’s release material. Test the changed application against your working enquiry and access cases before any later production rollout. Keep the old and new configuration evidence with a practical recovery plan. A copied archive that has never been opened by the application leaves an important question unanswered.
How should you evaluate data portability?
Write the exit requirement before asking for an export. Name the records that matter: customers, contacts, opportunities, activities, attachments, ownership and custom fields. State which relationships must remain usable outside the original screen. A spreadsheet of names alone is not equivalent to the working CRM.
Request a demonstration of the supported extraction methods in the selected installation. Record the format, field meanings, stable identifiers and any exclusions. If the proposed route needs custom work, give it a named owner and acceptance case rather than treating source-code availability as a completed migration method.
Keep the exercise synthetic. Use several connected records with one attachment and a custom field. Compare the extracted records with the fixture register and inspect how links are represented. Where a target system is part of the decision, test a small import into an isolated copy and reconcile it before considering a broader move.
Original deployment-and-exit dossier
Prepare a hypothetical company, two contacts, an opportunity, a follow-up activity and a harmless text attachment. Add a custom field identifying a fictional service category. Give every record a reference in a fixture register so both recovery and exit can be checked against the same known input.
Deployment page: Record release choices, prerequisites, services and owners. Ask a second operator to explain the environment from the page. Add any missing dependency or undocumented manual step to the dossier before calling the setup reproducible.
Working-task page: Follow the enquiry, move it through the agreed stage and locate the follow-up. Inspect the custom view and access boundary. Record what the ordinary user can see and change, with evidence from the actual test role.
Recovery page: Restore the fixture in a separate environment through the selected supported process. Open the contact, opportunity, activity and attachment. Compare relationships with the register. Record missing items and repeat only the affected checks after a correction.
Exit page: Extract the agreed records and inspect identifiers, relationships and files. Ask the intended recipient to interpret them without the original operator’s memory. Record what remains outside the extraction so the decision includes the real migration scope.
For wider planning, see business systems and hosting. To discuss an open-source CRM brief, get started with the deployment-and-exit dossier and the responsibilities you want the proposed arrangement to cover.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.