In this guide · 8 sections
- 01What moves and what does not
- 02Before you start: prepare Microsoft 365 and cPanel
- 03Run the IMAP migration batch, step by step
- 04MX cut-over and the cPanel email routing setting
- 05Stop the sync and clean up old hosting records
- 06After the move: set up devices and security
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
Create the users in Microsoft 365, verify your domain, then run an IMAP migration batch from the Exchange admin centre to copy each cPanel mailbox. Export contacts and calendars separately, switch the MX record, set cPanel's email routing to Remote Mail Exchanger, wait at least 72 hours, then stop the sync.
What moves and what does not
Microsoft's IMAP migration overview sets out the limits. Plan for them before you tell staff the move is 'automatic'.
| Item | Moves with IMAP migration? | What to do |
|---|---|---|
| Inbox and mail folders | Yes | Migrated newest first |
| Contacts (address book) | No | Export from webmail or Outlook as CSV or vCard, import into Outlook |
| Calendars | No | Export as .ics and import, or recreate key events |
| Tasks | No | Recreate in Microsoft To Do or Planner |
| Emails over 35 MB | No | Save large attachments to OneDrive before migrating |
| Mailboxes over 500,000 items | Only the newest 500,000 | Archive or export older mail separately |
| Filters, autoresponders, forwarders | No | Recreate as Outlook rules or mail flow settings |
Mail stored only on a PC (for example POP3 accounts that downloaded and deleted mail from the server) is not on cPanel any more, so IMAP migration cannot see it. Those users need their local Outlook data file imported instead.
Before you start: prepare Microsoft 365 and cPanel
Pre-migration checklist
Microsoft's guide to migrating other IMAP mailboxes recommends lowering the TTL to one hour or less before starting, so mail servers worldwide pick up the MX change quickly. Our guides to adding a domain to Microsoft 365 and changing MX records without downtime cover the DNS steps in detail.
Run the IMAP migration batch, step by step
This follows Microsoft's documented process for IMAP sources such as cPanel's mail server.
Find the IMAP server name
In cPanel, open Email Accounts, Connect Devices for a mailbox. It shows the secure IMAP server (often mail.yourdomain.com or the host's server name) and port 993.
Create the migration CSV
One row per mailbox with EmailAddress (the new Microsoft 365 address), UserName (the cPanel login, usually the full address) and Password. Microsoft allows up to 50,000 rows in one file.
Create a migration endpoint and batch
In the Exchange admin centre, go to Migration, add a batch, choose IMAP migration, enter the server, port 993 and SSL, then upload the CSV.
Start with one or two test mailboxes
Run a small batch first. Check folders, read status and a few old emails before migrating everyone.
Migrate the rest and monitor
Run the main batch outside office hours. Fix failed rows (usually wrong passwords) and rerun them.
MX cut-over and the cPanel email routing setting
Once mailboxes are copied, point the domain's MX record to Microsoft 365. Microsoft's guide notes it can take up to 72 hours for other mail systems to recognise the change, so some mail will still arrive at cPanel for a while. The migration batch keeps syncing (about once a day) to pick it up.
Then fix the setting that catches many cPanel users. cPanel's Email Routing documentation explains that with Local Mail Exchanger the server always accepts mail for the domain and delivers it to local mailboxes. If routing is still local, your website's contact form, WooCommerce order emails and any other mail generated on the hosting server can be delivered to the old cPanel mailbox instead of Microsoft 365. Set it to Remote Mail Exchanger, which tells the server to send all mail for the domain to the lowest-numbered MX record.
If form emails go missing after the switch, our guide to website contact form emails not arriving covers the other common causes.
Stop the sync and clean up old hosting records
Microsoft advises letting the migration batch run for at least 72 hours after the MX change before deleting it, so mailboxes have synchronised at least once and senders have picked up the new MX. After that, delete the batch to stop synchronisation.
- SPF: replace the hosting server's entry with Microsoft's (include:spf.protection.outlook.com), keeping any other services that send for you, such as your website or newsletter tool.
- DKIM: remove the old cPanel DKIM record once nothing sends through cPanel, and enable DKIM for your domain in Microsoft 365.
- Autodiscover: point it to Microsoft so Outlook finds the new mailbox, and remove any cPanel autoconfig records.
- Old mailboxes: keep them for a few weeks as a fallback, then delete them in cPanel so nobody keeps using them by accident.
- Website sending: make sure the website sends through an authenticated SMTP service or Microsoft 365, not unauthenticated PHP mail.
Updating SPF, DKIM and DMARC properly is what keeps your new mail out of spam; see our SPF, DKIM and DMARC guide.
After the move: set up devices and security
Each person needs the old IMAP account removed from Outlook and phones, and the Microsoft 365 account added. Leaving both in place causes confusion over which mailbox is current.
Do on day one
- Turn on MFA (security defaults) for every user
- Import contacts and calendars from exports
- Recreate rules, signatures and out-of-office messages
- Set up shared mailboxes for info@ and sales@
Avoid
- Keeping the old IMAP account in Outlook 'just in case'
- Forwarding Microsoft 365 mail back to cPanel
- Leaving the migration CSV on a shared drive
- Deleting cPanel mailboxes before checking every user
If you are moving between Google Workspace and Microsoft 365 instead of from hosting email, the tools differ; see migrating between Google Workspace and Microsoft 365.
Do it yourself or get help?
A confident admin can migrate a handful of cPanel mailboxes using Microsoft's wizard in a day, plus the waiting time for MX changes. The usual problems are wrong IMAP server names, mailbox passwords nobody knows, missing contacts and calendars, and the cPanel routing setting.
Our Email Migration service (S$390) moves up to five mailboxes with contacts and calendars where the source allows, handles the MX cut-over and cPanel clean-up, and keeps the old mailboxes as a fallback until you confirm. If you are setting up Microsoft 365 from scratch, Business Email Setup (S$249) covers the domain, DNS and security settings.
Frequently asked questions
No. Microsoft's IMAP migration only moves items in the inbox and other mail folders, not contacts, calendar items or tasks. Export contacts from your webmail or Outlook as CSV or vCard and calendars as .ics files, then import them into Outlook for each user after the mailboxes are created.
Not if you follow the order. Copy mailboxes first, switch the MX record, and keep the migration batch running at least 72 hours so mail that still reaches cPanel is synchronised. Lower the MX TTL beforehand, and set cPanel email routing to Remote Mail Exchanger so mail generated on the server goes to Microsoft 365.
Microsoft's IMAP migration needs either each mailbox's username and password or, for some server types, admin credentials in a special format. On typical shared cPanel hosting, the simplest route is to know or reset each mailbox password before the migration, and treat the migration file holding them as confidential.
Often because cPanel's email routing is still set to Local Mail Exchanger, so mail generated on the hosting server is delivered to the local cPanel mailbox instead of following the new MX record. Change it to Remote Mail Exchanger in cPanel's Email Routing settings, then send a test from the website form.
For a few mailboxes, the copying usually runs in hours, depending on mailbox size and the hosting server's speed. Plan about a week in total: a day or two to prepare DNS and lower the TTL, the migration itself, then at least 72 hours after the MX change before stopping synchronisation and cleaning up.