Missive Migration Checklist

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

Having done this hundreds of times, 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.

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)
• 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

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
2. • 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
3. • 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
4. • 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
5. • 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
6. • Contacts: if you bring over customer records, ensure you create Contact Books (if used), 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
7. • 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.

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.

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.
• 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.