Front Migration Checklist & Timeline (2026)

Know your two export paths first

Before you touch a checklist, decide how your data leaves Front, because the two routes have very different limits.

Front's native account data export is the official path — and it's gated. Per Front's guide on exporting your team's account data, only a company admin can request it, and you request it through Front Support's contact form rather than from a settings screen. Front says it will "acknowledge your data export request within 72 hours" and then process it. What you get back is a set of CSV files (EML on request) covering shared-inbox conversations, messages, discussions, comments, and shared-inbox attachments. What you don't get is the catch — more on that below.

A third-party migration tool is the other path, and for a like-for-like move into a new help desk it's usually the pragmatic one. Help Desk Migration (by Relokia) runs a Migration Wizard that connects to Front through an API token and moves your records directly into the target platform, at a documented throughput of roughly 2,000 tickets per hour. It maps far more than a raw CSV — but it, too, leaves things behind.

We cover the mechanics of pulling data out in depth in how to export data from Front; this post is the migration plan around it.

What moves vs what you rebuild

This table is the heart of any Front migration. Assume everything in the right-hand column is manual work, and scope your project around it.

Two honest takeaways. First, the native export is lossy: it explicitly excludes individual-inbox conversations and comments, contact data, message templates, tags, and individual-inbox attachments. Second, even the richer migration-tool path does not carry organizations, custom fields, inline images, knowledge-base articles, macros, triggers, or automations — those "remain in the source system," in Help Desk Migration's words. Your rules were never portable; more on that in the rebuild section.

The pre-migration checklist

Do this work before a single record moves. It's the difference between a two-day migration and a two-week one.

1. Audit and prune. Walk your Inboxes settings and list every shared inbox, connected channel, tag, template, and rule. Delete the dead ones now so you don't migrate clutter.
2. Map inboxes to the new platform. Decide which Front shared inbox becomes which group/queue in the target. Write it down — this mapping is what "during" runs against.
3. Request the native export early (if you're using it) via Front Support, because of the 72-hour acknowledgement window — it's the longest-lead item in the plan.
4. Prep the Front account for tooling. If you're using Help Desk Migration, generate an API token under Settings → Developers → API Tokens with Shared and Private scopes, temporarily disable 2FA on the service account, and add and invite your agents into Front first so records can be assigned to real people.
5. Stand up the destination. Create the matching inboxes, agents, and business hours in the new platform before import day.
6. Screenshot your rules and templates. They don't port. Capture every rule and every template now (the rebuild template below tells you exactly what to record).

The during-migration checklist

1. Run a demo migration first. Help Desk Migration's free demo (its "Demo with custom data" option) lets you import up to 20 records by ID so you can eyeball how conversations, tags, and assignments land. Note: each demo creates a new set of tickets, so delete the demo records before the full run to avoid duplicates.
2. Verify the demo record-by-record. Check the same IDs on both the source and target. Confirm timestamps, requesters, attachments, and internal comments survived.
3. Freeze changes, then run the full migration. Put Front into a low-traffic window, stop routing new work into inboxes you're moving, and start the full import. At ~2,000 tickets/hour you can estimate your run time from your ticket count.
4. Keep both systems live during the cutover. Don't disconnect Front's channels until the destination is confirmed working — this is your safety net.

Downtime, timeline, and the honest limits

Realistic timeline. For most teams the calendar looks like this: a few days of pre-work (audit, mapping, requesting the export), a same-day demo, a full migration whose length is driven by volume (a 20,000-ticket account is roughly a 10-hour import at documented throughput), then up to five days of post-migration verification — Help Desk Migration gives you a five-day window to confirm records transferred correctly. Budget one to two weeks end-to-end for a mid-sized team, more if you have heavy rule/template rebuild.

Downtime. A direct API migration can run with near-zero inbox downtime because you keep Front receiving mail while records copy across; the risk isn't outage, it's divergence — messages that arrive mid-migration. Freeze new inbound to the migrating inboxes during the final full run, or plan a delta pass for the gap.

What genuinely does not survive. Be candid with stakeholders: Front's rules, shared drafts, message templates, custom fields, and analytics history do not migrate by any route. The native export additionally drops tags and contacts. None of this is a bug — it's the boundary of what's portable out of a collaborative shared-inbox system. Treat the rebuild as a first-class workstream, not an afterthought.

The rule & template rebuild template

Because Front rules don't port, you rebuild them from a spec — and the cleanest way is to capture each one in a small table before you leave, then re-create it in the new platform's automation engine. Record, for every rule:

Do the same for templates: paste each template's full body and its trigger context into your doc so a teammate can rebuild it verbatim. This spreadsheet is your migration's memory of the logic Front won't hand over.

Where Macha fits after the move

Whichever inbox you land on, the reasoning your Front rules and templates were reaching for — "read this billing question, check the order, answer it" — is exactly the part that never ports. The broader category of AI agents for customer service exists to do that reasoning work. Macha is one such layer, and it's honest about its role: it runs on top of your help desk — Front included, via the Macha–Front connector — and never replaces it. So if you're migrating between platforms, Macha doesn't add another thing to migrate; you point it at wherever you end up. It reads each conversation, understands intent rather than keywords, and drafts or sends a grounded reply — pulling a real order or account status through a custom tool that turns your REST API into something the agent can call. Because Macha's credits are consumed per AI action — never per resolution — you can rebuild automation on the new platform and add the reasoning layer on top of it, priced for what it actually does.

FAQ

Can I export my Front data myself? Partially. Only a company admin can request Front's native account data export, and it goes through Front Support's contact form rather than a self-serve button; Front acknowledges the request within 72 hours. It returns shared-inbox conversations, messages, comments, and shared-inbox attachments as CSV — but not tags, contacts, templates, or individual-inbox data.

What does Front's export leave out? The native export excludes individual-inbox conversations and comments, contact data, message templates, tags, and individual-inbox attachments. Rules, shared drafts, custom fields, and analytics history don't come out by any route.

Do Front rules migrate to another platform? No. Front rules, macros, and automations do not port. You rebuild them in the new platform's automation engine — which is why capturing each rule's trigger, conditions, and actions in a spec before you leave is part of the checklist.

How long does a Front migration take? Plan one to two weeks end-to-end for a mid-sized team. Pre-work takes a few days, the demo is same-day, the full import runs at roughly 2,000 tickets per hour, and verification uses a five-day window. Heavy rule and template rebuilding adds time.

How do I roll back if the migration goes wrong? Keep Front fully live — channels connected, receiving mail — until you've verified the destination record-by-record. Because a direct API migration copies rather than moves, your source of truth stays intact; if verification fails, you re-point routing back to Front and re-run the import after fixing the mapping.

Landed on your new help desk? Start a free trial of Macha and connect the AI agent layer to whichever inbox you chose — no extra migration required.