Switching From Front: Migration Plan for Small Teams

When you switch from Front to another email client, the mail itself is not the problem — it lives in Gmail or Microsoft 365 and stays there. What Front holds in its own system is the assignment state, the internal comments, the tags, the analytics, and the routing rules that decided who saw what. That is the surface you have to inventory before you move a single mailbox.

This guide is for small teams — five, maybe ten seats — that bought a shared inbox for volume they no longer have, or that never really had, and want per-seat AI triage instead. The plan below moves the team without losing conversation history and without a support blackout. It also names the parts of Front that do not have a direct equivalent in a per-seat client, so you can decide whether you actually need them or whether they were process the tool made possible.

What actually moves and what doesn't#

Front is a layer on top of Gmail or Microsoft 365. The mail bodies, addresses, and OAuth grants live at your provider. The collaboration layer — comments, assignments, tag state, workflows, analytics — lives in Front's database. When you disconnect Front, the mail stays where it always was. The collaboration layer is what you have to export, and some of it does not have a clean destination in a per-seat client.

Pre-migration checklist#

Before you touch anything, spend two or three afternoons on the questions below. Most failed migrations off Front fail here — not on the technical export, but on discovering, three weeks later, that the team relied on a Front behaviour nobody documented.

• Who actually reads which mailbox today, and how many of those seats are still active.
• Which internal comments are decisions worth keeping versus chit-chat — only the decisions have to survive the move.
• Which tags map to labels or folders in the destination, and which were duplicate categorisation the team never used.
• Whether SLA reporting is a contract requirement or a habit — the answer decides whether a shared inbox is still the right shape.
• Which integrations (helpdesk, CRM, Slack) currently push into Front, and where they have to land instead.
• Whether the destination client supports Gmail and Microsoft 365 accounts side by side — some don't, and mixed teams get bitten late.
• Who signs off on the cutover, and who fields the "where did the assignment go?" question in week one.

The steps, in order#

1. 1

   Freeze changes in Front two weeks out

   No new automations, no tag renames, no reshuffled inboxes. You want the export you take to match the state the team knows.

2. 2

   Export conversation history

   Front's Core API can export conversations, messages, comments, and attachments as JSON via the sample export app. For a full account-level export, submit a request through Front Support; the self-serve admin panel doesn't do this. Park the output in a searchable archive so agents can look up old context after the move.

3. 3

   Choose the destination and connect mailboxes

   OAuth Gmail or Microsoft 365 into the new client. Verify both providers if your team is mixed. Confirm that shared drafts, if you need them, actually exist in the destination — not every per-seat client has them.

4. 4

   Recreate the shortlist of rules

   Tags become labels. Workflows become inbox rules. Canned responses become templates. Do this by hand from the shortlist you built in the pre-migration checklist; a lift-and-shift of every Front rule usually ports rules the team stopped using in 2024.

5. 5

   Run in parallel for one week

   New mail flows to both Front and the new client. Agents work in the new client. Front stays as a safety net and as the live reference for anything mid-flight. Log every time someone has to jump back to Front — that log is the punch list for step 7.

6. 6

   Cutover day

   Flip inbound routing to the new client only. Set Front to read-only rather than deleting it. Do this on a Tuesday or Wednesday, never Monday morning. Announce internally with the archive URL and the assignment convention in the new client.

7. 7

   Post-migration audit at 30 days

   Review the parallel-week log and any newer complaints. Improve the archive index; add any rule the team keeps asking for by hand. Only after this audit is the migration actually done.

A map of the move#

The diagram below shows the split most teams miss on their first pass: the mail itself never moves — it was always at your provider — while Front's collaboration layer has to be exported, and only the parts you actually use need to be rebuilt in the destination.

What breaks after the move#

Some Front behaviours do not have a direct equivalent in a per-seat client. Naming them up front is the difference between a migration the team accepts and one they resent for six months.

Rollback plan#

Two weeks in, if the destination genuinely can't do something important, you want a clean way back. That is why you keep Front read-only rather than tearing it down, and why the export archive stays untouched.

Reverse the inbound routing (the same OAuth toggle you flipped in step 6). The mail your team already handled in the new client stays in Gmail or Microsoft 365 — it never lived in the new client, so nothing is lost. Do a debrief: what did the destination miss? Is it a real capability gap or a habit gap? If it's real, you've narrowed the field for the next attempt rather than lost the effort.

Doing it without downtime#

Nobody's clients notice a shared-inbox migration when it's done right, because the client-facing addresses don't move — Gmail and Microsoft 365 mailboxes are still theirs. What causes downtime is a hard cutover on a busy morning, or an integration that quietly stops posting into the new tool.

1. 1

   Pick a low-volume day and time

   Tuesday or Wednesday afternoon in the team's timezone. Never Monday morning; never the first working day after a holiday.

2. 2

   Run parallel for one full working week

   Both Front and the new client receive new mail. Agents work in the new client, but Front is on-screen for reference. This week is when you find the integrations nobody thought about.

3. 3

   Have one person watching both queues

   Their job for the week is to catch any missed replies and to log each one. This is the single most important role in the migration.

4. 4

   Communicate the small breaks

   Internally: "from Wednesday, assignments live in [tool]; for comments on old threads, look in the archive." Externally: usually nothing — but if a specific address is retiring, tell those contacts a week ahead.

5. 5

   Flip integrations last

   Webhooks from CRMs and helpdesks are the quiet failure mode. Do them after the parallel week, one at a time, with a test event each.

Where a per-seat AI client fits after Front#

The reason small teams leave Front usually isn't Front — it's that a shared inbox is the wrong shape for the volume they run. AI Emaily is a per-seat AI email client for Gmail and Microsoft 365 that triages a mailbox into work, newsletter, and cold, drafts replies from a user-set Context brain (not from your past mail), and holds every action behind Copilot approval before send. That is the shape you land on after the plan above. We build AI Emaily.

Where Front is still the right answer: if your team measures response time against contractual SLAs across shifts, or if round-robin assignment on a truly shared address is load-bearing, a shared inbox stays the right shape and we are not the fit. Check current packaging on the AI Emaily pricing page before you commit.