Replacement
Part of CRM maintenance and replacement
Comparing reconfiguration with replacing the CRM
Define the failing customer task, compare repair and replacement on one scope, and account for dependencies and continuing effort.
Compare reconfiguration and replacement against the same essential customer task. Reconfigure when supported changes can make that task reliable at an acceptable continuing effort. Assess replacement when a material requirement remains unmet or the workaround cannot reasonably be sustained. Keep the cause, evidence and uncertainty visible for either decision.
Define the failing result
Describe what a person cannot do today without prescribing a new product. For example: “After an account changes owner, the incoming person cannot find the open deal and promised response.” Check whether the cause is an incorrect relationship, recording rule, permission, screen, workflow or product limit. A broad complaint that the CRM is complicated needs this smaller diagnosis before either route can be assessed.
State what result is essential, who needs it and what happens if it fails. Include the effort spent on manual workarounds and finding exceptions. Keep optional improvements separate from the work that must function.
Compare both routes on the same task
Reconfiguration
- Essential result
- Can supported settings and a clear process produce it?
- Existing history
- Will the change preserve needed records and reporting meaning?
- Connected work
- Which integrations and rules change?
- People
- What training and administration follow?
- Continuing effort
- Who maintains the revised setup?
Replacement
- Essential result
- Can the proposed edition produce it?
- Existing history
- Which values, links and history must move or remain accessible?
- Connected work
- Which connections must be rebuilt and reconciled?
- People
- What cutover support and retraining follow?
- Continuing effort
- Who maintains the new system and any legacy access?
Use the same scope and period for internal and supplier estimates. Record unknowns rather than assigning a price to work that has not been defined. This comparison decides whether to repair or assess a switch; a later vendor shortlist and contract review answer different questions.
Give repair a bounded check
Some apparent product limits are configuration questions. HubSpot pipelines organise processes into stages, and editing pipelines or stages requires edit property settings permissions.
Pipedrive allows users with deal-admin permission to add stages. Moving deals between its pipelines affects Insights reporting, with deal-progress reports reflecting movements within the current pipeline. These features establish possibilities and dependencies, not that a particular business problem is solved.
Define one task, the ordinary user who must complete it, the expected record and a stop condition. Include an awkward case such as a transferred account with two open opportunities. If the proposed change cannot deliver the result, record the specific failure and its cause.
Include the switch effort in the decision
Replacement may require a different route for history. HubSpot's standard record export includes current property values and associations, but its default selection follows the chosen view and contact activities have separate routes. Pipedrive requires separate exports for linked activities, notes and files. Specify the relationships and history that must be usable, plus access setup, integrations, training and transition reconciliation, before judging replacement effort.
Choose reconfiguration when the bounded check establishes a viable route and the continuing work is acceptable. Choose a replacement assessment when a material gap remains and a destination can be checked against it. If a decisive requirement or effort estimate is unresolved, assign that question and hold the choice.
