CRM project plan: the order that stops rework.

Search for a CRM project plan and you get a list of phases in roughly this order: select the system, configure it, import the data, integrate the tools, train the team, go live.

Every phase is real. The order is wrong, and it is wrong in a way that costs you the import twice.

What is a CRM project plan?

A CRM project plan is the sequence of work that takes a company from an unconfigured system to one their team uses daily. It covers decisions about structure, the configuration that expresses those decisions, moving the data, connecting the other tools, and getting people using it.

The plans you find published are lists of phases with durations attached. What they leave out is which phases depend on which, and that is the only part that determines whether you do the work once or twice.

Why the usual order costs you the import twice

Consider the standard sequence. You configure the system, then you import the data.

That looks fine until you notice what "configure" actually contains. It contains deciding what your stages mean, which fields are required, how accounts relate to deals, and what a duplicate is. Those are decisions about the shape of a record, and they take longer than anyone plans for, because they are commercial arguments wearing technical clothes.

So in practice the import happens while those arguments are still running. The records land, the schema then changes underneath them, and now you have thousands of rows carrying values from a definition that no longer exists. The fix is another import, which lands on top of the first, which is how a company arrives at duplicate records nobody can explain.

There is a second reason to be strict about it. Merging records in HubSpot cannot be reverted. So a dedupe run after a bad import is a permanent decision made under time pressure to clean up a mess that the sequence created.

You almost certainly cannot rehearse

Worth knowing before you plan around it. A sandbox is where you would normally try a schema before committing to it, and HubSpot lists sandbox creation as an Enterprise feature across its hubs.

On Starter or Professional there is no sandbox. So the plan below assumes you are configuring in production, on the real account, which is the situation every HubSpot team below Enterprise is in and which almost no published plan acknowledges. It is also why changing things later is more expensive than it looks, and why getting the order right the first time matters more than it would at a larger company.

Five gates, in dependency order

Each gate is a condition rather than a date. Nothing behind a gate starts until the condition is true, and the reason to write it this way is that a date slips quietly while a condition either holds or does not.

1. 1.
   Definitions. Gate: two reps give the same answer

   Write what each stage means, with one binary exit test per stage that the buyer produces. Write which fields are required and at what moment. Nothing else in the project starts until two different people, asked separately, describe your middle stage the same way. This gate is the whole project. Everything after it is execution.

2. 2.
   Structure. Gate: a test deal cannot move without its fields

   Build the pipelines, the fields and the requirements in the real account. Then try to break your own rules: create a deal with the required fields empty and try to advance it. If the system lets you, the rule is decoration and gate two is not closed.

3. 3.
   Clean the source, before it moves

   Deduplicate and correct in the system you are leaving, or in the file, not in the destination. Cleaning at source is reversible because the original is still sitting there. Cleaning after the import is a merge, and merges do not come back. Decide here what a duplicate is, in writing, because the import will apply that definition thousands of times without asking.

4. 4.
   Import in two passes. Gate: pass one reconciles

   Import a sample first, a hundred records or so, and reconcile it by hand: counts, a spot check that relationships survived, one deal traced end to end. Only then run the full import. The sample pass is where you discover that activity history came out without a deal ID, which is exactly the kind of thing an export reveals only when you actually open it.

5. 5.
   Train on real records, and only now

   Training before the data lands teaches people an empty system, which they then meet again full and different. Train on their own accounts, in the real account, with the required fields already enforced, so what they learn is what they will do on Monday.

Before gate one even opens, two questions decide how long the whole thing takes: can two of your people define your middle stage the same way, and can anyone say in one sentence what a duplicate is. If either answer is no, that is the project, and the configuration is the easy part that follows.

Integrations sit outside this sequence deliberately. Connect them after gate two and before gate four, and treat each one as its own small version of the same rule: nothing that writes records goes live until you know what a record is supposed to contain.