Migrate Rackspace Email to Google Workspace (2026 Guide)

Rackspace's Cloud Office and Hosted Exchange tiers have been steadily losing customers since the 2022 ransomware incident, and most of the migrations land at Google Workspace. The mechanics look simple on paper — both sides speak IMAP, Google publishes a Data Migration Service, MX gets repointed — but the failure modes are specific: shared folders that don't carry over, archive tiers that IMAP can't see, throttling that kicks in at the worst moment, and aliases that quietly drop on cutover. This guide walks the full path with the numbers and the error messages you'll actually see.

What you're moving and what you're not#

Rackspace mailboxes look monolithic to a user, but they're composed of several distinct data planes. Plan for each one separately.

In the IMAP path: INBOX, custom folders, Sent, Drafts, Trash, Junk, and any shared mailboxes the user has subscribed to. Message bodies, attachments, internal date, and most flags carry across.

Outside the IMAP path: contacts and calendars (Rackspace exposes these through CardDAV/CalDAV on Cloud Office and via EWS on Hosted Exchange), distribution lists, mailbox aliases, sieve/server-side rules, vacation responders, and any Cloud Office Archiving retention vault.

The mistake admins make is assuming IMAP is enough. It's enough for mail — it isn't enough for the migration. You'll need a separate plan for contacts, calendars, and aliases, and you should write it down before you touch DNS.

Pre-flight: provisioning and DNS prep#

Before the first byte moves, get the Google side ready and lower your DNS TTLs.

Provision the Google Workspace tenant#

Sign up for Google Workspace, verify the primary domain with a TXT record (Google publishes a unique value per tenant), but leave MX records pointing at Rackspace for now. Verification only requires the TXT — it doesn't require MX changes, and confusing the two will cause you to cut over too early.

Create users in bulk via the Google Admin console's CSV import. Match the primary SMTP address exactly — firstname.lastname@yourdomain.com should map to firstname.lastname@yourdomain.com on Google. Mismatches break the migration and create headaches later when you have to merge mailboxes.

For aliases, capture them from the Rackspace control panel (Cloud Office: Users → Email → Aliases) and recreate them in Google as "Add an alternate email" on the user. Distribution lists become Google Groups; you'll have to recreate membership manually, which is one reason to export the Rackspace member lists to CSV before cutover.

Lower DNS TTLs#

24 hours before MX cutover, drop your MX record TTL to 300 seconds. This is the single highest-leverage thing you can do on cutover day — without it, you're at the mercy of recursive resolvers that may cache the old MX for hours.

Confirm IMAP is enabled#

On Rackspace Cloud Office, IMAP is on by default but can be disabled per-user. Check User → Mailbox Features for each migrating user. On Hosted Exchange, IMAP4 is enabled at the org level by default but may have been turned off in hardened tenants — verify in the Exchange control panel before you assume.

Choosing a migration method#

You have three real options, and most organizations end up using two of them in sequence.

Google Data Migration Service (DMS)#

Google's built-in tool. Free, runs server-side, supports IMAP source. It handles mail and only mail — no contacts, no calendars, no labels-to-folders translation in reverse. DMS works well for mailboxes under 10 GB and for organizations under 50 users. Above that, the lack of resumability and visibility starts to hurt.

DMS limitations to know:

• No incremental/delta migration after the first pass — re-runs duplicate messages.
• Single-threaded per mailbox; large mailboxes can take 24+ hours.
• Error messages are sparse; when a sync fails you often see "Migration failed" with no actionable detail.
• Skips messages over 35 MB by default (Google's inbound size limit applies).

Desktop IMAP migration tool#

Run a tool locally that authenticates to both sides over IMAP and copies messages folder-by-folder. This is where Mailbox Taxi fits. Desktop tools give you parallelism control, delta-sync support, detailed per-message logging, and the ability to pause and resume without restarting from scratch.

The tradeoff: you need a workstation with enough bandwidth and uptime to run for the duration of the migration. For a 25-user organization with 15 GB average mailbox size, that's typically 12–18 hours of run time. Plan for the machine to stay awake.

Hybrid: DMS for bulk, desktop tool for delta#

For larger orgs, run DMS for the bulk transfer 1–2 weeks before cutover, then use a desktop IMAP tool to catch the delta in the final 48 hours. DMS gets you 95% of the data for free, and the desktop tool handles the messages that arrived during DMS's blind spot.

Step-by-step migration#

1. Pilot two mailboxes end-to-end

   Pick one heavy user and one light user. Run the full migration on both — IMAP source, Google destination, folder mapping, the works. Time it. A heavy mailbox (20+ GB, 100K+ messages) will tell you your real per-GB throughput; a light mailbox tells you your per-mailbox overhead. You need both numbers to plan the bulk window.

   Validate after the pilot: log into the destination, check sent items, check folder counts, send a test message both directions, verify that the user's mobile client picks up the new account cleanly.

2. Generate Rackspace credentials

   Rackspace Cloud Office supports standard IMAP password auth — no app passwords required unless the user has 2FA enabled. For users with 2FA, generate an app-specific password from the Rackspace mailbox settings. Store credentials in a manager like 1Password or Bitwarden; do not paste them into a spreadsheet.

   For Hosted Exchange mailboxes, use the primary SMTP address as the IMAP username and the mailbox password. If the org uses ADFS or external IdP, you may need to create temporary local passwords on the mailbox — coordinate with whoever manages identity.

3. Run the bulk pre-sync

   Start the full migration 48–72 hours before MX cutover. At this stage, mail is still flowing to Rackspace, so every message that arrives during the sync window will be included. You're not done after this pass — you'll run a delta later — but the bulk gets the slow work out of the way.

   Cap concurrency at 2–4 threads per source mailbox. Higher concurrency triggers Rackspace's connection limits and you'll start seeing "Too many simultaneous connections" errors. The Google side can absorb far more parallelism, but the source dictates the pace.

4. Cut MX records to Google

   At your scheduled cutover time, update the MX records at your DNS provider to Google's published values (the priority-1 record is smtp.google.com. for current Workspace tenants — Google's admin console shows the exact records for your tenant, always copy from there).

   Verify propagation with dig MX yourdomain.com @8.8.8.8 and check at least three public resolvers. Send a test message from an external Gmail and Outlook.com account; confirm it lands in the Google mailbox within 60 seconds.

