How to Migrate Rackspace Email to Office 365

Rackspace Email customers usually move to Office 365 for one of three reasons: they want the rest of the Microsoft 365 productivity stack alongside mail, they have outgrown Rackspace's per-mailbox feature set, or Rackspace has changed their pricing in a way that no longer fits. The migration itself is mostly an IMAP copy, but Rackspace ships two distinct mail products under the same brand — Cloud Office and Hosted Exchange — and the right operational path depends on which one you have. This guide covers both, with a bias toward the more common Cloud Office IMAP source, and ends with a clean MX cutover and a decommissioned Rackspace tenant.

Identify which Rackspace product you are migrating from#

Rackspace's mail products look identical on the inside of a mail client but are very different on the wire. Confirming which one you have is step zero.

Rackspace Email (Cloud Office)#

• Sold as "Rackspace Email" or "Cloud Office Email".
• Mailboxes are hosted on secure.emailsrvr.com.
• IMAP and POP3 are the protocols. There is no native MAPI or Exchange Web Services connection.
• Pricing is per-mailbox per-month, traditionally with a 25 GB mailbox.
• Most small business Rackspace customers are on this product.

Rackspace Hosted Exchange#

• Sold as "Hosted Exchange" or "Rackspace Hosted Exchange".
• Mailboxes are hosted on Rackspace's Exchange infrastructure with a different hostname pattern per region.
• Outlook desktop clients connect via Autodiscover and use MAPI over HTTPS.
• Pricing is per-mailbox per-month at a higher tier than Cloud Office, with larger default mailboxes.

To confirm, log in to the Rackspace control panel at cp.rackspace.com and look at the product label next to the domain. If you are not the admin, ask the customer to send a screenshot of the product card.

The rest of this guide focuses on Cloud Office migrations, since they are the more common case and the IMAP path is also viable as a fallback for Hosted Exchange when richer options are unavailable. For Hosted Exchange specifically, the Exchange to Office 365 guide covers the richer remote-move path and is the better starting point if you want to preserve full metadata.

What you need before you start#

Destination prerequisites (Office 365)#

• Your custom domain is verified in Microsoft 365 and DNS ownership is confirmed.
• Each destination user has a license that includes Exchange Online (Business Standard, Business Premium, E3, E5, or similar).
• Mailboxes exist in Exchange Online with the correct primary SMTP address. Users created without a mailbox or with the wrong UPN fail batch entry with a RecipientNotFound error.
• You are signed in as a Global Administrator or have the Recipient Management and Organization Management roles assigned in Exchange Online.

Source prerequisites (Rackspace Cloud Office)#

• You have either the password for each Rackspace mailbox or admin impersonation credentials that can authenticate against any mailbox in the tenant.
• IMAP access is enabled on the Rackspace side. It is on by default for Cloud Office.
• You have audited source mailbox sizes via the Rackspace control panel and confirmed that no mailbox exceeds the destination Microsoft 365 quota.
• You have a copy of the Rackspace mailbox list in CSV form, exported from the control panel.

Why Rackspace to Office 365 has its own shape#

Even though this is just another IMAP-to-Microsoft-365 batch on paper, Rackspace brings four operational details that shape the project.

• Two products, one brand. As covered above, Cloud Office and Hosted Exchange are different beasts. Confirm which one you have before touching anything else.
• secure.emailsrvr.com is shared infrastructure. Throttling thresholds shift over time and are not documented. Stay conservative on concurrency for the first hour of any batch and adjust based on what you see.
• Mailbox sizing varies a lot. Rackspace's default mailbox quota is 25 GB on Cloud Office, but enterprise customers often have 50 GB or 100 GB add-ons. Audit before you build batches — an oversized source mailbox stops syncing mid-batch with Quota exceeded if the destination is too small.
• MX cutover is the only delivery switch. Rackspace does not offer a hybrid coexistence path with Office 365. You move mail with IMAP, then flip MX at the registrar, and Rackspace stops being authoritative for delivery from that moment.

For a broader framing of the EAC migration model and how to size batches, the IMAP to Office 365 guide walks through the same concepts that apply here.

Step-by-step migration#

1. Identify the Rackspace product

   Log in to the Rackspace control panel at cp.rackspace.com. Look at the product type assigned to the domain. If it says "Rackspace Email" you are on Cloud Office and this guide applies as written. If it says "Hosted Exchange", consider whether the richer Exchange-based migration path is open to you before defaulting to the IMAP route. The office-365-migration-guide is a useful primer on choosing between paths.

2. Prepare the destination tenant

   Verify your domain in Microsoft 365 and confirm DNS ownership. Assign Exchange Online licenses to every destination user and confirm mailboxes exist in Exchange Online with the correct primary SMTP address. Lower the MX TTL for the domain to 300 seconds at least 24 hours before the planned cutover. Confirm you have the Recipient Management role in Exchange Online — you cannot create or run migration batches without it.

3. Collect credentials and mailbox sizes

   From the Rackspace control panel, export the mailbox list to CSV. For each mailbox, capture the email address and either the mailbox password or admin impersonation credentials. Rackspace offers an admin-level "migrator" credential for Cloud Office that can authenticate against any mailbox on the tenant — if available, this is much easier than collecting per-mailbox passwords. Audit mailbox sizes in the same export and flag any that approach the destination quota.

4. Build the CSV manifest

   The EAC IMAP migration wizard expects a CSV with three columns: EmailAddress (the destination Microsoft 365 address), UserName (the Rackspace mailbox address or admin impersonation form), and Password (the Rackspace password or admin password). Save the file as UTF-8 to avoid InvalidCsv errors during import. Keep one mailbox per row and avoid header padding spaces.

