IMAP and POP Migrations to Microsoft 365 from GoDaddy and cPanel

A lot of small businesses run email on whatever came with the web hosting: a GoDaddy Workspace account, a cPanel server at a shared host, or an old Plesk box. When they outgrow it, the move to Microsoft 365 goes through IMAP migration, which is simple but limited in ways that surprise people on cutover day.

This post explains what the IMAP migration tool does and does not move, how to set it up for the common hosts, and how to handle the POP-only mailboxes where all the mail lives on someone's laptop.

What IMAP migration moves

The Exchange admin center IMAP migration connects to the source server as each user, reads every folder, and copies the messages into an existing Microsoft 365 mailbox. It moves mail and folder structure, nothing else. It does not move contacts, calendars, tasks, rules, signatures or autoresponders.

There are a few hard limits. Items larger than 35 MB are skipped. A maximum of 500,000 items per mailbox is migrated. The source must allow IMAP over SSL and the admin either needs each user's password or an admin credential that the host supports for delegation, which GoDaddy and most cPanel hosts do not. In practice you reset passwords, run the migration, and reset them again.

Setting up the endpoint and batch

Create the users in Microsoft 365 with licenses first, since IMAP migration needs a target mailbox. Then build a CSV with three columns: EmailAddress, UserName and Password. The EmailAddress is the Microsoft 365 mailbox, the UserName is whatever the source server expects, which is normally the full email address for both GoDaddy and cPanel.

The server names differ per host. GoDaddy's legacy Workspace Email uses imap.secureserver.net on port 993. cPanel hosts use mail.yourdomain.com or the server's own hostname on port 993, and the certificate is often for the server hostname rather than your domain, which causes a TLS failure if you use the domain name. Use whatever the host's own IMAP client settings page shows.

1. Verify your domain in Microsoft 365 but do not change MX yet.
2. Create and license every user.
3. Build the CSV and test one row by hand.
4. Create the endpoint and a batch with the CSV, and start it.
5. Watch the batch until the initial sync reaches Synced for every user.
6. Switch MX and Autodiscover, wait for the final incremental sync, then complete the batch.

New-MigrationEndpoint -IMAP -Name GoDaddyIMAP -RemoteServer imap.secureserver.net -Port 993 -Security Ssl
New-MigrationBatch -Name GoDaddyBatch -SourceEndpoint GoDaddyIMAP -CSVData ([System.IO.File]::ReadAllBytes("C:\migration\imap.csv")) -AutoStart
Get-MigrationUser -BatchId GoDaddyBatch | Get-MigrationUserStatistics | Select Identity, Status, SyncedItemCount, SkippedItemCount, Error

The GoDaddy special cases

GoDaddy sells two different products that both say email. The older Workspace Email is a plain IMAP host and migrates as described. The newer Microsoft 365 from GoDaddy is a real Microsoft 365 tenant that GoDaddy resells and controls. You cannot IMAP migrate a GoDaddy-managed tenant into your own tenant cleanly, and you cannot simply take it over, because the domain is federated to GoDaddy's identity system.

The supported path for the GoDaddy-managed tenant is to defederate it: GoDaddy support removes their federation, you set new passwords for every user, and the tenant becomes yours to administer directly. If you would rather move to a fresh tenant, that is a tenant-to-tenant migration and needs either a third-party tool or a PST export and import.

POP mailboxes and mail that only exists on a PC

POP downloads mail and, by default, deletes it from the server. If a business ran POP for years, the server holds a few days of mail and the real archive is in an Outlook PST file or a Thunderbird profile on each computer. IMAP migration cannot see any of that.

The fix is client-side. For Outlook users, add the new Microsoft 365 account to the existing profile, then either drag folders from the old PST into the new mailbox or use File, Open and Export, Import to bring the PST in. For large PSTs, the Microsoft 365 network upload through the Purview compliance portal imports them server-side, which avoids a laptop doing 20 GB of uploads over Wi-Fi. Thunderbird users add the new account and drag folders across.

• Check each PC for PST files before the migration date: search for *.pst in the user profile and any mapped drives.
• Repair PSTs with scanpst.exe before importing. A corrupted PST fails halfway through an import.
• Set expectations: a 15 GB PST will take hours to upload from an office connection.
• Turn the old POP account off in the client only after the new account is working, so nothing is lost mid-switch.

The DNS switch and the last sync

Because IMAP migration keeps syncing until you complete the batch, the cutover is forgiving. Switch MX to Microsoft 365, and any mail that landed on the old host during propagation is picked up by the incremental sync, which runs about every 24 hours. Leave the batch open for a day or two after the DNS change, then complete it.

Set Autodiscover to Microsoft 365 at the same time so Outlook can build profiles, and add the SPF include for Exchange Online so the first messages out of the new tenant are not flagged.

Frequently asked questions

Takeaway

IMAP migration is fine for what it does: mail and folders from a legacy host into mailboxes you have already created. Plan separately for contacts, calendars and the PST archives that POP left behind on desks. Keep the batch open across the MX change, and the users see a slow copy rather than a hard switch.