CRM go-live: the dry run that catches what your project plan misses

Most CRM migrations are managed as a task list. Map the data, build the workflows, schedule the training, pick a launch date. The list goes green, someone declares the project done, and on the morning of the go-live the customer-facing team logs into a system nobody has actually used end to end. That is the moment the gaps show up, in production, with live customers in the records.

The issue is that a task list confirms the work got done. It does not confirm the flow works. A workflow can be built and still fire on the wrong trigger. A property can be mapped and still land in a view the rep never opens. A pipeline can be configured and still have no path from the stage a lead enters to the stage a deal closes in. None of that shows up in a status sheet. It shows up the first time a real record tries to travel the whole journey, and if the first time is your go-live, you are debugging revenue infrastructure while people are trying to sell on it.

There used to be slack in the system to absorb a rough launch. A few people would firefight the broken workflows for a week, the admin would patch things live, and the team would limp into adoption. That cushion is mostly gone. SaaStr’s 2026 GTM analysis found the median company is planning zero percent RevOps headcount growth this year, with GTM orgs running 20 to 30 percent leaner and far flatter than they were. The people who used to absorb a botched cutover do not exist on the org chart anymore.

The stakes on the other side are higher too. You do not get many shots at this. As SaaStr put it in their 2026 piece on CRM lock-in, the migration is usually “too painful to justify” doing twice, and as you wire agents and automations on top of the CRM, switching gets from annoying to “functionally impossible.” The CRM go-live is close to a one-way door. The dry run is how you make sure the door opens onto the right room.

So here is the distinction I would burn into every migration plan. There are two kinds of confirmation, and teams routinely collect the first and skip the second.

The first is task confirmation: the data is mapped, the workflows are built, the views are configured, the training deck is written. This is necessary and it is what your project plan tracks. The second is flow confirmation: a real record, starting where a real customer would start, makes it all the way through to a closed deal, and every stage, property, workflow, and view it touches on the way does what it is supposed to. Almost nobody books time for the second one. It is the cheapest insurance you can buy before a CRM go-live, and it is the step people cut when the launch date gets tight.

A dry run is not a demo and it is not UAT in a sandbox where the admin clicks through happy paths. It is a timed, end-to-end rehearsal of the full customer journey in the system you are about to launch on, run by the people who own each part of it, looking specifically for what breaks.

What I would recommend is to block two hours, put one record on the screen, and walk it from first touch to closed deal in front of the whole team. Lead comes in. Does it land in the right pipeline? Does the workflow that should fire actually fire? When the rep opens the contact, do they see the same view their teammate sees, or are there five different layouts so nobody is looking at the same data? When the deal moves a stage, does the next action get created? When it closes, does the handoff to onboarding or service trigger? You are not testing whether the pieces exist. You are testing whether the pieces connect.

The reason you do it live, together, and out loud is that the gaps live in the seams between people’s work. The person who built the lead-routing workflow and the person who built the deal stages each tested their own piece in isolation, and each piece passed. The journey crosses both, and the break is almost always at the join. You only see the join when one record travels the whole thing in one sitting.

We recently worked with a Series B B2B SaaS company in DACH moving off Salesforce onto HubSpot, with a hard go-live date and a customer-facing team that had never touched the new setup. The project plan was in good shape: data mapping scoped, workflows built, training booked.

Two things came out of insisting on a dry run before cutover. First, when we walked one record through the journey, several workflows had been built correctly in isolation but were never wired to the trigger that the actual customer journey produced, so a contact could enter and simply sit there with no next step. A status sheet would have shown those workflows as “done.” The dry run showed them as dead ends. Second, the team had not planned to migrate historical notes and activity from the old system, only open records. That sounds reasonable until you realize that on day one a rep picks up a live account, sees no history, and quietly opens the old CRM in another tab to find it. The moment your people keep the legacy system open, adoption is already lost, and you are paying for two CRMs to run one. We caught both before launch because we ran the journey, not the checklist.

1. Book the dry run as its own event, before the go-live. Two hours, the whole team, calendared as a working session, not a status call. If it is not on the calendar with a clear owner, it will get squeezed out by the launch date. Treat it as a gate the go-live has to pass, not a nice-to-have.
2. Walk one real record from first touch to closed. Pick a representative scenario and follow it the whole way: lead creation, routing, qualification, every stage, the close, and the handoff after the close. Do not jump to the interesting part. The boring transitions are where the dead ends hide.
3. Test the seams, not the pieces. At every handoff, ask whether the next thing fires: the workflow, the task, the notification, the view change, the assignment. The individual objects were already tested by whoever built them. Your job in the dry run is the connections between them.
4. Migrate history, not just open records. Decide explicitly what client history comes across: notes, past activity, prior context. If reps cannot see what happened before go-live, they will keep the old system open, and that is the single fastest way to lose adoption. If you cannot bring everything, bring enough that no rep has a reason to reopen the legacy CRM.
5. Standardize the views before launch, not after. A common, role-appropriate view so everyone sees the same data when they share a record. My rule is to change the view based on where the record is in its lifecycle, not on who is looking at it: a contact before it is a customer should look different from a contact that is a customer. Five personal layouts on day one means five people talking past each other in week one.
6. Write the documentation from the working version. Record the dry run, then build the user guide off the flow you just confirmed, with screen grabs of the real steps. Documentation written before the system is confirmed documents a system that does not exist yet.
7. Schedule the dry run early in the day, and book the fix-time after it. Assume the dry run finds gaps, because it will, and assume some of them need new workflows built. Run it in the morning so the person who has to fix things still has the afternoon. A dry run with no fix-time booked after it is just a list of problems you now know about and cannot solve before launch.

You do not need a formal program for this. You need two hours, one record, the right people in the room, and the discipline to follow the whole journey instead of the parts you are confident about. The dry run is the difference between finding your gaps in a calendared working session a week before launch and finding them in production with a customer on the line. One of those is cheap. The other one costs you the go-live and a chunk of your adoption.

If you are planning a CRM go-live and want a partner who runs the dry run before the cutover, that is the shape of work we do: scoping the migration, wiring the workflows, and rehearsing the whole customer journey before anyone has to sell on it. Read the companion piece on the CRM adoption gap that opens after launch, or see how we approach revenue operations end to end.

• SaaStr. “The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep.” SaaStr, January 2026. saastr.com
• SaaStr. “Which CRM Should You Use in 2026/2027? Follow the Agents.” SaaStr, February 2026. saastr.com