Migrate Outlook.com to Office 365: Consumer to Corporate Move

The naming is unhelpful. "Outlook" can mean the desktop client, the consumer webmail service at outlook.com, the corporate Exchange Online service formerly called Office 365, or any of the three at once. This post is about one specific journey: moving a mailbox out of the consumer Outlook.com service and into a Microsoft 365 business tenant with Exchange Online. People do this when a freelancer goes corporate, when a company finally formalises an email address that has lived in a personal Outlook account for years, or when an acquisition rolls personal mailboxes into a parent tenant. Same Microsoft, two different products, and a surprisingly real migration in between.

Two services that share a logo#

Outlook.com is Microsoft's free consumer email service. It started life as Hotmail, became Live Mail, then MSN, then Outlook.com. Mailboxes live in a consumer data centre, identity is a Microsoft consumer account, and admin tooling is the user's My Account page. Quota is 15 GB for free accounts, more with a Microsoft 365 personal subscription.

Microsoft 365 (formerly Office 365) is the paid business service. Mailboxes live in Exchange Online with quotas of 50 GB or 100 GB depending on the plan. Identity is Microsoft Entra ID (formerly Azure AD). Admin tooling is the Microsoft 365 admin centre and the Exchange admin centre.

The two services share branding, a UI family, and parts of the technology stack, but they are separate products with separate storage, separate identity systems, and separate admin tooling. A mailbox does not "upgrade" from one to the other. You provision a new Microsoft 365 mailbox and migrate the content.

What changes for the user#

Brace the user for a few visible differences after cutover:

• A new email address, usually on the company's domain instead of @outlook.com
• A new sign-in via the corporate identity, possibly with single sign-on
• New conditional access policies (MFA requirements, device compliance)
• A larger mailbox quota and corporate retention policies
• Loss of personal-account features like Outlook.com themes and ad-free toggles

If the user wants to keep their @outlook.com address forwarding into the new mailbox, set up a server-side forward on Outlook.com before decommissioning the source account.

Provisioning the destination#

The Microsoft 365 side has to be ready before you start moving anything.

Create the target mailbox#

In the Microsoft 365 admin centre, add the user under Users > Active users. Assign a license that includes Exchange Online (Business Basic, Business Standard, Business Premium, Enterprise E1/E3/E5, or any plan with Exchange Online standalone).

Wait for the mailbox to provision. It can take 5 to 60 minutes depending on tenant load. Confirm in the Exchange admin centre that the user's mailbox appears under Recipients > Mailboxes.

Confirm IMAP is enabled#

Open the mailbox properties and check Manage email apps. IMAP should be enabled. If the tenant has a baseline policy disabling IMAP, enable it for this user during the migration window.

Sort conditional access#

Conditional access policies will likely affect the migration. Check the Microsoft Entra admin centre under Protection > Conditional Access for policies that:

• Block legacy authentication
• Require compliant devices
• Restrict by location or network

Either exempt the user explicitly for the migration window, or use a migration tool that authenticates via OAuth2 (which most CA policies allow).

Source-side preparation#

The Outlook.com side needs some prep, but less than people assume.

Generate an app password#

If the source account has two-step verification on (most do), the migration tool needs an app password instead of the real password. Sign in to account.microsoft.com on the user's behalf, go to Security > Advanced security options, and generate an app password. The result is a string with no spaces. Use it as the IMAP password in the migration batch or tool.

The app password walkthrough covers the consumer Microsoft account flow specifically.

Inventory storage and folders#

Sign in to outlook.com and check the Storage page in settings. Note total size. Note any folder structure that the user cares about. Note any rules under Settings > Mail > Rules — those will not migrate and need to be recreated on the destination.

Note auto-replies and signatures. They do not migrate either.

Decide what to migrate#

The default is everything. Often the user wants to leave Junk and Trash behind. Confirm with the user before starting.

Running the migration#

You have two real options.

Option 1: Exchange admin centre IMAP migration batch. The official Microsoft tooling. Set up a CSV with source email/password pairs (app passwords work as the password column). The Exchange admin centre pulls from imap-mail.outlook.com and lands content in target mailboxes. Good for bulk migrations.

Option 2: Desktop migration tool with both endpoints. Configure source as imap-mail.outlook.com:993, destination as outlook.office365.com:993. Tool moves mail directly. Good for one-off or where you want more control over folder mapping and parallelism. Mailbox Taxi takes this approach because it gives you transparency into what is happening per message.

Both options copy mail server-to-server. Neither moves calendar or contacts.

