Separate the widget change from the data migration
There are three jobs in a live chat migration: changing the visitor-facing widget, configuring the new support workspace, and deciding what happens to old records. A successful widget installation proves only the first job. Your team still needs the right access, alerts, working hours, and a reliable way to continue unfinished conversations.
Decide which records actually need to move and which can remain in an authorized archive or the previous service. An export that you can open is not necessarily a file the replacement can import. Check the destination's supported formats and fields before promising that old chats will appear in the new inbox.
Yapdesk does not currently provide a built-in importer for another chat provider's conversation history. If you are moving to Yapdesk, plan access to old records separately. Do not rename an export file or paste transcripts into AI knowledge and treat that as a conversation migration.
Inventory where the current chat is installed
Before changing anything, note the current plugin name, connected service account, website identifier, agents, notification destinations, and active support modes. Record who owns the account and who can restore the old configuration. Keep any connection secrets in your approved credential store, not in a shared screenshot or migration checklist.
Check whether the widget also comes from a theme snippet, header-and-footer code tool, page builder, or tag manager. Deactivating a WordPress plugin may not remove a second installation elsewhere. That is one reason two launchers can remain visible after what looked like a complete replacement.
Take reference screenshots of the launcher and an open conversation on desktop and phone. Note the important pages to revisit: homepage, contact page, service or product pages, and any customer-account or checkout pages where the current widget appears. The goal is to compare behavior, not simply reproduce the old color.
Back up WordPress and preserve external records separately
WordPress's backup guidance distinguishes the database from site files; a typical complete site recovery needs both. Create a recent backup before changing plugins and confirm how it would be restored. A downloaded plugin folder alone is not a backup of your site's settings or database.
Hosted chat records may live outside WordPress. Confirm the previous provider's export, access, attachment, and retention options before canceling its service. Do not assume your hosting backup contains conversations stored in an external dashboard.
If an export is available, inspect it. Open a sample old conversation and a recent one, check dates and participant details, and confirm whether attachments are included or only linked. Check whether those links will still work after the account closes. Keep the archive access-controlled and retain only what your business is entitled and required to keep.
Assign every open request before changing tools
Make an open-work list rather than relying on everyone to remember their chats. For each unresolved request, record the old conversation identifier, responsible agent, current status, next action, and promised update time. Include an authorized reference to the original record so the next person can find the context.
Choose one place where each request will continue. You might finish it in the previous service during a defined transition period or continue through an approved email workflow. Do not have two agents answer the same customer independently because the request appeared in both work lists.
If a customer needs a different contact route, explain the practical change without making them reconstruct their issue. Transfer only the context needed for the next step, verify the recipient, and never copy credentials or unrelated customer information into a new conversation.
Prepare Yapdesk before the live switch
Start with a nonpublic test site where practical. A staging copy can still contain production chat identifiers, send email, or connect to live services, so isolate those connections before testing. A separate hostname alone does not make external integrations safe to exercise.
Install the official Yapdesk Live Chat plugin and open its WordPress admin screen. Choose Sign in to my account if you already use Yapdesk, or Create a free account if you need a new login. Confirm the intended account and website before connecting. Once connected, the plugin can automatically load the widget, so do not connect an unprepared replacement on a busy live site.
Configure the website's chat title, launcher, message text, notification destination, and answering mode. Core human live chat and message mode are free with Yapdesk branding. AI replies, hybrid replies, and AI knowledge features are Pro AI features; they are not required for the human-support migration.
Set up the device each agent will actually use and test its alerts. A notification permission granted to the previous service does not demonstrate that Yapdesk alerts are working. Also check account-plan limits before relying on extra websites or additional agents during the transition.
Sources: Official Yapdesk plugin on WordPress.org · Yapdesk support: Connect or reconnect WordPress · Yapdesk support: Phone installation and notifications
Make the live change during a controlled window
Choose a quieter period and tell the answering team when the change will happen. Finish active live exchanges where possible, or give those visitors a clear follow-up route. An already-open browser tab can still contain the previous widget, so a plugin change should not be described as a seamless transfer of active conversations.
In WordPress, deactivate the old chat plugin rather than deleting it immediately. Disable any separately installed copy of its script, then activate or connect the prepared replacement. Keep a verified contact route visible while you check the result. WordPress provides separate activation, deactivation, and deletion controls on the Plugins screen.
Clear the relevant page or CDN cache using your site's normal process, then check as a signed-out visitor. Avoid making unrelated theme, checkout, or plugin changes in the same window; otherwise it becomes harder to identify which change caused a problem.
Sources: WordPress: Manage plugins
Verify the whole conversation, not just the launcher
Use fictional customer details and clearly label test messages. Test the actual pages, devices, and support modes your team depends on. Do not submit a real purchase or refund merely to confirm that a chat widget is visible near those controls.
- Open a public page while signed out and confirm that only the intended chat launcher appears.
- Send a visitor message and confirm it reaches the correct website inbox in Yapdesk.
- Reply as the agent and verify the response arrives in the same visitor conversation.
- Repeat on a phone, checking that the keyboard, composer, close control, and page navigation remain usable.
- Verify the alert on the device that will receive customer chats; seeing the message in an inbox is a separate check.
- Test message mode during a controlled period and confirm the follow-up appears where the team expects it.
- Search for the new test conversation so agents know how to find it later. Old-provider history will not appear automatically.
- Restore the intended live support mode, record the switch time, and identify who is watching the first incoming requests.
Sources: Yapdesk support: Receive and reply to your first live chat
Keep rollback narrow and account for new messages
Define the conditions that would make you pause: messages reaching the wrong account, replies not arriving, inaccessible mobile controls, or duplicate widgets. Preserve the test evidence and keep an alternative contact method available while you investigate.
A widget rollback usually starts by disabling the replacement and restoring the previous known working installation. Recheck the visitor side after clearing the relevant cache. Account for messages received in the new system during the test window; changing the widget back does not move those messages into the old service.
Do not restore an entire older WordPress database as a routine first step. That can replace unrelated orders, registrations, or content created since the backup. Ask the site maintainer or host for the smallest appropriate recovery action, especially on an active store.
Retire the old plugin only after the support work is covered
Once the replacement works and unresolved requests have owners, review the old service's access and billing separately. Deactivating or deleting a local WordPress plugin is not proof that an external subscription has been canceled. Check the provider's actual account status and any remaining archive-access requirements.
WordPress's uninstall documentation explains that deletion can run plugin cleanup routines. Read the particular plugin's behavior before deleting it. For example, Yapdesk's current uninstall routine removes its local connection settings when the plugin is deleted; that is different from a normal update, which retains the saved connection.
After the transition is complete, remove unused scripts and plugins through the appropriate maintenance process, restrict archive access, and give the team one clear rule for where new questions and old follow-ups belong. The migration is complete when customers can reach you and agents can continue the work, not merely when the old icon disappears.
Start with free live chat
Add Yapdesk to WordPress, answer visitors from one inbox, and use message mode when your team is away. Pro AI is available when you want an AI assistant trained on your business.