Front Migration Checklist

If you are preparing to migrate your support or shared inbox operations into Front, having a detailed checklist is essential. Front is powerful, flexible and fast, but you only get a smooth migration when the environment is prepared well and when you understand what must be done through API and what must be configured manually.

This checklist walks you through the whole journey. The planning. The technical prep. The actual data move. The post-migration cleanup And everything you must verify before agents start working full-time in Front.

Scope the migration

Start slow. Get clear on the basics. Rushing this part causes painful rework later.

Decide how many years of conversation history you are moving.
Identify how many active and inactive teammates need to exist in Front so ownership is mapped correctly.
Figure out which inboxes, tags, custom fields, conversation metadata, attachments, internal comments and message threads you need to preserve.
Decide what you want to drop. Old spam. Test messages. Dead contacts. Outdated tags.
Map old routing logic to Front’s assignment model and “inboxes” structure.
Confirm API rate limits and estimate migration time.

Keep your scope document visible to everyone on your team. It avoids last-minute surprises.

What can be migrated via API

Contacts & Companies

Front’s API lets you recreate your entire customer base. You can programmatically add contacts, update their details, attach custom fields and link them to companies. This also means you can preserve old attributes like legacy IDs or notes and have every historical ticket point back to the right person or organisation.

Conversations & Messages

You can rebuild whole conversations through the API. Every message, reply, internal comment and timestamp can be recreated in the exact order it happened. It feels seamless because Front treats imported conversations almost the same as live ones. It gives you a clean, threaded history just like the original.

Attachments

Attachments come through with ease. The API allows you to add files to any message in the thread, keeping their proper names and formats. PDFs, logs, screenshots or inline images will sit exactly where they belong.

Tags, Custom Fields & Metadata

If your old helpdesk relied heavily on labels or custom fields, you can bring all of that over. Tags can be applied to conversations, and custom metadata fields can store details like old ticket IDs, priorities or categories. It helps keep context alive in the new workspace.

Quick Note: Data in the custom fields can be migrated via the API, however, custom fields have to be set up initially via the Front UI.

Assignments, Ownership & Participants

Ownership can be restored without trouble. You can assign conversations to teammates, add participants or followers and even place the conversation inside the correct shared inbox. Status values like open or archived can also be set through the API.

Comments, Mentions & Internal Notes

Private notes and internal discussions can be recreated too. Even though mentions may not behave exactly like in the old system, the historical comments will still appear in the correct order, right inside the conversation timeline.

Custom Channels & Source Attribution

If you want imported history to come from a dedicated source, you can write everything into a custom channel. This makes it easy to trace which conversations were migrated and keeps reporting clean.

Rules & Integrations (Partially)

While not everything in Front’s automation suite is API-driven, you can still build parts of your workflow programmatically. Integrations that rely on Front’s plugin framework or webhook logic can be created or updated this way, but the full automation builder still lives in the UI.

What still needs to be configured in the Front UI

Channels & Connected Inboxes

All your inboxes and channels must be connected manually. Email accounts, shared inboxes, IMAP/Google/Microsoft connections, SMS or WhatsApp integrations and social channels all require UI setup. The API cannot create these links for you.

Teammates, Roles & Permissions

User creation is a hands-on task. You need to invite teammates, assign roles and set permissions from the interface. Only then can you reference these users in your migration scripts.

Shared Inboxes & Team Structure

Shared inboxes, their members and their visibility rules all need to be configured by hand. This is where you map your organisation’s structure inside Front, and the API will rely on this foundation when importing data.

Rules (Automation Builder)

Front’s automation builder is powerful, but entirely UI-driven. Auto-assign rules, keyword routing, escalations and tagging logic all have to be recreated manually after the migration. None of these rules can be generated by API.

Message Templates (Canned Responses)

Saved replies and canned messages must be written or imported by hand. The API can’t create these templates, so agents will set them up once the workspace is ready.

Collaboration Settings

Settings related to collaboration, such as how mentions behave, internal comment preferences or collision detection, all live inside Front’s interface. These small details shape how your team works day-to-day and must be configured manually.

Signatures, Preferences & Personal Setup

Every teammate needs to fine-tune their own space. Signatures, notification preferences, keyboard shortcuts, availability settings and integrations like calendars or CRMs all require manual configuration inside each profile.

Plugins & Integrations

Many integrations require UI confirmation or installation steps. CRM plugins, billing systems, webhook connections and other third-party apps often need a few clicks in Front before they become active. The API can manage data, but connection setup happens in the UI.

Setting Up Your Front Account Before Migration

Before you import data, get the target environment set up so the import lands into a clean, functional structure.

Create the Front account & configure core settings

Choose the right Front plan (features like shared inboxes, routing rules, analytics, custom objects) to match your expected usage.
Set up organisation settings: company name, timezone, default language, data residency (if applicable).
Invite key stakeholders (admins, lead agents). Decide who will own the migration process within Front.

Configure agents, teams & inboxes

Create all current active agents/teammates. If you plan to migrate inactive ones as owners of old tickets, create them too (or map to a “legacy owner” alias).
Set up shared inboxes (e.g., support@, sales@, billing@) in Front. Ensure forwarding or routing from those addresses is ready.
Create teams or groups if you segment by function (Support, Sales, Escalations). Map agent membership accordingly.
Provide each agent with a login and basic training so they are comfortable in Front before the cut-over.