1. Set up authentication on both ends

   Outlook.com source: app password generated. Microsoft 365 destination: OAuth2 via an Azure AD app, or migration batch admin credentials with the appropriate permissions.

2. Test connectivity

   Connect to imap-mail.outlook.com:993 and outlook.office365.com:993 from the migration host. Confirm both reach. Test SMTP if you also need to migrate sent mail metadata.

3. Map folder names

   Outlook.com IMAP uses "Sent", "Deleted", "Junk Email". Microsoft 365 uses "Sent Items", "Deleted Items", "Junk Email". Configure mapping accordingly. Inbox, Drafts, and user-created folders map straight across.

4. Pilot one folder

   Migrate a small folder first. Verify in Outlook on the web that messages appear, dates are right, attachments open, flags are preserved.

5. Run the full migration

   Cap parallelism at 2–3 connections. Outlook.com throttles aggressively. Plan for 50–80 MB per minute against the consumer service.

6. Migrate calendar and contacts separately

   Export from outlook.com as ICS (calendar) and CSV (contacts). Import into the M365 mailbox via Outlook on the web's import functions or via PowerShell for directory-level contacts.

7. Reconfigure clients

   Update Outlook desktop, Outlook for Mac, and mobile devices to the new Microsoft 365 account. Confirm the user can read both new and migrated mail.

8. Set up forwarding and decommission

   On Outlook.com, set a server-side forward to the M365 address. Keep the source account active for 30–90 days as a safety net before final decommission.

Throughput and limits#

Outlook.com is the tighter side of this migration. Plan around:

• 2–3 IMAP connections per account to avoid Too many simultaneous connections
• 50–80 MB per minute realistic throughput
• 150 MB per-message limit on Outlook.com (Microsoft 365 accepts the same by default)
• 15 GB mailbox cap on free Outlook.com (paid Microsoft 365 personal extends this)

Microsoft 365 is less aggressive on throttling but does have rate limits — Too many simultaneous connections and stalls when you push past 5–10 concurrent mailboxes.

Errors you'll see#

AUTHENTICATIONFAILED against imap-mail.outlook.com — usually MFA is on and you gave the real password. Switch to an app password.

Too many simultaneous connections — drop to 2 connections, wait, retry.

Message too large for destination — increase MaxSendSize and MaxReceiveSize on the Microsoft 365 side, or skip large messages.

Folder UTF-7 conversion error — non-ASCII folder name encoding mismatch. Rename source to ASCII.

OAuth2 token expired — tool should refresh. Restart if not.

STARTTLS handshake failed — proxy intercepting TLS. Run from an unproxied network.

Verification#

Before declaring the migration done:

• Compare per-folder message counts between Outlook.com (via Outlook on the web) and the Microsoft 365 mailbox. Small differences are normal.
• Spot-check ten messages per major folder: date, sender, body, attachments, threading.
• Search in the M365 mailbox for known recent senders to confirm reachability.
• Confirm calendar and contacts came across separately and are visible in the M365 mailbox.
• Confirm rules, auto-replies, and signatures have been recreated.
• Confirm the user can sign in, read mail, send mail, and that their Outlook desktop client is configured correctly.

Keep the Outlook.com account active for at least 30 days with a server-side forward. Missing-message reports surface weeks after cutover, and the source account is the only reliable way to answer them.

The MX cutover#

The very last step is updating the domain's MX records to point at Microsoft 365 — but only if the user is migrating a custom domain that they own. For users moving from @outlook.com to a new corporate address, MX records do not change because Outlook.com keeps owning the @outlook.com namespace.

If the user owns a custom domain currently pointed at Outlook.com (some Outlook.com users add custom domains via Microsoft 365 personal subscriptions), update the MX records to point at the new tenant's Exchange Online endpoint per the Microsoft 365 admin centre's setup wizard. Allow 24–48 hours for DNS propagation before relying on the new mail flow.

Related routes#

If the destination is Gmail instead of Microsoft 365, see migrate Outlook to Gmail for the consumer-Outlook-to-Gmail path.

For tenant-to-tenant moves between Microsoft 365 tenants, migrate Office 365 to Gmail is the wrong direction but covers the source-side considerations, and the Office 365 migration guide covers tenant-to-tenant scenarios in depth.

If the destination is Microsoft 365 but the source is Gmail or Google Workspace, see migrate Gmail to Office 365. The general patterns are similar.

The complete email migration guide covers cross-platform migration planning at a higher level, including the parts of this work that are not specific to any source-destination pair.