To migrate IMAP email to Microsoft 365, you create your users and assign licences in Microsoft 365 first, build a CSV file of mailbox credentials, set up an IMAP migration endpoint in the Exchange admin centre, run the migration batch, then switch your MX record once all mail has copied across. The process is admin-led, runs in the background while your current email keeps working, and typically takes a few hours to a few days depending on how many mailboxes and how much stored email you have. If you are moving your South African business from shared hosting, a local IMAP provider, or any email system that is not Microsoft Exchange, IMAP migration is the correct path — and it differs meaningfully from the options available when you migrate from Exchange or upgrade your entire digital setup from a DIY website builder.

Most South African businesses on hosted email — cPanel, Horde, Zimbra, or a custom domain through a local ISP — are running IMAP-based mailboxes. When a business decides to move to Microsoft 365 for better reliability, collaboration tools, or data residency assurances, IMAP migration is the standard tool. Understanding what it does and does not carry across matters: email and folder structure copy cleanly, but contacts, calendar entries, and tasks do not — and that catches businesses off guard if they have not planned for it. This guide covers the decision table, the step-by-step process, and the South African considerations — data residency, POPIA and load-shedding timing — that global guides tend to skip entirely. If you are comparing platforms before committing, the Google Workspace vs Microsoft 365 Business comparison is a useful starting point.

Quick Answer

To migrate IMAP email to Microsoft 365, you need to create M365 users first, then use the Exchange admin centre (EAC) to set up an IMAP migration endpoint pointing at your source server, upload a CSV file with mailbox credentials, run the migration batch, and finally switch your MX record to Microsoft 365. Only email is migrated this way — contacts, calendar events and tasks must be moved separately. Microsoft launched data centres in Johannesburg and Cape Town in 2019; new SA tenants provisioned with a South African billing address have their Exchange Online data stored in those local facilities by default — verify your current data location in the Microsoft 365 admin centre under Settings > Org settings > Microsoft 365 data location.

Hands-off migration or tight deadline?

Send us your current hosting setup and the number of mailboxes — we will map the fastest migration path and flag anything that needs attention before you touch the MX record.

Get a free migration assessment

Which Migration Method Should You Use?

The right migration method depends on your current email platform — and for Exchange Server environments, also on your mailbox count. Microsoft offers four main paths, and only one applies to businesses currently on a non-Exchange IMAP system.

Current email systemTypical sizeRecommended methodMigrates contacts & calendar?
Hosted IMAP (cPanel, Horde, Zimbra, ISP mailbox, Rackspace)AnyIMAP migrationNo — manual export/import required
Gmail / Google WorkspaceAnyIMAP migration or Google Workspace pathNo via IMAP; use Google Workspace migration for full data
Exchange Server 2003–2013 (under 150 mailboxes)SmallCutover migration (formal ceiling 2,000; Microsoft recommends 150 or fewer in practice due to migration duration)Yes
Exchange Server 2010 (150–2,000 mailboxes); Exchange 2013 or later (any size)Mid–LargeHybrid or Express migrationYes
Exchange Server 2003 / 2007 (2,000+ mailboxes)LargeStaged migrationYes

The key distinction: Exchange-to-Exchange migrations can move email, contacts, and calendar data in a single operation. IMAP migration moves email only. If your business is on hosted cPanel or a local IMAP provider, IMAP migration is your tool — and you plan the contacts and calendar separately.

Key Point

IMAP migration is the correct method when your source system is not running Microsoft Exchange. If you are on shared hosting, cPanel, a local ISP mailbox, or any IMAP-enabled system, this is your path — but it moves email only. Contacts and calendar data need a separate export/import step.

What Migrates — and What Does Not

IMAP migration copies all email from a user's inbox and mail folders to their new Microsoft 365 mailbox, but it does not touch anything that is not a stored email message. Understanding this before migration day prevents unpleasant surprises.

ItemMigrated via IMAP?What to do
Emails (inbox and all mail folders)✓ YesMigrated newest to oldest, up to 500,000 items per mailbox
Contacts✗ NoExport as CSV or vCard from your old system; import to Outlook or Microsoft 365
Calendar events✗ NoExport as ICS file; import to Outlook calendar
Tasks✗ NoManual re-entry or use a third-party migration tool
Individual emails over 35 MB✗ NoDownload large attachments locally before migration; re-attach after

Before migration day: Ask each user to export their contacts and any calendar events from the old system. This takes under ten minutes per user and avoids the most common post-migration complaint — missing contacts. The export/import process is separate from the IMAP migration batch and does not affect your email cutover timing.

Prerequisites Before You Start

