Missive Migration Checklist

If you're about to migrate your help-desk or support operations into Missive, having a checklist of things to do, not do, and be aware of is important.

We've run Missive migrations across a range of source platforms — Zendesk, Freshdesk, Intercom, Help Scout, Front, and others — and we've seen the pitfalls, the common "oh-no" moments, and the things that make the migration smooth.

This checklist is your roadmap: from planning, through pre-migration setup, to the migration itself, and post-go-live validation.

Follow these steps and you'll minimise disruption, protect customer history, rebuild workflows accurately, and go live confidently.

Scope the migration

• How many years of ticket history do you bring over? Full history or say last 3-5 years?
• How many agents/users? Are you migrating active agents only, or also inactive/archived ones?
• By business unit: Do you migrate everything by unit (say Support, Sales, Billing) or selectively?
• Decide what records you want to migrate: tickets/conversations, contacts, companies (or organisations), agents, teams, custom fields, tags/labels, attachments, comments/notes, time logs.
• Decide what not to migrate: e.g., very old tickets, low-value records, closed/archive only, spam or test tickets.

Platform-specific considerations

Different source platforms have different gotchas when migrating to Missive:

• Zendesk: Ticket fields, macros, and triggers don't have 1:1 equivalents in Missive. Custom fields need to be mapped to Missive labels or contact custom fields. Zendesk "organizations" map to Missive organizations, but nested group structures may need flattening.
• Freshdesk: Freshdesk companies map to Missive organizations. Freshdesk "canned responses" must be manually recreated as Missive response templates. Note that Freshdesk's ticket priority levels don't have a native Missive equivalent — use labels.
• Intercom: Intercom's conversation model is closer to Missive's than traditional ticket systems, but Intercom "tags" map to Missive labels and Intercom "segments" have no direct equivalent.
• Help Scout: Help Scout mailboxes map well to Missive shared inboxes. Saved replies need manual recreation. Help Scout "workflows" must be rebuilt as Missive rules.
• Front: Front's shared inbox model is the closest to Missive. Tags map to labels, but Front's rule engine differences mean automations need rebuilding.

Missive key terminology

Missive uses specific terms that can overlap or confuse if you're coming from another platform:

• Organization: The top-level account container in Missive. All teams, users, and data live inside it. Equivalent to a Zendesk "account" or Freshdesk "portal."
• Team: A group of users who share access to specific inboxes and labels. Used for routing and assignment.
• Group: Refers to contact grouping — a way to organize contacts into logical buckets (e.g., VIP Customers, Partners).
• Contact Book: A collection of contacts, sometimes scoped to an organization or team. Think of it as an address book.
• Shared Label: A label visible to all members of a team or organization, used for categorizing conversations.
• Posts: Internal system-level entries within a conversation — used to represent system events, audit logs, or internal notes that aren't customer-facing messages.

What we can migrate via API into Missive

• All customers and companies as Missive contacts, organizations and groups
• Full ticket history as conversations/messages, including original timestamps, authors, attachments and internal system events (via posts — see terminology above)
• Shared labels, categories and queues, including their colors, hierarchy and sharing scope
• Assignee, participants and team ownership for each conversation
• Tasks and follow-ups attached to tickets
• Webhooks that notify your systems of new messages/comments, plus analytics reports for validation

What still needs to be configured in the Missive UI

• Channel connections: email accounts, shared inboxes, shared addresses, SMS/WhatsApp/Twilio, Facebook, Instagram, Missive Live Chat
• Users, teams, org membership and roles
• Rules and automations (SLA rules, auto-assign, auto-reply, weekend DND, etc.) apart from webhook-only rules
• Canned responses/templates content
• Signatures, personal preferences, notification settings and the live chat widget appearance

Field mapping reference

The table below shows how common source-system fields map to Missive. Exact field names vary by platform, but the structure is consistent.

Setting up your Missive account before migration

Always build the target environment proactively so the data lands in a ready-state.

1. Create the Missive Organisation & Subscribe

• Ensure you have the correct plan (Missive paid plan/yearly) that allows full history import and API token generation.
• Set up the organisation name, billing, and verify you are ready to invite users and agents.

2. Invite and create all Users / Agents