Configure data schema: contacts, companies, custom object

Create custom contact and company fields (to capture legacy IDs, account tier, source system fields).
If you use “companies” (accounts) in your helpdesk, replicate those in Front via contacts + company associations or via custom objects if you need richer modelling.
If your source system has entities that don’t map to contact/company/conversation, plan to use Front’s Custom Objects feature. (Front’s API supports many resource types.)

Prepare channels and routing rules

Ensure all inbound channels are set up in Front: email, live chat, SMS/WhatsApp (if applicable) or API sources. Front documentation for Channels API indicates custom channel support.
Temporarily disable or modify routing/automation rules that would trigger on imported old data (avoid flooding agents or customers).
Decide when you’ll switch email forwarding from old system to Front shared inboxes at go-live.

Disable notifications and test import path

Turn off outgoing customer notifications for imported history (you don’t want customers alerted about old tickets during import).
Run a small pilot import: import e.g., 100 contacts + 50 tickets + few attachments. Confirm mapping, data accuracy, attachments appear correctly, the right team and agent assignment.
Validate the import handling: message threading, contact assignment, timestamps, attachments, tags/status.

Migration Execution

Here’s where it gets real. You’ll run your main import, handle volume, monitor for errors, then cut over.

Import contacts and companies first. Once your contact base is in Front, conversations can reference them correctly.
Import conversations/messages: For each ticket in the source system you’ll replicate as a Front conversation. Include all messages in the thread, attachments, status, participants, creation/close timestamps. Front’s Core API supports creating and updating many relevant resources.
Import attachments with correct metadata so they attach properly to the conversation in Front.
Import old assignments: who owned the ticket, which team or inbox it belonged to. Map those to Front teammates/teams/inboxes.
Import tags, custom fields, rating history, and other metadata you decided were in scope.
Run delta import for all new tickets created after your main export cutoff and up to the moment of go-live.
Switch routing: update email forwarding/MX or routing rules so new requests land in Front rather than the old system.
Monitor API usage, errors, duplicates, failed imports. Maintain a log of any manual fixes required.
Communicate the cut-over: Let agents know when the system moves, when the old system is read-only, what to do in Front.

Post-Migration Checklist

Once the data is loaded and agents are working in Front, it is time to validate, optimise and go live fully.

Data verification

Compare counts: contacts, companies, conversations, messages, attachments in Front vs source system.
Perform random spot checks: open a ticket in the source system and verify the conversation chain appears the same in Front (sender/recipient, timestamps, attachments, status).
Verify contact/company associations, custom fields.
Check that attachments open correctly.
Confirm teammates and teams are visible and have correct permissions.
Confirm conversation status is correct (open, closed, snoozed, archived) and that it lands in the correct shared inbox.

Channel testing & agent workflows

Test each inbound channel: email, chat, SMS/WhatsApp (if applicable). Create full new conversation and follow through resolution.
Verify outbound replies send correctly, and inbound replies thread cleanly in Front.
Agents should test assignment, tagging, internal comments, team handoffs in Front.
Ensure forwarding, auto-reply, SLA notifications (if applicable) are working as expected.

Automation, routing and workflows

Re-enable routing rules: auto-assign based on tags, keywords, team, channel.
Test workflow automations: status changes, tagging, notifications, escalations.
Validate custom steps and internal macros/templates. Front allows rule-based automation and API-driven integrations.

Agent setup & adaptation

Ensure each agent has correct role and permissions. Check what they see: their inboxes, shared inboxes, folders, tags.
Provide training: how Front differs from old system, how to use features like internal comments, collaboration with teammates, assigning, snoozing, archiving.
Encourage agents to set personal preferences: notification settings, signatures, integrations.

Final cleanup & go-live

Once you’re confident, disable the old helpdesk system or set it to read-only to avoid duplicate tickets.
Reactivate all customer notifications that were turned off for import.
Start full live operations inside Front.
Schedule a review in 1 week and in 1 month to check performance, user feedback, missing tickets, workflow issues.
Collect agent feedback: what’s working in Front, what gaps remain, iterate.

Common Mistakes and Pro Tips

Attachments are often underestimated. Big files, inline images, zipped logs — test how Front handles them.
Agent mapping mistakes: If you miss mapping an agent or create duplicate identities, you’ll end up with orphaned conversations or wrong owners. Create all agents and match meticulously.
Labels/tags vs shared inboxes: In Front, how you use shared inboxes, tags, folders matters a lot for how agents view work. Think about the user view early.
Delta window hidden cost: Many teams export, wait days, then find new tickets created in that window. Plan the delta import carefully to avoid missing conversations.
Training is as important as the import. Even the best data import fails if agents don’t know how the target system works. Front has a collaboration-centric workflow (shared inboxes, team comments) which may differ significantly from older “ticket system” workflows.
Monitor API rate limits: Front’s API pagination and rate limit policies require your migration scripts to handle back-off and errors.
Clean up before import: If the source system has many unused tags/custom fields or duplicate contacts, consider a clean-up phase. It simplifies the target schema in Front.
Keep the old system accessible (read-only) for some period post-go-live so agents can reference historic tickets if something didn’t migrate perfectly.