CRM migration notes

Teams sometimes change CRM while DialSplice is running, for example moving from HubSpot to HighLevel. DialSplice consumes routed events from whichever system is live and never decides which contacts belong to which CRM. Your migration plan owns the split. In-flight nurture sequences are not restarted, and the queue keeps working through the change.

How DialSplice behaves during a migration

• Routed events. A new web lead, form fill, or inbound message becomes a work item when the live CRM emits the event. If both CRMs are connected during the cutover, DialSplice takes events from each without merging or deduplicating across them.
• Dispositions and bookings. Outcomes are written back to the CRM that owns the contact record, from the same event that updated the queue.
• The repeat-lead rule. A returning contact updates the open opportunity in its own CRM. A new opportunity is created only after close or abandonment.
• Nurture sequences. Sequences already running in the old CRM continue there. DialSplice does not restart them in the new one.
• The ledger. Every read and write is logged with the connector it went through.

Steps

1. Tell your onboarding contact the migration dates and which CRM will own new contacts from which date.
2. Connect the new CRM. Its credentials are configured server-side and the connector goes through discovery, build, and activation.
3. Activate a configuration revision that sets the new CRM as the source of inbound routed events. The change is previewed, approved, and can be rolled back.
4. Run both connectors during the overlap if your plan needs it. Watch the manager desk for Pending sync states.
5. When the old CRM is retired, deactivate its connector in a further revision. History already read from it stays in the ledger as events, not content.

What you’ll see

• The Unified history on a contact shows the source system for each entry, for example “HighLevel”.
• The connector list shows both CRMs with their status during the overlap.
• Call log rows for contacts still owned by the old CRM sync to it until the switch.

If something looks wrong

• A contact appears twice. Both CRMs emitted an event for the same person. Resolve it in your migration tooling; DialSplice will not guess.
• Dispositions land in the wrong CRM. Check which system owns the contact record. Ownership is decided by your migration, not by DialSplice.
• A sequence restarted. That happened in the CRM, not in DialSplice. Check the CRM’s own automation.

Related

• Requesting a connector
• Connector status and credentials
• Setting a disposition