Guide · CRM & customer operations
Which CRM Automations Should You Rebuild After a Move?
Sort old workflows by the job they perform, then decide which to rebuild, simplify, pause, or retire.
The automation list in an old CRM can read like a history of the business. There's a follow-up sequence for an offer you stopped selling, a workaround for an old form, and a workflow named "Final v3 copy." Rebuilding every one of them would preserve the history. It might also preserve the problems.
Ask what each workflow is supposed to accomplish
Take one automation and describe it without referring to its buttons or blocks. "When a new service request arrives, assign a coordinator and create a callback task" gives you something to rebuild. "It runs the blue workflow" doesn't.
Identify the trigger, the information it reads, the action it takes, and the person who notices if it fails. Ask the team whether that job still needs doing. Some automations remain valuable even if their implementation is awkward. Others were temporary fixes that outlived the problem.
Keep a copy of the existing configuration where your tools allow it. Your simplified description should explain the purpose, but the original may contain a condition or exception that matters during rebuilding. You want both the intended behavior and evidence of the actual behavior.
Put the workflows into four groups
Rebuild the ones that support current, understood work. Simplify the ones whose purpose still matters but whose steps include obsolete branches or duplicate tools. Pause anything with an unclear owner or unresolved dependency. Retire workflows for work the business no longer does, after checking that nobody still relies on them.
For a hypothetical cleaning company, an inquiry-to-callback workflow may be essential. A five-email promotion for a discontinued service may not be. A reminder tied to an old calendar could need a new design rather than a block-for-block copy. These decisions should come from the operating team, not just the person handling the transfer.
Rebuild one complete path
Start with a workflow whose inputs and result you can observe. Map its trigger to the destination system, confirm the required fields, and test the happy path using test data. Then test the conditions that should prevent it from running.
Check ownership and timing explicitly. Who gets the task if the original owner no longer exists? What happens if the request arrives outside working hours? Does a later edit trigger the workflow again? A visually similar automation may behave differently because the destination handles events and updates differently.
Keep external actions controlled during testing. Sending a real reminder is a different test from confirming that the reminder was prepared. Use the provider's supported test approach and a small, known audience when you reach that stage.
Give the rebuilt workflow an operating note
A short note should name its purpose, owner, dependencies, test cases, and the place to inspect failures. Include how to pause it and what happens to work already queued. The person covering for the owner should be able to find those answers without rebuilding your reasoning.
After the team has used the new workflow, ask whether it still earns its place. Maybe a clear task and a saved view solve the job with less maintenance. Maybe the automation is essential. Either conclusion is useful when it comes from observing the work rather than counting how many workflows survived the migration.