Preparing the environment correctly prevents the most common IMAP migration failures — authentication errors, missing mailboxes, and mail delivery gaps during the MX record switch.

Work through this checklist before you create a single migration batch:

  • Domain ownership verified. Add and verify your custom domain in the Microsoft 365 admin centre. If you skip this step, you cannot use your existing email addresses in M365.
  • Users created and licences assigned. IMAP migration does not create Microsoft 365 mailboxes — you must add each user first and assign a licence that includes Exchange Online (Business Basic or higher). Mailboxes that do not exist in M365 before the batch runs will simply be skipped.
  • Source mailbox passwords known or reset. The migration CSV file needs either each user's password or admin-impersonation credentials for your source IMAP server. If your host supports admin-level impersonation (some do, many do not), you avoid resetting individual passwords. If not, reset to temporary passwords, use them in the CSV, and communicate new credentials to users after migration.
  • Archival and MRM policies disabled on source server. Microsoft strongly recommends disabling any messaging records management or automatic archiving on your source system before the migration starts. These policies can move or delete messages during the copy process, making it appear as if data was lost when it was actually moved by the policy.
  • IMAP access enabled on source server. Most hosting providers enable IMAP by default, but confirm this in your hosting control panel. You will also need the IMAP server's fully qualified domain name (FQDN) for the migration endpoint.
  • MX record TTL lowered in advance. At least 48 hours before your planned MX switch, lower your domain's MX record TTL to 3,600 seconds (one hour) or less. This reduces the propagation window when you make the final cutover and minimises mail delivery delays.
  • Contacts and calendar exported. Do this before the migration, not after. It can be done in parallel with the email migration and gives users their full data set from day one in Microsoft 365.

How to Migrate IMAP Email to Microsoft 365 — Step by Step

For IMAP email migration Microsoft 365 uses the Exchange admin centre (EAC) — the general admin centre IMAP path was deprecated and now redirects there. The steps below follow the Microsoft Exchange migration documentation (updated July 2026). An IMAP email migration to Microsoft 365 uses a migration endpoint — a saved connection profile pointing at your source server — rather than a direct server-to-server trust, which is why the setup sequence differs from an Exchange-to-Exchange migration.

Step 1 — Create your Microsoft 365 users and assign licences

In the Microsoft 365 admin centre, go to Users > Active users and add each person who needs a mailbox. Assign them an M365 licence that includes Exchange Online (Business Basic at a minimum). Without this step completed first, the migration batch has no destination to write email into.

Step 2 — Build the migration CSV file

Open Excel and create a spreadsheet with exactly three column headers in row 1: EmailAddress, UserName, Password. One row per mailbox. EmailAddress is the M365 address; UserName is the login credential for the source IMAP mailbox (often the full email address on hosted systems); Password is the current password for that source mailbox. Save as a .csv file. The file can hold up to 50,000 rows and up to 10 MB.

Step 3 — Create the IMAP migration endpoint

In the Exchange admin centre, navigate to Migration > Endpoints. Click Add, choose IMAP as the migration type, and enter your source server's FQDN (e.g., mail.yourhostingprovider.co.za or imap.yourdomain.co.za). Leave the port and security settings at defaults (port 993, SSL) unless your host requires different settings. Save the endpoint — you will select it when creating the migration batch.

Step 4 — Create and start the migration batch

In the EAC, go to Migration and click Add migration batch. Name the batch (no spaces), select Migrate to Exchange Online, then select IMAP migration as the type. Select your endpoint from the dropdown, upload your CSV file, configure any folder filtering if needed, and save. Start the batch immediately or schedule it for an off-peak window — for load-shedding-aware SA businesses, aim for a period with at least four uninterrupted hours of power and connectivity.

Step 5 — Monitor progress and verify

The migration dashboard shows each mailbox's status in real time. Once completed, ask a few users to sign in to Microsoft 365 and confirm their email folders are intact. Email is copied incrementally — the batch continues syncing new messages from the source until you stop it, so there is no need to rush the verification step.

Step 6 — Switch your MX record to Microsoft 365

When you are ready to cut over, update your domain's MX record to point at Microsoft 365 (your M365 setup wizard shows the exact value to use). Because you lowered the TTL in Step 0 of your pre-migration prep, the change propagates to most mail servers within one hour. New inbound mail will start arriving directly in Microsoft 365 mailboxes. Mail that arrives at the old system during propagation is not automatically forwarded — this is why the reduced TTL matters.

Step 7 — Wait 72 hours, then stop synchronisation