• Create/invite all current agents to the Missive organisation (even if some will go inactive later) so they exist ahead of mapping.
• Set roles: Admins, regular agents, observers/guests (if you will use guest access).
• For security: generate/administer API keys (go to Preferences → API tab → Create new token) for migration.
• If you plan to disable two-factor authentication (2FA) temporarily for agent accounts during migration (some clients choose to), ensure you have an internal policy/documentation for re-enabling afterwards.

3. Turn off notifications and freeze workflows during migration

• To avoid confusion during import: disable email notifications for imported tickets/conversations so agents are not flooded with alert emails for bulk import activity.
• (Link internally to your standard "Disable notifications during import" how-to).
• If your source system is still active and generating tickets, consider setting it to "maintenance mode" or "read-only" during the final import window.

4. Create Teams and assign Agents

• Recreate your organisational structure: teams (Support, Sales, Billing, Tier 1, Tier 2 etc).
• Assign the invited users to the correct teams so when tickets import with owner/team assignment they map correctly.
• Ensure each agent's user ID in Missive is documented and mapped to their source system user ID.

5. Create and replicate structure of Contacts, Companies, and Conversations

• Contacts: if you bring over customer records, ensure you create Contact Books (if used — see terminology section above), or custom groups in Missive, so imported contacts map into correct book/group.
• Companies/organisations: if your source system has companies, you might need to use Missive's contacts + custom fields or tags to simulate the company association.
• Custom fields / tags: In your source system, you may have ticket fields, contact fields, company fields. Pre-create these in Missive (via custom fields, tags, labels) so the imported data knows where to land.
• Recreate assignment rules: If you have assignment logic tied to teams or labels, replicate these after migration (see post-migration workflows).

6. Do not delete tickets/conversations during migration

• Important: Do not purge old tickets or conversations prematurely in your source system. You need the full history until cut-off.
• In Missive: avoid closing or archiving incorrect imported data until validation is complete.

Data privacy and compliance considerations

Before moving customer data between systems, make sure you've addressed the compliance basics:

• GDPR: If you handle data from EU residents, ensure your data processing agreement (DPA) covers the migration. Both the source platform and Missive should have DPAs in place. Customer data in transit should be encrypted (TLS at minimum).
• Data residency: Confirm where Missive stores data and whether that aligns with your regulatory requirements. If your source system stores data in a specific region, verify that migrating to Missive doesn't violate residency constraints.
• Data minimisation: Migration is a good opportunity to purge data you no longer need (expired tickets, deleted contacts, GDPR erasure requests that were pending). Don't migrate data you shouldn't be holding.
• Access control during migration: Limit API token access to the migration team. Revoke tokens immediately after migration is complete.
• Audit trail: Keep a log of what was migrated, when, and by whom. This is useful for compliance audits and for debugging post-migration issues.

Migration Execution (Let the migration team do the magic)

This is the "data moving" phase. At this point you've done all the setup. The migration partner or internal migration team executes the import.

• Run an initial sample migration (e.g., 1-10% of records) to validate everything: field mapping, attachments, ownership, labels, timestamps, replies history etc.
• Review the sample in Missive: ask the stakeholders/agents to check and find any data anomalies, missing attachments, broken links.
• Adjust mappings, custom field logic, exception handling (for example if a ticket reference number duplicates or if an attachment is missing).
• Once sample is signed off, schedule the full migration window (preferably during low traffic hours).
• Monitor progress: track API usage, error logs, failed imports, skipped records. Escalate if thresholds or rate-limits hit.
• If you planned a delta migration (i.e., tickets created between sample/initial import and final cut-off), execute that after full import. Many migrations require syncing that "last few days" of data.
• Conduct the cut-over: switch new incoming tickets from the source system into Missive (point email routing, change MX records or shared inbox forwarding) so from that moment, support operations run inside Missive.

Rollback and failure planning

No migration checklist is complete without a plan for when things go wrong.

• Keep the source system intact. Do not decommission or delete data from your source platform until migration is fully validated and you've run in production on Missive for at least 1-2 weeks.
• Define rollback criteria upfront. Before migration starts, agree on what constitutes a failed migration — e.g., more than X% of records failing import, critical data loss, or broken integrations. If those thresholds are hit, you revert to the source system.
• Snapshot before migration. If your source platform supports data export or backup snapshots, take one immediately before the migration window opens.
• Have a communication plan. If you need to roll back, agents and customers need to know. Prepare a brief internal comms template in advance.
• Partial failure handling. Not every failure requires a full rollback. If specific record types fail (e.g., attachments over a certain size), document them, continue with the rest, and remediate those records separately.

