How to Pause Every Automation Safely During a CRM Migration

How do you pause every automation safely during a CRM migration?

List every automation that reads from or writes to the old CRM, decide for each one whether to pause, reroute, or leave running, and switch them off in a planned order before data moves. Capture anything that arrives during the pause, then turn automations back on one at a time against the new CRM, testing each before the next.

CRM migrations rarely fail because of the data import itself. They fail because of everything connected to the CRM that nobody remembered. A form keeps sending leads to the old system. A Zapier flow keeps updating records that no longer matter. An enrichment job overwrites freshly imported data. Two weeks later, the sales team finds leads missing and nobody knows where they went.

This article is for the person running a CRM move at a small B2B company, whether from Pipedrive to HubSpot, HubSpot to Salesforce, or a spreadsheet to anything. It is a practical plan for pausing automations without losing leads.

Why do automations cause so much trouble in a CRM migration?

Because they keep running while the ground moves under them. An automation does not know a migration is happening. It will keep creating, updating, and deleting records in whatever system it points at, on its normal schedule. If that system is half-migrated, the automation writes into a mess, or into a place nobody checks anymore.

The other problem is invisibility. Many automations were set up years ago by someone who has moved on. They live in Zapier, Make, n8n, the CRM's own workflows, a form tool, an enrichment tool, and sometimes a script on someone's laptop. Nobody has a full list. During a migration, the forgotten ones do the damage.

So the first job is not technical. It is finding everything. I covered a practical way to do that in how to inventory every automation that touches your CRM.

How do you decide what to pause, reroute, or leave running?

Pause anything that writes to the CRM in bulk or on a schedule, like enrichment, scoring, and syncs. Reroute anything that captures new leads, so nothing is lost. Leave running anything that only reads data or sends notifications that do not depend on the CRM. Write the decision next to each automation.

Lead capture is the priority. Website forms, chat tools, and inbound email routes must never simply stop. Instead, point them at a temporary holding place for the migration window, like a Google Sheet, an Airtable base, or a dedicated inbox. Every lead that arrives is captured, and nothing writes into a half-moved CRM.

Bulk writers are the danger. An enrichment job or a nightly sync that runs during the import can overwrite clean data with stale values, or create duplicates faster than you can fix them. Pause these first and turn them back on last.

Read-only automations, like a dashboard that pulls numbers, can usually keep running. They might show odd numbers for a few days, so tell the team to ignore them during the window.

In what order should you switch automations off?

Switch off scheduled and bulk jobs first, then reroute lead capture to the holding place, then pause CRM-internal workflows. Only after all three are done should data start moving. This order ensures no automation writes into the old CRM after your final export, and no lead slips through the gap.

Timing matters. Plan the pause for a quiet window, ideally the end of a week, and tell the sales team exactly when it starts and ends. Reps should know that for those hours, new leads will arrive in the holding place, not the CRM, and who is watching it.

Keep a written checklist with each automation, its tool, its owner, the action taken, and the time it was done. When something goes wrong later, that checklist is the first place you will look.

How do you make sure no lead is lost during the pause?

Route every lead capture point to one holding place, assign one person to watch it during the window, and reply to urgent leads manually. After the migration, import the held leads into the new CRM in one clean batch and confirm the count matches what arrived.

The count check is simple and powerful. If forty leads arrived in the holding sheet, forty should appear in the new CRM. If the numbers differ, you know immediately rather than discovering it when a prospect complains that nobody called back.

For urgent leads, like demo requests from target accounts, do not wait for the migration to finish. Have the watcher forward them to the right rep straight away. A lead that waits two days because of an internal system change is a lead you may not get back.

How do you turn automations back on safely?

Turn them on one at a time, in reverse order of risk, against the new CRM. Start with lead capture, then simple notifications, then CRM workflows, and last the bulk jobs like enrichment and syncs. Test each one on a few records before turning on the next, and watch for duplicates and overwrites.

Testing each automation on real but low-risk records catches most problems. Submit a test form and confirm the lead lands in the right place with the right owner. Change a test deal stage and confirm the right workflow fires. Only then move on.

Be especially careful with field mapping. The new CRM almost always names fields differently, and an automation that wrote "Lead source" in the old system may now write into nothing, or into the wrong field. Check every mapped field before you trust it. A sandbox helps here, which I covered in how to sandbox a HubSpot workflow before it touches real contacts.

What usually breaks after the migration?

The usual breaks are field mappings that point to the wrong place, owner assignments that use old user IDs, duplicates from enrichment jobs that cannot match existing records, and forgotten automations still writing to the old CRM. Most of these show up in the first week, so watch closely during that time.

Owner IDs are a classic trap. An automation that assigns leads to "user 12345" in the old CRM has no idea who that is in the new one. Leads end up unassigned and invisible. Check every assignment rule before launch.

Overwrites are another. A sync that turns back on and treats the new CRM as stale can overwrite good, freshly imported data. Make sure every write-back automation respects fields people have edited. I explained the rules I use in whether an automation should overwrite a field a rep edited.

When should you shut down the old CRM completely?

Keep the old CRM in read-only mode for a few weeks after the migration, with all automations off. Use that time to confirm nothing still writes to it and that reps can find everything they need in the new system. Then export a final archive and close it down.

The read-only period is your safety net. If a rep cannot find an old email thread or a note, they can look it up. If an automation was missed and still writes to the old system, you will see new activity there and can fix it.

What should you do next?

Before any CRM migration, build a full list of automations that touch the CRM. Mark each as pause, reroute, or keep running. Set up a lead holding place and a watcher. Plan the switch-off order, migrate, then bring automations back one at a time with a test for each.

I build the automations behind lead generation, and CRM migrations are where a careful plan saves weeks of cleanup. If you are planning a move and want help mapping the automations first, reach out and let's chat.