> For the complete documentation index, see [llms.txt](https://missiveapp.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://missiveapp.com/docs/migration/migrating-to-missive.md).

# Migrating to Missive

Moving a team to Missive is mostly a people project, not a technical one. This guide is our recommendation for transitioning smoothly, wherever you're coming from.

## Why teams migrate

Most teams come to Missive to fix the same handful of problems:

* **Shared accounts with no ownership.** Shared email accounts and distribution lists where everyone gets a copy and nobody knows who's handling it.
* **Side conversations that get lost.** The "can you look at this?" lives in a separate chat, detached from the email.
* **No visibility or metrics.** You can't see who's handling what, how fast you respond, or where the time goes.

In Missive, you can have one copy of each message, assigned to one person, but still [visible to the whole team](/docs/core-features/team-inboxes.md).

## Before you start

* **Pick a rollout lead.** One person who owns the migration end to end. The smoothest rollouts always have one.
* **Decide your inbox structure.** One shared inbox per client or team, or a few broader ones like **support@** and **sales@**? Fewer, busier inboxes are simpler. One inbox per client/team gives cleaner separation.
* **Get admin access** to your current email provider. You'll need it to move shared and group addresses, this is especially important for [Outlook users](/docs/core-features/connected-accounts/email-accounts/outlook-office-365/faq.md).

## The recommended rollout, step by step

### 1. Run a small pilot first

Pick a small team (2 or 3 people) and one low-stakes inbox (an internal address like **it@** works well). Connect it, [create a team](/docs/core-features/team-inboxes/creating-a-team-space.md), and use it for real for a week or two. You'll surface the questions your whole team will have before they have them, and you'll know what to put in your company-specific FAQ.

### 2. Agree on one shared-inbox workflow

This is the step most teams skip, and the one that matters most. Decide as a team how you'll work a shared inbox: how mail gets assigned, when to close versus archive, and who routes what. See [From distribution lists to shared inboxes](/docs/core-features/team-inboxes/from-distribution-lists-to-shared-inboxes.md) for a proven approach you can adopt as-is.

{% hint style="info" %}
**Why it matters:** Missive can keep a shared inbox spotless, but only if everyone works it the same way. One agreed workflow beats a dozen personal habits.
{% endhint %}

### 3. Move your shared email accounts into shared inboxes

Connect each shared account (`accounting@` or `clienta@`) to Missive and assign it to a [team](/docs/core-features/team-inboxes/creating-a-team-space.md). Everyone on that team then sees its mail in the Team Inbox. The address never changes, so your contacts won't notice.

How you connect depends on where you're coming from. See your source page under [Migration by source](#migration-by-source) for the exact steps. Distribution lists and shared accounts each have their own path.

{% hint style="info" %}
**Tip:** You can add one simple [rule](/docs/advanced-features/rules.md) per inbox to auto-label incoming mail with the team or client name. Keep automation light at launch. You can always add more once people settle in.
{% endhint %}

### 4. Give everyone a sandbox week

About a week before go-live, invite the whole team and have each person set up their own account: connect their email, [calendar](/docs/core-features/calendar.md), and [signature](/docs/core-features/aliases-and-signatures/setting-up-email-signatures.md), and click around. Leave the shared inboxes off for now. Everyone keeps doing real work in their old tool.

This is what makes migrations painless: people get comfortable with Missive at zero stakes, before anything they rely on moves.

{% hint style="info" %}
**Note:** Everything in Missive is 2-way synced with your email provider, so actions taken in Missive affect what you see in your email server (Gmail/Outlook/IMAP).
{% endhint %}

### 5. Go live in one cutover

After the sandbox week, do the switch in a single window (after hours is easiest): connect the shared inboxes and assign team members as members or observers. The next morning, your team works entirely in Missive.

{% hint style="info" %}
**Run both systems in parallel** until you're confident everything's flowing. Connect the new accounts and verify mail arrives before you retire the old setup. Don't turn anything off on day one.
{% endhint %}

## Make the switch painless

A few things that consistently separate smooth rollouts from rocky ones:

* **Write one short FAQ and point everyone to it.** Capture the questions from your pilot, keep it somewhere central, and answer "where's this" and "how do I" with a link. The questions repeat.
* **Set one workflow, not many.** See [From distribution lists to shared inboxes](/docs/core-features/team-inboxes/from-distribution-lists-to-shared-inboxes.md).
* **Let the AI assistant answer "how do I" questions.** The **?** in the bottom-right searches Missive's own docs. Point new users there first.
* **Expect a couple of holdouts.** Change is hard for some people. Most of the team will be won over within days once the inbox is calmer.
* **Attend a** [**live demo**](https://calendly.com/luis-missive/missive-the-team-inbox) **or watch the** [**pre-recorded demo**](https://www.youtube.com/watch?v=K5tO3W1Jnxg)**.** Either gives a nice overview of Missive.

## What feels different coming from a traditional inbox

Worth telling your team up front. These apply no matter where you're coming from:

* **Your unified Inbox shows anything you're involved with,** not just mail to your address. Assignments and threads you're @mentioned on show up too. Use the filter icon if it feels noisy.
* **The inbox sorts by last activity, not date received.** A new reply moves a thread to the top.
* **Folders (from Outlook) become** [**labels**](/docs/core-features/understanding-label-types.md)**,** and one message can carry several labels.
* **You assign instead of forward,** and you talk on the thread with [internal comments](/docs/core-features/conversations/internal-chat.md) instead of starting a side chat.
* **Read/unread states are per person, not per email.** If you read an email in Missive, it won't be marked read for a colleague.

## Migration by source

Start here, then open the page for your old tool for the specifics:

| Coming from              | Guide                                           |
| ------------------------ | ----------------------------------------------- |
| Outlook or Microsoft 365 | [From Outlook](/docs/migration/from-outlook.md) |
| Front                    | [From Front](/docs/migration/from-front.md)     |

## Rollout checklist

* [ ] Rollout lead assigned
* [ ] Inbox structure decided
* [ ] Pilot run on one low-stakes inbox
* [ ] Shared-inbox workflow agreed and written down
* [ ] Shared and group addresses connected and assigned to teams
* [ ] Sandbox week scheduled (personal setup only)
* [ ] Go-live cutover scheduled (after hours, in parallel with the old tool)
* [ ] FAQ started and shared with the team

## Next steps

* [From distribution lists to shared inboxes](/docs/core-features/team-inboxes/from-distribution-lists-to-shared-inboxes.md)
* [Team inboxes](/docs/core-features/team-inboxes.md), [Creating a team](/docs/core-features/team-inboxes/creating-a-team-space.md), and [Triage and assignment](/docs/core-features/triage-and-assignment.md)
* Your source page above under [Migration by source](#migration-by-source)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://missiveapp.com/docs/migration/migrating-to-missive.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.