Microsoft recommends waiting at least 72 hours after the MX switch before deleting the migration batch. This ensures that any external mail servers that cached your old MX record have had time to refresh, and that at least one incremental sync cycle has completed. After 72 hours with no new delivery issues, delete the migration batch in the EAC to stop ongoing synchronisation between the old and new systems.

Step 8 — Communicate with users and decommission old mailboxes

Send a brief note to staff with their new Microsoft 365 sign-in details and Outlook setup instructions. Once everyone has confirmed access, decommission the old mailboxes with your previous hosting provider. Keep the old accounts active for a short buffer period (a week is reasonable) in case anyone finds a gap.

Migration Timing

The actual data copy happens in the background while your current email keeps running. Only the MX switch causes any change in where new email arrives — and with a 1-hour TTL in place, that window is short. Schedule the MX change for a weekday morning when your team is available to confirm email is flowing correctly.

South African Considerations for Microsoft 365 Email Migration

When you migrate email to Microsoft 365 South Africa as a destination, a few local factors need attention that global guides skip. Before you move IMAP mailbox to Microsoft 365, these three considerations are worth working through explicitly.

Data residency and Microsoft's SA data centres

Microsoft launched data centres in Johannesburg and Cape Town in 2019. Any Microsoft 365 tenant registered with a South African address has its Exchange Online data stored in those South African facilities by default — you do not need to request this or pay a premium. This directly addresses the data residency question that arises when businesses consider moving off a local hosting provider: your email data does not leave the country. Verify your specific data location in the Microsoft 365 admin centre under Settings > Org settings > Microsoft 365 data location.

POPIA and cross-border data transfer

South Africa's Protection of Personal Information Act (POPIA) section 72 governs when personal information may be transferred out of the country. Because Microsoft stores SA tenant data locally and holds a data processing agreement with customers (meeting the section 21 operator-agreement requirement), the primary POPIA cross-border concern does not apply to standard Microsoft 365 deployments. That said, POPIA's accountability principle means you as the responsible party remain accountable for personal information in your mailboxes regardless of where it is stored — so access controls and retention policies in M365 matter as part of ongoing compliance, not just the migration itself. Engage your legal adviser if your business processes special categories of personal information (health data, biometric records) at scale.

Load-shedding and migration timing

IMAP migration batches can tolerate short interruptions — the process resumes from where it left off when connectivity restores. However, the critical moments — particularly the MX record switch and the post-switch verification window — need consistent connectivity. Check the Eskom schedule before committing to a cutover time and avoid stages 4+ during your planned MX switch. An uninterruptible power supply (UPS) or mobile data backup for your admin workstation during the MX update step is worth the ten minutes of preparation.

Microsoft 365 plans and pricing in South Africa

Microsoft 365 is sold through Cloud Solution Providers (CSPs) in South Africa, so the rand price reflects both Microsoft's list price and your CSP's margin. Based on current SA reseller listings, Microsoft 365 Business Basic — which includes Exchange Online, Teams, and 1 TB OneDrive storage — typically starts from approximately R105 per user per month on an annual commitment, with the actual rate varying by CSP and exchange rate. Business Standard (which adds desktop Office apps) runs at approximately R219 per user per month. Check the Microsoft South Africa pricing page for the current official figure before committing — CSP margins and exchange rate movements mean published third-party figures may lag.

Monthly billing adds a premium over the annual commitment. For most SA SMEs on shared hosting, Microsoft 365 Business Basic represents a modest cost increase that includes Teams, OneDrive, and the collaboration tools that most cPanel email plans do not.

Not sure which M365 plan fits your team?

Share your team size and current setup — we'll tell you which plan covers your needs and what the migration will realistically involve.

Get a plan recommendation

Why South African Businesses Work with Growth Pulse Media for Email Migrations

South African businesses using Growth Pulse Media for email migration get senior-led execution across every step — DNS preparation, migration endpoint configuration, MX record cutover, and post-migration verification — with all work executed in-house and no outsourced handoffs. Dirk van Greuning built and scaled a South African ecommerce business before founding the agency, which means the decisions that come through the door are assessed by someone who has dealt with the hosting, DNS and email infrastructure that SA SMEs actually face.

When businesses come to us for help with email migration to Microsoft 365, we are assessing the full digital setup: whether the existing web design and hosting arrangement creates DNS complications, whether the domain registrar used (common local registrars sometimes have slow propagation or non-standard MX record formats) needs specific handling, and whether the business's existing email volume and folder structure requires any pre-migration cleanup before the IMAP batch runs.

