Switching Email Clients Without Losing Your Outlook Rules

What happens to Outlook rules when you switch email clients depends entirely on where the rule was stored, and most people who have used Outlook for years have no idea their rules are split into two categories that behave in opposite ways. The short version: server-side rules follow the mailbox to any client. Client-only rules die with the Outlook app they were built in.

This post is the audit and the rebuild. We show which of your rules will travel, which will not, how to identify each one before you switch, how to export the client-only set as a safety net, and how to reconstruct the local logic in a new client without spending a week rebuilding a rule ladder by hand.

One honest scoping note before we start. If your rules are heavy on Outlook-specific actions — playing a sound, launching a script, moving mail into a local .pst — and you rely on that behaviour daily, you may not want to switch at all. Classic Outlook remains the most powerful rules wizard on the market, and no third-party client, ours included, matches it feature for feature in that specific UI. Read the 'What breaks' table below before you commit to the move.

What actually moves and what doesn't#

Outlook rules live in one of three places, and only two of them survive a client switch. Knowing which is which is the whole game.

Server-side inbox rules are stored on the mailbox itself — Exchange on-prem, Exchange Online (Microsoft 365), or the consumer Outlook.com service. They run on the server, so they fire whether Outlook is open or not, and any client that connects to that mailbox inherits them automatically. Sign into the same account from Apple Mail, Thunderbird, Spark, eM Client or AI Emaily, and those rules keep working without you touching them.

Client-only rules live inside your local Outlook profile on one specific computer. Outlook labels them 'client-only' in the rules manager, and they only execute while Outlook is open and syncing that account. They exist because the server cannot do the thing the rule asks for — running a script, showing a desktop alert, moving to a local .pst archive, or applying a custom form. When you close Outlook, they stop firing. When you switch clients, they disappear.

Exchange transport rules are the third category and are often confused with the first two. They are admin-controlled mail-flow rules that apply organisation-wide inside Exchange or Microsoft 365, set by an IT admin in the Exchange admin centre. They are not your rules, they do not appear in the Outlook rules manager, and they are unaffected by any client you use. If your mail is being redirected or stamped by one of these, changing clients changes nothing.

Pre-migration checklist: audit before you touch anything#

The audit is the whole job. Ninety per cent of 'my rules disappeared when I switched' tickets are client-only rules that the user assumed were server-side, because Outlook does not put a warning banner on either kind. Ten minutes with the rules manager tells you exactly what will travel and what will not.

• Open classic Outlook (not new Outlook — it hides most of this). File, Manage Rules & Alerts. The list you see is every rule attached to the currently selected account.
• Look for the words 'client-only' at the end of any rule name. Outlook appends it automatically to rules that cannot run on the server. Every one of those is at risk. Every one without it is already server-side and will travel with the mailbox.
• For each rule, note the action. Move, copy, delete, forward, mark as read, apply category, flag for follow-up: server-side capable. Play a sound, display a desktop alert, start an application, run a script, print, apply a custom form, move to a local folder or .pst: client-only forever.
• Screenshot the whole list, ordered top to bottom. Order matters — Outlook evaluates rules top-down and stops after the first match unless a rule specifies 'continue'. Your rebuild in the new client needs the same order or the same result set will not appear.
• Export the client-only rules as an .rwz file: File, Manage Rules & Alerts, Options, Export Rules. The .rwz is your rollback insurance. If the switch goes wrong, you can reimport into classic Outlook and be back to where you started in one click.
• Confirm which rules quota you are near. Exchange Online caps inbox rules at 256 KB per mailbox (higher for migrated mailboxes). A bloated rule set can silently fail to sync fully to some clients — better to prune before you switch than debug afterwards.
• Check for Exchange transport rules with your admin. If someone else has set org-wide mail flow rules, those apply in every client and are not yours to migrate. Knowing they exist stops you rebuilding logic that is already running one layer up.

Steps: how to switch without losing what matters#

The order matters. Prove the server-side rules arrive in the new client first, then rebuild only the client-only ones you actually miss, then decommission the old Outlook profile last. Skipping the middle step is how people spend a weekend rebuilding rules they never used.

1. 1

   Run the audit and export the .rwz

   Do not skip. The .rwz file is your one-click rollback if the new client turns out to be wrong for you, and the screenshot of the rule list is your rebuild reference. Both take five minutes.

2. 2

   Sign into the new client with modern auth (OAuth)

   Use 'Sign in with Microsoft' rather than an app password. Microsoft has ended basic auth for personal Outlook.com in third-party apps (September 2024) and is progressively retiring it for M365. OAuth also carries the scope the client needs to read the mailbox's server-side rules cleanly.

3. 3

   Let the initial sync finish before judging anything

   A full mailbox sync with folder hierarchy, flags and server-side rule evaluation can take hours on a large archive. Do not decide a rule is missing before the client says it is done. Server-side rules already apply on incoming mail during the sync — you may see freshly-filed messages arriving in the right folder immediately, which is a good sign the rule fired on the server.

