From four tabs to one thread.

Before touching anything, write down what each tab actually does for you — not what it was bought to do. The portal holds history and ticket states. The inbox catches everything the portal's form scared away. Slack is where teammates ask "has anyone answered this?" And Discord is where your most engaged customers were the whole time.

Notice the pattern: one tab faces customers (badly), one catches overflow, two exist purely so your team can coordinate. A migration succeeds when it preserves all four functions while collapsing the surfaces. The functions are real; the tabs are not.

Three questions sharpen the inventory:

• Which tab does the customer actually see? Usually just the portal — and usually reluctantly. Everything else is internal, which means everything else can change without anyone's permission.
• Where does the real record live? If the honest answer is "partly in each," write that down. It's the strongest argument you'll have when someone asks why you're migrating at all.
• What does the team do when the portal is down? Whatever that workaround is — usually email plus Slack — it's a sketch of the system you actually want.

The cardinal rule: never run a cutover you can run as an overlap. Connect your support address as an email source while the old portal stays alive. Every new email now lands in both systems — the portal keeps its record, and the same conversation appears in InboxBarn as a thread. You've changed nothing customer-visible, and you can already evaluate the new system on live traffic.

Do the same with the rest of your surface area at whatever pace suits you: connect the Discord server as a source, drop the web chat widget on your site. Sources are independent; this isn't one big migration, it's several small ones, each reversible.

Parallel running also answers the question every migration plan dodges: what if the new system isn't better? Then you disconnect two sources and you've lost an afternoon. The overlap costs nothing but a few weeks of duplicate records in a portal you were already paying for, and it converts the scariest decision of the year into a reversible experiment.

Never run a cutover you can run as an overlap.

Here's the move that makes the whole thing gentle: your team migrates first, and the customers never migrate at all. Point a destination at the place your team already coordinates — support email flowing into Slack, or into your Discord server — and let people answer real conversations from there for a week or two.

Because of the reply invariant, every answer still reaches the customer on their original channel, in their existing thread. The team is practicing the new workflow on production traffic with zero customer-facing risk. The dashboard receives everything regardless, so nothing can fall between systems while trust builds.

Expect the team to migrate unevenly, and let them. One teammate will live in the dashboard, another will answer everything from Slack, the community person will never leave Discord — and none of it needs reconciling, because every reply obeys the same invariant and every thread stays whole. A migration that allows people their habits is a migration people don't resist.

Once the team stops opening the portal voluntarily — it happens sooner than you'd think — schedule the actual switch. It's smaller than the word suggests:

1. 1

   Freeze the portal's intake

   Stop the portal from sending its own auto-replies and notifications. Your support address now has one owner. Inflight portal tickets get finished where they started — don't migrate open conversations mid-flight.

2. 2

   Set the routing vocabulary

   Map your old queues to the four categories — general, VIP, billing, sales — and subscribe destinations accordingly. If your old system needed more than four, read our case for routing without regex before recreating the archaeology.

3. 3

   Rebuild only the macros you used

   Port your ten most-used saved replies, classified by category, and abandon the other sixty. A migration is the one free chance you'll ever get to shed accumulated canned text.

4. 4

   Keep the export

   Take a full export of portal history and archive it somewhere searchable. You'll consult it rarely — but "rarely" isn't "never," and the archive is what lets you cancel the old subscription without ceremony.

Give the switch week a single owner, the way you'd give any conversation one. Their job isn't to do the four steps — it's to be the person who notices the auto-reply nobody disabled, or the old queue that didn't map to a category. Migrations fail at the seams, and seams need a watcher.

Resist the migration announcement email. From the customer's side, nothing has changed in any way that requires their action: they email the same address, post in the same server, and get answers in the same threads — likely faster than before. An announcement invites them to look for problems. Silence, here, is the deliverable.

The one change worth a quiet word is retiring the portal login itself. If customers used to check ticket status there, tell them the simpler truth: reply to the thread, that's the status. The best compliment this migration can earn is the one a customer pays by not noticing it happened — and since every channel ships on the free plan, the parallel-run weeks cost you exactly nothing while you confirm it.

One last habit to retire with the portal: quoting ticket numbers at people. The threads carry the history now, so the IDs have nothing left to do — the case for dropping them entirely is shorter than this guide, and the week you switch is the cheapest moment you'll ever have to act on it.