Migrating from a Cloud CRM to WordPress

A CRM migration is not really a data transfer. It is an opportunity to stop carrying things you never use, disguised as a data transfer — and the projects that go badly are almost always the ones that treated it as a straight copy. You export everything, import it in whatever order the files come out, and end up with 9,000 contacts, deals attached to pipelines that do not exist, and a forecast nobody trusts.

This is the sequence that avoids that, written for a small team moving from a hosted CRM to a self-hosted one inside WordPress. It assumes you can export CSVs from the old system, which every mainstream cloud CRM allows.

Decide what you are actually bringing

Start here, before you export anything, because this decision determines the size of every subsequent step. The instinct is to bring everything on the grounds that you might need it. The result is a new system that is instantly as cluttered as the old one, except now nobody knows their way around it.

A useful frame: you are not archiving, you are moving in. The old system can stay as a read-only archive for a while — that is much cheaper than importing ten years of noise and then trying to work around it.

What is usually worth bringing:

• Companies and contacts you have had genuine contact with in roughly the last two to three years, plus every current customer regardless of date.
• Open deals only. Anything not closed, with its value, expected close date, owner and current stage.
• Custom field values that someone actually uses to make decisions.
• Notes attached to live relationships — the context that makes the next conversation possible.

What is usually not:

• Closed-lost deals from years ago. They will not be revived and they will pollute every win-rate calculation you run. If you want the statistics, keep the export file.
• Historical invoices. These live in your accounting system, which is the system of record for tax purposes anyway. Duplicating them into a CRM creates two versions of financial truth.
• Contacts with no interaction history at all — usually the residue of a list purchase or a stalled import. Bringing them is also the kind of thing that makes a retention policy hard to defend.
• Old completed tasks. Nobody has ever looked at a completed task from 2021.
• Automation and workflow definitions. These do not port, and rebuilding the three that matter is faster than auditing the twenty you inherited.

Build the destination before you import

This is the step whose omission causes the most rework, and it is worth being blunt about it: create your pipelines and stage probabilities before you import a single deal.

The reason is mechanical. A deal import maps each row to a pipeline and a stage. If the stages do not exist yet, every deal lands in whatever default it can find, and you then have to re-stage hundreds of records by hand — or re-run the import and clean up duplicates. If the stages exist but the probabilities are still at their defaults, your forecast will be wrong the moment the import finishes, and the first thing everyone does with a new CRM is look at the forecast and decide whether to trust it.

So the preparation order is:

1. Install the plugin and let it create its database. In Stillpoint that happens on first load — a single SQLite file in a protected folder inside wp-content/uploads by default, or your own MySQL database if you would rather. Nothing to provision.
2. Create your user accounts and set roles, so owners exist before anything references them.
3. Build each pipeline and its ordered stages, matching how you actually sell rather than copying the old system's labels out of habit. This is a good moment to consolidate: if the old CRM had eleven stages, five to seven is usually better.
4. Set the win probability on every stage plus the won and lost flags. Weighted forecasting is derived from these, so a stage with a placeholder number produces a placeholder forecast.
5. Create any custom fields you decided to keep, on the right entity — contact, company or deal.
6. Only now start importing.

The export and import order

Relationships point in one direction, so the import has to follow that direction or the links silently fail. Contacts reference companies. Deals reference both. Import in dependency order:

1. Companies first

Export company or account records with name, website, industry, country, region, city and phone. Deduplicate in the spreadsheet before importing, not after — company duplicates are the worst kind because contacts and deals attach to whichever copy happened to be found first, and splitting an account across two records is tedious to unwind. Sort by name and scan for near-matches: trailing "Ltd", inconsistent "&" versus "and", the same firm entered twice with different capitalisation.

2. Contacts second

Now contacts can reference companies that exist. Export name, job title, emails, phone numbers, company name, location, lead source and notes. Two things to fix in the file first: split any single "full name" column if your destination expects separate parts, and normalise the company name column so it matches the company records exactly — an approximate match is a failed link.

3. Open deals third

With pipelines, stages and owners all in place, deals import cleanly. Export name, value, currency, expected close date, owner, stage and the linked contact and company. Map each old stage to a new one explicitly — write the mapping down in a two-column table before you start, because doing it from memory row by row is how deals end up scattered.

4. Notes and activity last

If your destination supports importing notes against contacts, do it after the contacts exist. If it does not, this is a strong argument for keeping the old system readable for a period rather than trying to force it.

Field mapping and the awkward columns

Two-thirds of columns map obviously. The rest need decisions, and making them consistently is what separates a clean import from a messy one.

