Key takeaways
- The full run can take as long as it needs, because the team keeps working in the old helpdesk throughout.
- A delta run carries new records, new replies and changed fields, not the whole history again.
- A ticket resolved or reopened after the full run should arrive in its new state.
- Switch the channels after the catch-up delta, then run one more for anything that arrived during the switch.
What a delta run is, and how it finds changes
A full run moves everything in scope. A delta run moves only the difference since a previous run: records created since then, and records changed since then, such as a new reply on an old ticket, a status change or an edited contact. Where the source can list records changed since a point in time, the delta asks it for exactly that; where it cannot, records are compared with what was written last time.
- New replies are appended to the thread already in the destination, not copied in again.
- A changed ticket is updated in place, because each migrated record is linked to its destination record.
- A record that failed in an earlier run is retried rather than skipped.
A cut-over plan
- 1.Run the full migration while the team keeps working in the old helpdesk.
- 2.Set up the destination: channels, routing and automations. Keep automations that message customers paused for now.
- 3.Run a catch-up delta as close to the switch as you like.
- 4.Switch the channels: email forwarding, chat widget, contact forms and integrations.
- 5.Run a final delta for anything that arrived in the old helpdesk during the switch.
- 6.Reconcile record counts on both sides, then turn the destination’s automations on.
A delta sync at cut-over is part of every DataGrine migration, run self-serve on the platform or fully managed by the migration team, with 24/7 support either way. A delta run can also be rolled back like any other run; see how rollback works.