We work with a deliberately limited client load to make sure migrations get senior attention at each step. We keep all work in-house, which matters when your MX record and mail flow are on the line. If you need help moving from a local IMAP host to Microsoft 365 — or you need someone to assess the DNS, domain, and hosting situation first — the starting point is the same: a no-obligation conversation via our contact page. We typically respond within 24 hours.

Who This Is NOT For

Businesses already on Microsoft Exchange on-premises. If your organisation runs an on-premises Exchange server, IMAP migration is the wrong tool. Cutover, staged, or hybrid migration preserves contacts, calendar, and task data that IMAP migration cannot touch. Get the right method from the Microsoft migration advisor or an Exchange specialist.

Who This Is NOT For

Businesses that need contacts and calendar data migrated automatically. IMAP migration is email-only. If your team has extensive shared contacts, recurring calendar entries, or task workflows that live in their email client, they will need to export and import those manually — or you need a third-party migration tool. Know this before the migration window, not after.

Who This Is NOT For

Operators who want to skip the preparation steps. IMAP migration without domain verification, pre-created M365 mailboxes, and a lowered MX TTL routinely results in mail delivery gaps and migration batch failures. The process is straightforward when the prerequisites are in place; it is painful when they are not. If you do not have time to work through the pre-migration checklist, get a provider to do it.

Who This Is NOT For

Businesses whose primary email compliance concern is a local server in their own building. If your sector or your interpretation of your obligations requires on-premises email storage, Microsoft 365 — even with South African data centres — may not satisfy that requirement. Microsoft 365 is a cloud service. Confirm with your legal or compliance adviser before migrating if this is a live concern.

Ready to move your mailboxes?

Tell us how many mailboxes you are migrating and which platform you are moving from — we will outline the migration sequence and flag any risks before you start.

Start the conversation

Frequently Asked Questions

How long does it take to migrate IMAP email to Microsoft 365?

The time depends on your mailbox count and total data volume. A small business with five to ten mailboxes typically completes the copy phase within a few hours; larger migrations extend this to one to four days. The copy runs in the background while your current email keeps working — you do not need to take the business offline, only the final MX record switch requires a brief coordination window.

Will my email folders and subfolder structure be preserved?

Yes. IMAP migration copies items from a user's inbox and all mail folders, which preserves your existing folder structure in the new Microsoft 365 mailbox. Emails within those folders migrate newest to oldest, up to a maximum of 500,000 items per mailbox. The folder hierarchy you built in your old client comes across intact; users do not need to reorganise from scratch.

What happens to email that arrives during the migration?

During the migration batch phase, your MX record still points at your old email system, so new inbound mail arrives there and is also included in the ongoing sync. The batch continues copying until you stop it. After you switch the MX record to Microsoft 365, new mail goes directly to M365; any mail that arrives at the old system during the propagation window (which can be up to 72 hours without a lowered TTL, or roughly one hour with a TTL of 3,600 seconds) will not be automatically forwarded. This is why lowering the TTL before migration day and waiting for propagation confirmation matters.

Does Microsoft 365 store my SA business's email data in South Africa?

Microsoft launched data centres in Johannesburg and Cape Town in 2019, and new tenants provisioned with a South African billing address have their Exchange Online data stored in those local facilities by default. This addresses the main data residency question for businesses concerned about POPIA section 72 obligations, since the data does not leave the country under a standard SA M365 tenant configuration. Verify your specific data location in the Microsoft 365 admin centre under Settings > Org settings > Microsoft 365 data location.

Can I migrate IMAP email to Microsoft 365 myself, or do I need a provider?

The process is technically accessible to any competent IT admin — the prerequisites and batch wizard in the Exchange admin centre are well-documented by Microsoft. Where SA businesses typically need outside help is in DNS configuration with local registrars (which sometimes have non-standard MX record interfaces) and troubleshooting CSV credential errors in the migration batch. For under 20 mailboxes with a clean setup, self-directed migration is reasonable; larger or more complex migrations benefit from a managed approach.

Migrate Your Business Email to Microsoft 365 — Done Right

Growth Pulse Media handles Microsoft 365 email migrations for South African businesses — including DNS and domain configuration, migration batch setup, MX record cutover, and post-migration verification. All work executed in-house by senior operators, not juniors following a checklist. No obligation — we'll get back to you within 24 hours.

Request a free migration assessment
Dirk van Greuning — Founder, Growth Pulse Media
Dirk van Greuning Founder, Growth Pulse Media

Founder of Growth Pulse Media and a specialist in South African search dominance. Dirk translates his experience in scaling South African businesses into high-velocity digital strategies for B2B and retail leaders. He writes about SEO, lead generation, and paid media from an operator's perspective — prioritising pipeline value over impressions.

Connect on LinkedIn