5. Run the delta sync

   48–72 hours after MX flipped, run a delta sync against each Rackspace mailbox. Some mail will still have landed on Rackspace from senders with stale DNS caches or aggressive resolver behavior; the delta sweeps those into Google. A good IMAP tool will use UID-based dedup so the delta doesn't reimport everything you already moved.

   If you set up a Rackspace-to-Google forwarder on each mailbox at cutover, the delta will be small. If you didn't, expect 0.5–2% of total volume to need this final pass.

6. Decommission Rackspace

   Once the delta is clean and users have validated, cancel the Rackspace subscription. Export your archived data first if you have Cloud Office Archiving. Keep DNS records (SPF, DKIM, DMARC) updated to reflect Google — leftover Rackspace include statements in SPF will cause SPF failures on outbound mail and tank your deliverability.

Specific issues you'll hit#

These are the recurring failure modes, with what to do about each.

"Too many simultaneous connections"#

Rackspace's per-mailbox connection ceiling is around 8–10. If you see this error, drop concurrency. The error doesn't permanently lock the account, but it does throttle that mailbox for 5–15 minutes. Aggressive retry loops make it worse, not better.

Folder name mismatches#

Rackspace's "Junk E-mail" doesn't auto-map to Google's "Spam" label. Most IMAP tools handle this with a folder map, but check your tool's defaults. Without an explicit map, you'll end up with a literal "Junk E-mail" label on Google sitting next to the real Spam label, which is confusing for users.

For details on how Google represents folders as labels under the hood, see our migrate IMAP to Gmail walkthrough — the same folder-to-label semantics apply here.

UTF-7 folder encoding#

If you see Folder UTF-7 conversion error in logs, that's the IMAP modified-UTF-7 encoding used for folder names with non-ASCII characters (common with French, Spanish, or accented folder names). Modern tools handle this correctly. Older tools and some custom scripts don't. If you wrote your own migration script, this will bite you.

Messages over 35 MB#

Google's inbound size limit applies to migration just like it applies to live mail. Messages over 35 MB will be rejected by the destination. Log them, attach the rejected count to your final report, and decide per-user whether to extract attachments and re-upload to Drive separately. Most users have a handful of these — usually old training videos.

Calendar and contact sync#

For Rackspace Cloud Office, contacts are accessible via CardDAV at contacts.emailsrvr.com and calendars via CalDAV. Export to vCard/iCal and import into Google Contacts and Google Calendar. For Hosted Exchange, EWS is the path — and depending on your tier, you may need PowerShell access. Plan an extra day for this if you have shared calendars.

Compare this with the Office 365 path if you're still deciding between destinations — calendar fidelity is notably better on the Microsoft side because of native EWS-to-EWS migration tools.

Cutover-day checklist#

Print this out. Tape it to the wall.

• T-24h: lower DNS TTL on MX to 300s.
• T-72h: bulk pre-sync started.
• T-1h: stop accepting changes in Rackspace (notify users).
• T-0: update MX to Google.
• T+10m: verify propagation with three public resolvers.
• T+15m: external test message lands in Google mailbox.
• T+1h: spot-check five user mailboxes for new mail flow.
• T+48h: delta sync.
• T+7d: cancel Rackspace subscription.

If you're coming from a single-user Rackspace setup or migrating just a handful of mailboxes, the simpler Rackspace to Gmail path will save you the Workspace admin overhead. For organizations weighing destinations, our Google Workspace migration guide compares the broader options, and the Rackspace to Outlook walkthrough covers the desktop-client side if users will continue on Outlook against Google's IMAP.

Post-migration validation#

The migration isn't done when the bytes move. It's done when you've validated.

Validate per-user:

• Folder count matches between source and destination.
• Message count per folder is within 1% (small drift is normal due to dedup).
• Sent items are intact and accessible from the Sent label.
• Latest 10 messages in INBOX are visible and readable.
• Mobile clients pick up the new account.

Validate per-tenant:

• SPF record includes _spf.google.com and excludes Rackspace.
• DKIM is enabled and signing outbound (Google publishes per-tenant DKIM keys).
• DMARC policy is reachable and reporting.
• All distribution lists (now Google Groups) deliver test messages correctly.

Once both checklists are green, you're done. Send the all-clear to the team and start the 7-day Rackspace decommission countdown.