Fixing Inbox Rules Not Migrated After Email Move

A user opens their freshly migrated mailbox, checks the inbox at 9am, and finds 400 unsorted messages that should have been routed to project folders, vendor labels, and the "from-finance" bucket. None of their rules survived the cutover. This is the most common post-migration support ticket after "where did my contacts go," and it surprises admins who assumed IMAP would carry rules along with mail. It doesn't, and it can't. Here's what's happening and how to rebuild quickly without re-running the entire migration.

Why IMAP migrations never carry rules#

IMAP is a protocol for moving messages and folder structure. That's it. Inbox rules — the if-this-then-that logic that sorts, flags, forwards, and auto-replies — are stored entirely outside the IMAP message store. Each provider keeps rules in its own proprietary schema:

• Exchange / Microsoft 365 stores rules as hidden FAI (Folder Associated Information) items in the Inbox folder, accessible only through MAPI, EWS, or Microsoft Graph.
• Gmail / Google Workspace stores filters as user settings exposed through the Gmail API as users.settings.filters resources.
• Zoho, Fastmail, Yahoo each use their own JSON or XML formats served from web admin APIs.
• iCloud stores rules in a Sieve dialect on the IMAP server, but exposes them only through the iCloud web client.

When any migration tool authenticates over IMAP, it sees mailboxes and messages. It never touches the rules store because the rules store is not part of IMAP. This is true whether you're using Mailbox Taxi, a competitor product, or a homegrown imapsync script. If you need rules to survive, you have to handle them as a separate workstream.

Confirming rules are actually missing (not just broken)#

Before you start rebuilding, rule out two false alarms:

1. Client-side rules on a different machine. If the user logs in from a new laptop after the migration, their Outlook client-side rules won't appear because those live in the local Outlook profile, not on the server. Have them open Outlook on their old machine and check whether the rules still exist there.
2. Rules that reference now-missing folders. A rule that moves messages to Inbox/Clients/Acme will silently fail if the destination platform renamed or merged that folder during migration. The rule may still exist; it just can't execute.

Step-by-step rebuild process#

1. Export rules from the source while you still can

   For Exchange and Microsoft 365, run Get-InboxRule -Mailbox user@domain.com | Export-Csv rules.csv against the source tenant. For Gmail, use the Gmail API endpoint users.settings.filters.list or have each user export filters from Settings → Filters and Blocked Addresses → Export. For Zoho or Fastmail, the admin console exposes a JSON dump per user.

2. Translate vendor-specific conditions

   Gmail filters use labels; Outlook uses folders and categories. A Gmail filter that applies the label Clients/Acme becomes an Outlook rule that moves the message to the folder Clients\Acme and optionally assigns the category Acme. Importance flags, star markers, and "skip inbox" all have non-obvious equivalents — document these mappings before you start scripting.

3. Recreate rules at the destination

   For Exchange Online, New-InboxRule -Mailbox user@domain.com -Name "From Finance" -From finance@domain.com -MoveToFolder "Inbox\Finance" works per user. For larger batches, loop through your translated CSV with PowerShell. For Gmail destinations, the Gmail API's users.settings.filters.create accepts a JSON filter object.

4. Validate with a test message per rule

   Send a message that matches each rule's criteria and confirm it lands where it should. Watch for ordering bugs — Exchange evaluates rules top to bottom and a "stop processing more rules" flag in the wrong place will mask later rules.

5. Walk the user through the result

   Schedule 15 minutes with the user to confirm everything sorts the way they expect. Power users often have unwritten rules ("anything from this domain after 6pm goes to the late bucket") that didn't make the export. Catching those during a live review beats a ticket two weeks later.

When rule rebuilding gets ugly#

A few migration patterns make rule recreation harder than usual:

• Gmail to Outlook with deeply nested labels. Gmail allows a single message to carry multiple labels; Outlook folders are mutually exclusive. A filter that adds three labels becomes three categories plus one folder move at the destination, and the rule logic has to be rewritten, not just translated.
• Outlook to Gmail with public folder rules. Public folders don't exist in Gmail. Rules that copied messages to shared public folders need a redesign — usually a shared Gmail label with delegated access, or a Google Group.
• Tenant-to-tenant Microsoft 365 with transport rules. Transport rules live at the tenant level, not the mailbox. They migrate separately through Exchange admin export and are easy to forget during a cutover.

For broader post-migration checks, see the post-migration validation playbook and the wider email migration troubleshooting hub. If out-of-office replies also disappeared, the out-of-office fix covers that specific case.

Scripting at scale for MSPs and larger tenants#

If you're moving 200+ mailboxes, manual rebuild isn't tenable. The viable path is a translation layer:

1. Pull source rules from the source API or PowerShell into a normalized intermediate format — JSON with fields for condition, action, and ordering.
2. Build a small translator per provider pair that maps source conditions and actions to destination equivalents.
3. Loop through the intermediate JSON against the destination API to create rules.

The translator is the work. Once it exists, you can rerun it whenever a user reports missing logic, and you can keep it in source control alongside your migration tooling. For the bigger picture on how this fits into your overall plan, see the complete email migration guide.