Migrating to Tola
Most teams coming to Tola are not starting from nothing. They have years of history in Zendesk, a shared Gmail account, a WhatsApp number on someone's phone, or all three at once. This page covers what moves, what does not, and how to run the switch without a customer noticing.
What a migration actually involves
A migration is four separate jobs, and it is worth separating them in your head because they have very different costs:
- Name
Moving the channels- Type
- hours
- Description
Repointing your email, WhatsApp number and chat widget at Tola. Genuinely quick — this is a day's work at most, and much of it is waiting for DNS or Meta.
- Name
Moving the customer data- Type
- a day or two
- Description
Contacts, companies and the attributes you hold about them. Exported as a spreadsheet from your old system and imported into Tola.
- Name
Moving the historical conversations- Type
- the hard one
- Description
Years of closed tickets. This is where most of the cost sits, and — see below — usually where the least value is.
- Name
Moving the team- Type
- two to four weeks
- Description
Habits, saved replies, routing rules and the muscle memory of a support team. The part that determines whether the migration is judged a success.
Plan for the fourth one. Everyone underestimates it, and everyone overestimates the third.
What transfers and what does not
Transfers cleanly:
- Contacts, with names, emails, phone numbers and any custom fields you keep about them.
- Companies and which contacts belong to them.
- Your saved replies and canned responses — as text, to be recreated in Tola.
- Your team, their roles and your channel structure.
Transfers with effort:
- Historical conversations. These can be brought across as records against the right contact, but the fidelity depends on what your old system will export. Threading, internal notes and attachments do not always survive.
- Help center articles. The text moves; the formatting and any custom theming will need redoing.
Does not transfer:
- WhatsApp chat history from the WhatsApp Business app. This is a WhatsApp limitation, not a Tola one, and it catches people out. See below.
- Automation rules and workflows. The logic is portable, the configuration is not — you will rebuild these, and it is usually a good thing.
- Reporting history. Your old numbers stay in your old system. Export any board-level figures you need before you cancel the contract.
- Ratings and satisfaction scores.
Before you pay for a full historical conversation migration, ask how often your team actually opens a ticket older than ninety days. For most businesses the honest answer is "almost never" — in which case keeping the old system in read-only mode for a quarter is far cheaper and works just as well.
From a shared mailbox
The most common starting point, and the easiest migration.
- Connect the mailbox to Tola by forwarding, or by connecting Gmail or Microsoft directly. See email.
- Export your contacts from wherever you keep them — your CRM, your billing system, a spreadsheet — and import them.
- Leave forwarding on for a fortnight so nothing in flight is lost, and so you have a fallback if something surprises you.
- Turn off the old habits. The real work is people no longer replying from the mailbox directly. Remove access if you have to.
Realistic time: half a day of setup, two weeks of habit change.
From Zendesk or Freshdesk
You are moving from a ticketing model to a conversation model, and the mental shift is bigger than the technical one.
- Export contacts, organisations and users from the admin area. Both platforms produce spreadsheets you can map straight into Tola's contacts and companies.
- Export your macros and canned responses as text, and rebuild them in macros and canned responses. Do not port all of them — most teams find a third are unused.
- List your active triggers and automations, then rebuild the ones that earn their place as workflows. This is the single best opportunity you will get to delete rules nobody understands.
- Recreate your groups as teams and your custom fields as custom attributes.
- Repoint your support email address at Tola.
- Decide about history. Either migrate it, or keep the old account in read-only for a quarter.
Realistic time: one to two weeks of preparation, one day to switch.
Tickets and conversations are not the same shape. A ticket is a work item that gets closed; a conversation is an ongoing relationship with a person that has a status. Teams who try to recreate a ticket workflow exactly in Tola tend to end up fighting it. Give it two weeks before deciding anything is missing.
From Intercom
The closest model to Tola's, so the concepts translate well.
- Export contacts and companies, including the custom attributes you have built up. These map directly.
- Export saved replies and rebuild them as canned responses.
- Rebuild your inbox rules as workflows.
- Replace the messenger snippet on your website with Tola's. See live chat — get your web team to swap them in one deployment, so there is never a window with two chat widgets on the page.
- Rebuild your Resolution Bot or Fin flows as Tola AI assistants, knowledge and scenarios. Point the assistant at the same help center content you were already using.
Realistic time: one week, most of it AI knowledge setup.
From WhatsApp Business app
This one needs care, because it is the only migration that can lose something irreversibly.
A WhatsApp number can only be connected to one platform at a time. Moving it from the WhatsApp Business app to Tola disconnects it from the app, and the chat history in the app does not come with it.
Before you start:
- Decide whether that history matters. If it does, export what you need from the app first — it can send chat exports per conversation, which is tedious but possible for your most important customers.
- Warn whoever is holding the phone. The number stops working in their app the moment you migrate. This should not be a surprise on a Tuesday morning.
- Consider a new number instead, with the old one forwarding or auto-replying with the new one for a month. Slower, but nothing is lost and there is no cutover moment.
Then follow WhatsApp setup.
Running the switch
The pattern that works, whatever you are coming from:
Two weeks out. Set up Tola fully in parallel — channels connected but not yet receiving live traffic, contacts imported, teams and roles built, canned responses written. Nothing is switched.
One week out. Route a single low-volume channel to Tola for real. Live chat is ideal. Let two or three agents work in it daily and fix what they complain about.
Switch day. Repoint the main channels. Keep the old system open and forwarding. Have both systems watched by someone senior for the whole day.
Two weeks after. Old system goes read-only. Nobody replies from it. Announce a hard date and hold it — a support team running two systems indefinitely will use both badly.
Three months after. Old system cancelled, once you are confident you have not needed it.
Do not migrate during your busiest period. Not before a sale, not at renewal season, not in the run-up to a holiday. The best week to migrate is a quiet one, and there is always a quiet one if you look.
The first week
What to expect and what to watch:
- Response times will get worse before they get better. People are learning where things are. Two weeks is normal; tell your management this in advance so it is not a surprise finding.
- Watch the unassigned queue daily. Routing rules built in advance rarely survive contact with real traffic.
- Collect complaints in one place and triage them weekly. Most "Tola can't do X" turns out to be "I don't know where X is", and the fix is a five-minute demo rather than a change of plan.
- Do not add features in week one. Get the basics working — conversations in, conversations answered, conversations resolved. AI, campaigns and complex automation come later.
Common mistakes
Migrating everything. Every unused macro, every dead automation rule, every stale custom field. A migration is the cheapest opportunity you will ever have to delete things. Take it.
Switching all channels on one day. Move one, learn from it, then move the rest.
Not deciding who owns it. Migrations without a single named owner stall in the middle, which is the worst place to be — two systems, split team, nobody accountable.
Keeping the old system open too long. A team with two inboxes checks one of them badly. Set the shutdown date at the start.
Skipping the contact import. Starting with empty customer records means agents lose the history that makes them good at their job, and they will blame the tool.