Export everything before you cancel anything
The single most common migration regret is discovering, after the account closed, that
something was only ever stored in the old provider. Access usually ends on the cancellation date
rather than at the end of a grace period, and support teams are rarely able to retrieve data from
a closed account.
So the order matters: export first, verify the exports open and contain what you expect, then
cancel. Work through the list deliberately.
- Chat transcripts. Often needed for dispute resolution, and sometimes for your own retention obligations. Check the export format is something you can actually read later, not a proprietary blob.
- Canned responses and saved replies. These represent real accumulated work. Copy the text out even if the new system stores them differently.
- Offline messages and their contact details, which are frequently held separately from transcripts.
- Reports and historical metrics. You will not be able to recreate last year’s numbers afterwards, so save the summaries you actually reference.
- Agent lists, departments and routing rules, as a written reference for rebuilding.
- Widget settings — colours, position, wording, hours — captured as screenshots if there is no export.
Know what will not transfer
Very little moves automatically between providers, and expecting otherwise is what turns a
half-day job into a bad week. Assume that anything configured in the old system has to be
rebuilt by hand in the new one.
Historical transcripts almost never import into a new provider in a searchable form. Plan to
keep them as an archive you can search outside the tool rather than expecting continuity. Routing
rules, proactive invitation triggers and canned response libraries are all conceptually similar
between products but structurally different, so they need re-entering rather than importing.
Integrations are the ones that catch teams out. Anything wired into the old widget — a
CRM connection, a helpdesk link, analytics events, a webhook into an internal system —
points at the old provider and will stop working the moment you swap the snippet. List them
before you start, because an unnoticed broken integration usually surfaces weeks later as
missing data.
Rebuild deliberately rather than replicating
A migration is the one moment when re-examining the setup costs almost nothing, because you
are re-entering it anyway. Most long-running chat configurations have accumulated rules nobody
can justify: an invitation firing on a page that no longer exists, a department with one member,
a canned response describing a policy that changed two years ago.
Copy across what is working, and leave behind what was only ever inertia. Reviewing the canned
response library in particular is worth the hour — teams routinely find a third of it is
out of date, and rebuilding is a natural moment to fix that rather than importing the staleness
into a fresh system.
Cut over without a gap
The cutover itself is short if it is planned, and messy if it is improvised. A sensible
sequence:
- Set up and configure the new provider fully while the old one is still running. Nothing is live yet.
- Test the new widget on a staging site or a single low-traffic page, with real agents answering real test conversations.
- Brief the team before the switch, not during it. Agents discovering a new console mid-conversation is the worst version of this.
- Swap the snippet at a genuinely quiet hour — early morning or a weekend for most businesses.
- Watch the first hours closely with someone available to roll back, and confirm chats are arriving and notifications are firing.
- Leave the old account open, but with the widget removed, for a short overlap in case something needs retrieving.
Resist running both widgets at once. Two chat buttons on one page confuse visitors, split your
agents’ attention, and produce conversations nobody is watching.
Check the things that silently break
After the swap, a few failures are common and none of them announce themselves. Confirm that
the widget appears on every template, not just the homepage — checkout, help pages and
landing pages often carry their own layout. Verify it on a phone as well as a desktop, since
placement problems usually show up on small screens first.
If your site has a content security policy, it must allow the new provider’s domain or
the widget will silently fail to load for every visitor while looking fine to anyone whose
browser cached the old one. Check notifications actually reach agents, since a missed sound
setting means chats sit unanswered. And confirm your privacy policy and any cookie notice still
describe reality, because they almost certainly name the old provider.
How MyLiveChat fits
MyLiveChat is free forever for one agent, which makes it practical to set up and test a new
configuration properly before you touch the live site — the whole rebuild can be done in
parallel with your existing provider still running. The install is a single snippet, so the
cutover itself is one edit and is equally easy to reverse if you want to roll back.
What to measure
For the first fortnight, compare chat volume against the same period before the move. A sharp
drop almost always means a technical problem — a template missing the snippet, a blocked
domain, a widget hidden behind other page furniture — rather than a change in demand.
Watch first-response time as well, since it usually worsens briefly while agents learn a new
console and should recover within a week or two. If it does not, the issue is training or
notification settings rather than the product. Finally, keep a short list of anything the team
says it misses from the old system; some items are genuine gaps worth solving, and the rest stop
being mentioned once the new habits form.