Post-Migration Checklist

Now that the data is in Missive, and your agents are working, here's how you validate and wind down:

Data Verification

• Verify record counts: number of contacts, number of tickets/conversations, number of attachments, compare source vs target with allowance for known exclusions.
• Spot-check data integrity: randomly pick contacts/tickets and verify attachments exist, assignment is correct, timestamps preserved, comments/notes intact, labels appear as expected.
• Confirm owner/agent assignments: tickets assigned to correct agents or teams in Missive.
• Check that attachments opened correctly in Missive and links are accessible.
• Query for missing or "orphan" records: e.g., tickets without contact, contacts without email, tickets without labels when there should be.
• Validate timestamps: Created date, Last message date should align reasonably with source system.

Ticket Creation and Channel Testing

• Use each channel (email, live chat if applicable, SMS/WhatsApp integrations) to create new ticket/conversation and verify it appears in Missive.
• Confirm new assignments, notifications (if turned back on), agent routing, labels and response flows.
• Have agents send/receive, add internal comments, re‐assign tickets, and check that all behave as expected.

Agent Roles and Permissions Validation

• Ensure every agent has correct role: admin vs standard vs guest; manage what access they have.
• Confirm team assignments: their inboxes, label visibility, archive permissions, mention/comment permissions.
• Confirm that external users/guests (if you have them) have the correct limited access rules.
• Confirm that housekeeping actions (archive, close conversation, assign) work and are visible in analytics or reports.

Automation and Workflow Trigger Tests

• Re-create workflows/rules: e.g., automatic assignment based on label or keyword, auto-close after X days, SLA escalation, canned responses.
• Test each rule: create a condition and verify correct outcome (assignment, label application, notification).
• Confirm scheduled or recurring jobs (if you have them) are running: e.g., daily reports, reminders, bulk tagging.
• Confirm integrations: If Missive is connected to other systems (CRM, Slack, Zapier), verify new tickets generate the correct outputs/triggers.

Enable Conversation Ratings / Feedback (if enabled)

• If you use conversation ratings/feedback or NPS surveys via Missive: set those up, test the workflow, send a test rating request, ensure results log correctly.
• Communicate to agents that ratings now work inside Missive and show how they'll appear on dashboards.

Final Clean-Up and Go-Live

• Once you're confident everything is correct, enable live status: turn on email notifications, re-enable 2FA (if you disabled temporarily), switch agents into "live" mode inside Missive.
• Archive or disable your old system (or set to read-only) to avoid duplicate tickets or confusion.
• Train agents: share any process changes in using Missive (labels, shared inboxes, assignment logic).
• Document any deviations/exceptions found during migration for future reference.
• Schedule a follow-up review (e.g., 1 week & 1 month later) to check for any missing records, agent feedback, performance issues, and adjust as needed.

Common Mistakes and Pro Tips

• Notifications chaos: If you leave notifications on during import, agents get flooded with replies or assignment alerts for migrated tickets. Turn off bulk import alerts.
• Training too late: Agents coming in cold to a new system and data set feel lost. Run orientation/training just ahead of go-live.
• APIs hitting rate limits: Always test sample size, monitor API calls, apply retries/back-off logic. Missive's API requires token auth and has documented rate limits — check Missive's API documentation for current thresholds.
• Agent mapping mismatch: If an agent leaves mid-migration or you don't map correctly, you'll end up with "ghost owners" or tickets assigned to old IDs. Pre-create all users.
• Delta gap between cut-off and go-live: Without capturing tickets created in that gap, you'll lose recent history. Plan the delta window.
• Workflows built too late: If you build rules/automations after go-live but before validating, you may miss routing for older tickets. Build workflows before high volume comes in.
• No rollback plan: Assuming the migration will work perfectly is a recipe for panic. Keep the source system running and define your failure criteria before you start.
• Skipping compliance review: Moving customer data between systems without reviewing your GDPR obligations or data residency requirements can create legal exposure. Do the compliance check before migration, not after.