Zero-downtime migration: running two helpdesks in parallel

Some teams can take a quiet weekend and switch helpdesks in one motion. Others can't: support runs around the clock, volume never dips, or the stakes of a rough Monday are simply too high. For them there's a different pattern — the parallel run. Instead of a cutover event, migration becomes a dial: two helpdesks live at once, traffic shifting from old to new one channel at a time, with the old tool switched off only when the numbers say it's safe.

Done right, customers never notice and agents never face a cliff. Done casually, you get the two classic failures: customers answered twice by different people, or answered by no one because each tool assumed the other had it. The difference is a handful of rules.

The principle: route new, drain old

One rule powers the whole pattern: new conversations start in the new tool; conversations in flight finish where they began.

Nothing gets moved mid-thread. A customer who wrote on Tuesday in the old system gets their Thursday reply from the old system, from an agent who can see the whole exchange. A customer who writes for the first time after the switch lands in the new inbox. Every conversation has exactly one home, chosen by where it started — which means at any moment, both teams and both tools know unambiguously who owns what.

The old helpdesk stops being your support system and becomes a draining queue: no new intake, a shrinking backlog, and a visible finish line.

Switch channels one at a time

Parallel running works because you never bet every channel at once. A typical order, lowest risk first:

1. Website chat. One snippet swap, instantly reversible, and chat conversations are short — the in-flight drain takes hours, not weeks. This is your rehearsal at low stakes.
2. A secondary email alias — the low-volume address, not the flagship. Watch a full week of traffic flow end to end: routing, assignment, escalations, CSAT.
3. The main support email. By now the process is proven; volume is the only thing that changes.
4. Messengers and social channels — often gated by platform-side reconnection steps, so schedule their re-linking rather than assuming it.

Give each channel a soak period — a few days where it runs on the new tool while you check nothing leaks — before switching the next. The whole ladder typically spans two to four weeks. Slower is fine; skipping rungs is how surprises stack.

Keeping data consistent across two tools

The tempting architecture is a live two-way sync between the systems. Resist it. Two-way sync between helpdesks is fragile plumbing that breaks silently, and it exists to solve a problem the routing rule already solved — nobody needs both tools to hold every conversation during the overlap; they need every conversation to have one home now, and the new tool to hold the full record at the end.

The pattern that works is much simpler:

• Bulk import before the parallel period starts: history, contacts, knowledge base and macros land in the new tool so agents have context from day one.
• A delta import at the end: once the old tool's queue has drained, one final pass picks up everything created there during the overlap. The record is complete exactly when the old tool retires.
• Contacts converge on email as the deduplication key, so a customer who appears in both tools during the overlap merges into one record rather than becoming twins.

Who answers where: staffing without split-brain

Split the team by channel, not by seniority: whoever owns chat works the new tool the day chat switches; the email crew follows when email does. Every agent crosses over aligned with a routing change, so nobody works two queues at once — and working two queues at once is exactly what produces the double-reply.

Two supporting rules:

• Champions cross first. The agents who learn fastest take the first channel, and by the time the main email flips, the new tool has in-house experts on every shift.
• The old tool gets an end date on a calendar, visible to everyone. Open-ended parallel periods breed queue-camping — agents lingering in the familiar tool — and you end up paying for two systems out of pure inertia.

Metrics during the dual period

Blended numbers lie during an overlap: the old tool's queue is shrinking by design and the new tool's is growing by design, so any combined average mostly measures the mix, not the service. Instead:

• Track per-tool first-response time and resolution time, and compare the new tool's numbers against the old tool's pre-migration baseline — that's the honest like-for-like.
• Watch the old tool's backlog curve. It should fall monotonically; a plateau means something is still routing intake there, and finding that leak is the day's most important task.
• Expect the new tool's numbers to start slightly worse and cross the baseline within a week or two per channel, as habits settle.

Exit criteria: when to switch the old one off

Write these down before the parallel period begins, so the decision is a checklist, not a debate:

• Every channel routed to the new tool, with each having completed its soak period.
• Old tool's in-flight queue drained below an agreed handful, with the stragglers explicitly reassigned.
• The delta import has run and spot-checks confirm the record is complete.
• New tool's per-channel metrics at or above the pre-migration baseline.
• Integrations, webhooks and automations verified as pointing at the new tool only.
• Team sign-off — the shift leads agree nothing still depends on the old system.

Then: old tool to read-only until the billing cycle ends (cheap insurance and honest reference), cancellation confirmed in writing, and the archive export stored somewhere you control.

The failure modes to design against

• Double replies — always a symptom of an agent working both queues or a channel routed to both tools. The routing rule and channel-aligned staffing prevent it structurally.
• Orphaned aliases — the forgotten forwarding address still feeding the old tool after "everything" switched. The backlog plateau exposes it.
• Integrations writing to the corpse — a webhook or script still creating tickets in the old system. Part of exit criteria for a reason.
• The eternal overlap — paying for both tools for six months because nobody owned the end date. Set it on day one.

Where MoveDesk fits

MoveDesk was built for the parallel pattern: the free white-glove migration includes both the initial bulk import and the final delta pass, unlimited seats mean the whole team can live in both tools during the overlap without seat-license arithmetic, and the 14-day trial comfortably covers the first rungs of the channel ladder. If you're weighing what the other side of the overlap looks like, the Intercom comparison shows the migration path in detail.

Pick your first channel — probably chat — and set the old tool's end date today. A parallel migration without an end date isn't a migration; it's a second subscription.