Migrating from cPanel / shared hosting over IMAP — what do I need before starting?

Question

We have about 12 mailboxes sitting on an old cPanel host that we have been with for a decade. I want to move everything to Microsoft 365. I have the cPanel login but I am not sure what else I need to gather. What should I have ready before I start?

Marcus T. · Accepted Answer

IMAP migrations are the most straightforward kind once access is set up correctly. At 12 mailboxes this is a short project. Gather these before you begin:

- **The IMAP hostname.** Usually `mail.yourdomain.com`, but on older cPanel boxes it is sometimes the server hostname directly. cPanel shows the correct value under Email Accounts → Connect Devices.

- **Port and encryption.** Use 993 with SSL/TLS. Port 143 exists but sends credentials in cleartext unless STARTTLS is negotiated. If your host only offers 143 without STARTTLS, that is a strong signal it is time to leave.

- **Per-mailbox passwords.** This is the part that catches people. IMAP has no delegated admin access — you need each individual mailbox password, not just the cPanel account password. In cPanel you can reset each one from Email Accounts, which is usually faster than collecting them from users.

- **The folder prefix.** Some servers namespace everything under `INBOX.` so that Sent appears as `INBOX.Sent`. Getting this wrong produces a nested mess where every folder ends up inside the inbox.

- **The concurrent connection limit.** Shared hosts commonly cap you at 5–10 simultaneous IMAP connections per account and will start refusing connections beyond it. Worth knowing in advance so you can throttle rather than discover it as a wall of failures.

Rachel K. · Answer

The per-mailbox password point is the one I would have missed — I assumed cPanel admin access covered it. Resetting all 12 now.

One more: our host disconnects long sessions. Is that going to break a migration halfway through?

Marcus T. · Answer

It should not, and this is worth understanding because it separates a robust migration from a fragile one.

Aggressive idle timeouts are normal on shared hosting. A migration that treats a dropped connection as a fatal error will fail constantly on these hosts. The correct behavior is to catch the disconnect, reconnect, and resume from the last confirmed item — not restart the folder from the beginning.

Because every item is tracked individually and matched by a content fingerprint, resuming after a drop does not re-copy what already transferred and does not create duplicates. In practice you will see the transfer pause for a few seconds and continue. You do not need to babysit it.