4. 4

   Send yourself a test message that should trigger a known rule

   From a second address, send a message matching one of your server-side rules — an obvious subject line or sender you filter to a project folder. If it lands in the folder in the new client, the rule fired on the server and everything below it is inherited. If it lands in the inbox, that rule was probably client-only and you have not spotted it yet.

5. 5

   Triage the client-only rules by whether you actually use them

   Walk your screenshot and mark each client-only rule as 'still need it', 'can replace with a provider-side filter', 'was never useful, delete'. The last bucket is usually the largest. People accumulate rules for one-off situations and never clean up.

6. 6

   Rebuild the surviving client-only rules in the new client's own rules engine

   Most modern clients ship a rules editor. Recreate the conditions and actions the client supports. Where the action was Outlook-specific (play a sound, run a script), pick the closest native equivalent — a notification, a category, a webhook — or accept that the rule is retired.

7. 7

   Rebuild what the rules engine cannot express as AI triage instead of a rule ladder

   This is where a rule-based mind loses time. Client-only rules were often a workaround for logic the server could not express — 'move to Follow-up if sender is one of these fifteen people AND subject contains any of these seven words AND it's a Monday'. In a modern client with an AI triage layer, that stack collapses into one instruction in plain English, evaluated per message. See the 'A faster way' section below.

8. 8

   Leave both clients running for a week

   Two clients on the same Exchange or Microsoft 365 mailbox is safe. The server is authoritative and each client writes back its state (read/unread, moved, flagged). Use the week to catch the rules you did not think you needed, and to notice which ones were doing invisible work. When nothing has forced you back to Outlook for seven days, close the profile.

What breaks, and how to replace it#

The table below is the shopping list. Most items have a workable replacement; a few genuinely retire when Outlook does. Cross them off as you go so you can tell what actually changed by the end of the week.

A picture of the split#

The diagram below is the mental model to hold while you audit. Rules on the left of the split travel with the mailbox. Rules on the right travel with the app — and when the app goes, so do they.

Rollback plan: what to do if the new client is not right#

Rollback is the reason the pre-migration checklist is worth doing even if you are confident about the switch. Because server-side rules never left the server, reconnecting classic Outlook to the same mailbox restores every one of them automatically — nothing has to be re-created. The client-only rules are what you would lose, and the .rwz file you exported earlier restores them in one click: File, Manage Rules & Alerts, Options, Import Rules, select the .rwz.

Order for a clean rollback: reinstall or reopen classic Outlook, sign into the same account, wait for sync to complete, then import the .rwz. Test the same trigger message you sent during the switch and confirm the same behaviour. This whole exercise is fifteen minutes if the .rwz is where you left it.

The only real loss on rollback is anything you built inside the new client during the trial period — its own rules, its templates, its saved actions, any AI-triage instructions you tuned. Those live inside the new client, not on the mail server, so they do not come back. Which is why the honest answer to 'should I skip the audit and just try it' is no; the audit is what makes the fifteen-minute rollback possible.

Doing it without downtime#

There is no cutover moment for an Exchange, Microsoft 365 or Outlook.com mailbox. The server is authoritative and can be signed in from as many clients as you want simultaneously. Both classic Outlook and the new client can be running on the same account, on the same or different machines, and each will see the same folders, the same flags, and the same server-side rule outcomes. No message is ever in flight.

Run both in parallel for a full working week. Do real work in the new client. Keep Outlook available in the background for anything you notice you have not migrated — the client-only rule you use twice a month, the .pst you had forgotten was an archive, the Quick Step muscle memory you have not rebuilt yet. When Outlook has not been the answer to a real question for seven days, close the profile and remove the account. That is the whole cutover.

If you are on a POP account, this is not true — POP downloads and removes, so having two clients pulling from the same account will race. Move POP to IMAP first, or accept that the switch has to be a hard cutover on a specific day.

A faster way: AI triage instead of a rule ladder#

The reason most client-only Outlook rules exist is that a plain condition-action rule cannot express the judgement the user actually wants. 'Move to Follow-up if it is from one of these fifteen people, but only if it is not a calendar invite, and only during work hours, and only if I have not already replied' is a paragraph, not a rule. In Outlook that becomes six rules and a Quick Step. In a client with an AI triage layer, it is one instruction written the way you would explain it to a colleague, evaluated per message with approval before anything is filed. AI Emaily is that client — we ship a rules brain that reads plain-English instructions alongside classic condition-action rules, with an approve-before-send agent (Copilot) or gated automation (Autopilot), and an audit trail for every action it takes. We build AI Emaily. It is a 7-day free trial on Pro or Autopilot — card on file, $0 if you cancel before day 7. Full pricing at /pricing; product overview at /.