• Dates. Normalise to YYYY-MM-DD in the spreadsheet before importing. Ambiguous formats are the classic silent corruption: 03/04/2026 is two different days depending on which side of the Atlantic wrote it.
• Currency and amounts. Strip symbols and thousands separators so values import as numbers. If you sell in more than one currency, decide whether you are storing the original or a converted figure and be consistent, because a mixed column makes every total meaningless.
• Owners. These must match users that already exist. Deals belonging to someone who left should be reassigned in the file, not imported as orphans you will find later.
• Picklists. Old lead-source values are usually a mess of overlapping options. Consolidate to a short list before importing rather than importing the mess and promising to tidy it.
• Everything that does not fit. Use custom fields rather than concatenating things into the notes field. Notes are unqueryable; a custom field can be filtered and reported on. But apply a test first: if nobody has used the value to make a decision in the last year, drop the column instead of recreating it.

Attachments and email history, honestly

This is where migrations get oversold, so here is the realistic position: attachments and historical email are the two things that rarely transfer well between CRMs, and planning around that is better than hoping.

Attachments. Most cloud CRMs export files as a bulk archive with machine-generated names, not as records neatly linked to the contact they belong to. Re-attaching them programmatically requires a mapping file that not every vendor provides. The pragmatic approach: bulk-download everything into a dated folder on your own storage, keep the old system's export as the index, and re-attach only the documents connected to currently open deals — signed contracts, live proposals, current specifications. That is usually a few dozen files rather than thousands.

Email history. The thread is generally still in your mailbox, which is the more reliable archive anyway. Stillpoint's inbox is a per-user IMAP and SMTP connection — each person connects their own mailbox, with credentials encrypted, and it needs the PHP imap extension enabled on the server to read mail. Because it reads your actual mailbox, connecting it gives you your ongoing correspondence going forward; it is not a mechanism for backfilling a different system's stored history. Treat that history as an archive you can search in the mail client, note the important context in the deal, and move on. Trying to reconstruct three years of threads is a large amount of work for something nobody will read.

Run both systems in parallel, briefly

Do not cut over on a Friday and cancel the old subscription on the Monday. Run both for a defined period — one to two weeks is plenty for a small team — with one rule that has to be stated explicitly and enforced: the new system is the one you write to. The old one is read-only reference.

Without that rule, parallel running becomes dual data entry, everyone reverts to the interface they know, and you end up with two half-complete systems and a genuine mess. Someone has to own the switch and say so out loud.

What the parallel period is for is discovering the small things that no plan catches: the report someone runs every Monday, the field that turns out to matter, the customer whose record did not come across because their company name had a typo. Two weeks of real use surfaces those while the old system is still there to check against.

Cutover checklist

1. Every user has an account, the right role, and has actually logged in once.
2. Pipelines, stages and probabilities are final, and the team agrees on what each stage means.
3. Companies, contacts and open deals are imported, and every open deal has an owner.
4. Every open deal has one dated next action, so the pipeline is a working queue from day one.
5. Lead capture is repointed: website forms, the intake endpoint, and the WooCommerce sync if you run a store, with the historical backfill run once.
6. Email is connected for anyone who needs the inbox, and a test message has been sent and received.
7. A backup of the new database is taken and, more importantly, a restore has been tested.
8. The old system is set to read-only, with a date in the calendar for cancelling it — not before the first month-end close in the new one.
9. The archive export from step zero is stored somewhere durable that is not the laptop of whoever ran the migration.

How to verify it actually worked

"The import said success" is not verification. Four checks, in this order, catch nearly everything:

1. Record counts. Compare rows in each source file against records in the destination. An exact match is unlikely if you deduplicated deliberately, so what you are looking for is a difference you can explain. An unexplained shortfall of 340 contacts is a failed import, not a rounding error.
2. Spot-check owners and links. Open ten contacts at random and confirm the company link, the owner and the notes are right. Then open ten deals and confirm the stage, value, close date and linked contact. Ten of each takes fifteen minutes and finds systematic mapping errors immediately, because mapping errors are never limited to one row.
3. Confirm the forecast looks sane. Look at the weighted forecast and ask whether it is in the region you would have guessed before the migration. If it is wildly off, the cause is almost always stage probabilities left at defaults or a stage mapping that dumped deals into the wrong column — both easy to fix now and painful to discover in a board meeting.
4. Ask the team on day three. The people using it will find the missing thing faster than any checklist. Ask specifically: what did you look for and fail to find?

One last thing worth saying, because it is the most common regret. Resist the urge to reproduce the old system exactly. You are migrating partly because the old setup accumulated fifteen years of compromises, and faithfully recreating them means paying for the migration without collecting the benefit. Fewer stages, fewer fields, fewer contacts, and a clear rule about next actions will make the new system better than the old one on day one — which is the only reasonable justification for the work.

The install and configuration walkthrough, including the lead-capture endpoint and database hardening, is in getting started, and the features overview covers what each part of the CRM does once your data is in.