Migrating from Pipedrive to a Self-Hosted Twenty CRM: A Four-Phase Playbook

CRM migrations fail in predictable ways. The data arrives dirty because nobody defined what clean meant. The new system reproduces the old system's problems because nobody questioned the data model. The cutover happens on a Tuesday afternoon with no rollback plan, and three weeks later the sales team is quietly keeping a spreadsheet on the side.

None of this is a technology problem. Pipedrive exports cleanly enough, and Twenty CRM, the open-source CRM we deploy, imports cleanly enough. The failures happen in the work around the tools, which is why we run every migration through the same four phases, each closed with a client sign-off before the next one starts. This is the playbook as we actually use it.

Phase 1: Audit

Before anything is built or moved, we produce a utilization report on the current CRM. It quantifies what the system actually does for the business: which features are used daily, which are paid for and ignored, which fields are populated consistently and which decayed into noise years ago. It also catalogues every integration and automation hanging off the CRM, because those are the things that break silently during a migration.

The report exists to force an evidence-based decision. Sometimes the evidence says stay: the team uses what it pays for, the data model fits, and the dissatisfaction is really a process problem wearing a software costume. We have told clients exactly that. A migration recommended on evidence is worth doing; a migration recommended because the consultant sells migrations is not.

The audit also sets the baseline the rest of the project is measured against. Record counts, field population rates, the inventory of automations: these become the acceptance criteria for Phase 3. Without them, "the migration is complete" is an assertion. With them, it is a comparison anyone can check.

The failure mode of skipping the audit is migrating on mood. The owner is irritated by the renewal invoice, someone saw a demo, and six months of effort gets spent moving to a system that solves none of the actual problems, because nobody wrote down what the actual problems were. The audit is also where you discover the undocumented automation that the entire quoting process secretly depends on. Better to find it in week one than during cutover.

Phase 2: Implementation

The new system gets built before any legacy data touches it. We deploy a self-hosted Twenty CRM instance on infrastructure the client controls: their virtual machine, their database, their backups. Ownership is the point of the exercise, so it starts on day one, not at handover.

Then comes the part that determines whether the migration was worth doing: the data model. A rented CRM gives you contacts, organizations, and deals, and your business learns to contort itself into those shapes. Self-hosting removes the excuse. Twenty supports custom objects and custom fields, so we design the schema around the business's real sales motion. If the business sells against a publication calendar, editions become an object. If prospects are qualified by category and territory, those are first-class fields with controlled values, not free-text tags that drift into forty spellings of the same thing.

The discipline here is to model what the business does, not what the old CRM happened to record. In our engagements, the schema design session with the people who actually work the pipeline is consistently where the most value surfaces. It is usually the first time anyone has written down how a deal actually moves.

The failure mode of skipping deliberate implementation is rebuilding Pipedrive inside Twenty. Same default objects, same vestigial fields, same workarounds, now self-hosted. You have taken on the operational responsibility of running your own system and kept every limitation you were paying to escape. It is the worst of both arrangements.

Phase 3: Migration

Sanitization rules come first, written down before a single record moves. What makes a company record valid? Which duplicates merge, and which field wins when two records disagree? What happens to deals abandoned in a pipeline stage since 2022? These are business decisions, and they belong to the client. Our job is to put each question in front of them with the evidence attached, then encode the answers as rules a script can apply uniformly. Migration is the one chance to fix data quality wholesale; carry the dirt across and it becomes permanent.

With rules in place, the data is enriched and scope-filtered. Legacy records get corrected and completed against current sources, and records outside the defined scope (dead categories, out-of-territory companies, contacts with no path to revenue) are excluded deliberately rather than dragged along by default. A CRM that starts life containing only records the business intends to work is a different tool than one preloaded with archaeology.

Validation is statistical, not anecdotal. Spot-checking the five accounts everyone remembers proves nothing. We draw seeded random samples (seeded so the check is reproducible and can be re-run by anyone) and verify the sampled records field by field against the source. Linkages get particular attention, because a contact attached to the wrong company is worse than a missing contact: it looks correct.

Every change ships with a staged rollback script. Not a vague intention to restore from backup: a tested script, written before the change runs, that returns the system to its prior state. Most are never executed. The ones that are will justify all the others.

Cutover happens in a planned window the client agreed to, with the old system frozen, the delta synced, and a smoke test run before anyone is told the new system is live: log in as a real user, find a known company, advance a deal, confirm the automations fire. Then the sales team starts Monday in the new CRM. The old system stays read-only for an agreed period afterward, not as a fallback to work in but as a reference, so any dispute about a record can be settled against the source.

The failure mode of a casual Phase 3 is the trust-the-export migration: dump the CSV, map the columns, import, declare victory. The errors surface one at a time over the following months, each one spending a little of the team's trust, until someone announces the new CRM "can't be relied on," and they are right.

Phase 4: Training and handover

A self-hosted CRM the client cannot operate is not owned; it is rented from the consultant at a worse exchange rate. The engagement ends with three deliverables. An admin runbook that covers the operational realities: backups and restores, updates, user management, what to check when something looks wrong, and when to call for help. Live training for the people who will use the system and, separately, for whoever administers it, on their data rather than a demo set. And a formal ownership transfer: credentials rotated into the client's hands, access confirmed, our standing access removed unless they choose to retain a support arrangement.

The failure mode of skipping the handover is dependency. Everything works as long as the consultant answers the phone, and the client has swapped a software vendor they could leave for a person they cannot. We consider an engagement successful when the client could fire us the next day without operational consequence.

The playbook in practice

We ran this playbook first on Sprout IQ, our own publishing business, before asking any client to trust it: 8,000+ records, 117 production workflows (as of June 2026), each phase closed at its gate before the next began. The case study covers the specifics, including the ownership.

The pattern that matters is the gating. Each phase produces something the client reviews and approves: a report, a working system, a validated dataset, a completed handover. Nobody is asked to approve work they cannot see, and a problem in one phase is caught at that phase's gate instead of compounding into the next. Four phases is not ceremony. It is the difference between a migration and a gamble that exports cleanly.