5. Create the IMAP migration endpoint

   In the Exchange admin center, go to Migration, then Endpoints, and select New. Choose IMAP. Set the IMAP server to secure.emailsrvr.com, port 993, security SSL. Leave authentication on Basic. Set the maximum concurrent migrations conservatively for the first batch — 5 to 10 is a sensible starting point. Set the maximum concurrent incremental syncs slightly lower. Save and confirm the test connection succeeds.

6. Run a pilot batch

   Create a new migration batch from the IMAP endpoint with your CSV but include only one or two pilot mailboxes. Accept the default folder mappings unless you know you need overrides. Let the batch reach Synced. Open the destination mailbox in Outlook on the web and verify:

   • Folder counts match between Rackspace and Office 365.
   • Sent maps to Sent Items and not a custom folder called Sent.
   • Junk and Trash map to Junk Email and Deleted Items via the endpoint mappings.
   • Attachments open cleanly and inline images render.
   • Read state matches.

   Only proceed once a pilot mailbox is clean. Fixing issues at scale is far more expensive than fixing them on one account.

7. Schedule full-mailbox batches

   Split remaining mailboxes into batches of 20 to 50 and stagger start times by 30 to 60 minutes. Monitor the per-mailbox status in the EAC migration dashboard. Watch for Too many simultaneous connections or STARTTLS handshake failed and drop concurrency if either is repeated. Allow incremental syncs to run on each batch until the day of cutover so newly arrived mail is captured automatically.

8. Cut over MX and decommission

   Once every batch is in Synced state and the most recent incremental sync is clean, update the MX record at your DNS provider to point at the Office 365 endpoint (<tenant>.mail.protection.outlook.com). Watch inbound mail in Exchange Online for the first hour. Once you are confident new mail is landing, complete each migration batch in EAC to stop incremental syncs. Wait at least 14 days before closing the Rackspace mailboxes so you have a documented rollback window. Archive the migration report CSVs. The complete email migration guide has a usable decommissioning checklist worth adapting.

Rackspace-specific gotchas#

These are the issues that come up over and over on Rackspace projects. None of them is a blocker if you plan for them.

secure.emailsrvr.com throttling behaviour#

Rackspace does not publish IMAP throttle limits, but the infrastructure is shared across many tenants and behaves accordingly. The first sign of trouble is Too many simultaneous connections appearing on a few mailboxes in a batch, then more, then the whole batch. Drop endpoint concurrency by half when you see the first repeat and let Exchange Online retry on its own schedule.

Folder name collisions#

Rackspace uses Sent (singular) for the sent folder name historically, while Office 365 uses Sent Items. The default IMAP migration creates a separate Sent folder in the destination unless you set the mapping. Same applies for Trash and Junk. Set the mappings on the endpoint advanced properties before the pilot batch, not after.

Aliases and distribution lists#

Rackspace distribution lists are separate objects from mailboxes and do not migrate via IMAP. You have to recreate them as Microsoft 365 distribution groups in Exchange Online before MX cutover. Same applies for catch-all addresses, which become a transport rule in Exchange Online.

Mobile clients after cutover#

Cloud Office users frequently have ActiveSync configured on phones. After MX cutover, those clients keep trying to fetch from Rackspace and the user thinks new mail has stopped arriving. Walk users through reconfiguring their phone client to Microsoft 365 before the cutover, not after.

Hosted Exchange edge cases#

If you do end up migrating Hosted Exchange via IMAP because the richer options are not available, expect to lose calendar items, contacts, and most server-side rules. They live outside the IMAP store. Set expectations explicitly with the customer.

Errors you will actually see#

• AUTHENTICATIONFAILED — the password in the CSV is wrong, or admin impersonation is not enabled. Reset the password or enable impersonation on the Rackspace side.
• Too many simultaneous connections — Rackspace throttled the source. Drop endpoint concurrency and let Exchange Online retry.
• STARTTLS handshake failed — the endpoint is configured on port 143 with STARTTLS rather than port 993 with implicit SSL. Recreate the endpoint with the correct settings.
• Folder UTF-7 conversion error — a folder name uses characters the legacy IMAP folder encoding does not support. Rename the source folder and let the next incremental sync pick it up.
• Message too large for destination — the source message exceeds Exchange Online's 150 MB receive limit. Skip and log; rarely worth a manual recovery.
• Quota exceeded — the destination mailbox filled up. Either assign a license with a larger mailbox or archive part of the source before re-running.

Communication plan for users#

Rackspace customers are usually small business or mid-market teams where one or two non-technical people own the day-to-day mail experience. Communication matters more than usual.

• Send a kickoff note 7 days before cutover. Include the cutover date and time, what changes, and what users should do in the meantime.
• Send a reminder 24 hours before cutover. Mention that the desktop and mobile clients need to be reconfigured to Microsoft 365.
• Send a "we have started" note when MX is updated. Include the Outlook on the web URL and a one-line how-to.
• Send a follow-up 48 hours after cutover asking whether anything looks off. Most issues that become tickets in week two would have been caught with this email.

If you want a reusable template, lift the section from the complete email migration guide and adapt it.

When to use Mailbox Taxi instead#

EAC IMAP batches are the right answer for tenant-scale Rackspace Cloud Office moves with a competent admin running the project. They are overkill for single-mailbox personal migrations and they assume you have admin access to the Microsoft 365 tenant. Mailbox Taxi runs locally on the user's machine, handles the Rackspace IMAP source with the same connection string, and is a better fit when the operator is also the end user — for example a sole trader leaving Rackspace for a Microsoft 365 Business Standard subscription with one mailbox.