Email migration sits at the intersection of visibility and risk. It's the most visible system you'll touch-every single employee checks email dozens of times a day. Mess it up, and you erode trust before you've even migrated a single CRM record or financial report. Yet get it right, and you've delivered a tangible, day-one win that demonstrates you know what you're doing.
The brutal reality is this: email migration after acquisition should be your first integration move, not your last. It's visible, fast, and establishes security and control faster than any other system. For roll-ups consolidating 3-10 acquisitions, email migration typically takes 6-8 weeks from audit to cutover-faster than CRM, ERP, or operational systems.
This guide covers the decisions, sequence, and execution details for migrating email and collaboration tools post-acquisition. You'll get timing windows, platform decisions, a phase-by-phase playbook, and the pitfalls that derail 40% of migrations in the first fortnight.
Why Email Migration After Acquisition Is Not Optional
Email isn't just communication-it's identity, access, security posture, and your first impression of competence to an acquired team. Here's why it can't wait:
Security and compliance baseline. Acquired companies often run outdated systems-on-premises Exchange 2010, legacy POP3 accounts, Gmail accounts tied to personal credit cards. Every day of delay is a day of shadow IT, weak authentication, and legal exposure. Unified email means you can enforce MFA, audit trails, and data loss prevention policies within weeks, not quarters.
Visibility to the business. Email migration is the only integration project every employee experiences directly. Do it well and quietly, and you've built trust. Botch it-lost emails, broken calendars, missing contacts-and you've damaged confidence before you've touched a single operational system.
Fast, tangible win. Compared to ERP or CRM unification, email migration is fast. A 50-person acquisition can be migrated mailbox-to-mailbox in under two months, including audit, testing, cutover, and hypercare. That's a confidence builder for leadership and proof that integration won't drag on indefinitely.
Bundled collaboration tools. Google Workspace and Microsoft 365 aren't just email-they're shared drives, calendars, contacts, document collaboration, and chat. Migrating email opens the door to broader consolidation of file storage and workflows without separate projects. If you defer email, you also defer file storage rationalisation, and suddenly you're supporting three different collaboration stacks a year later.
Cost control. Legacy systems cost money-whether that's on-prem Exchange CALs, ageing hardware, or per-user SaaS licenses. Consolidating onto a single platform cuts vendor sprawl and gives you volume pricing negotiating power. It's common to find duplicate Microsoft 365 licenses across acquisitions because nobody has audited entitlements — sometimes dozens of wasted seats across three or four entities.
Not migrating email isn't neutrality-it's a decision to live with fragmented identity, duplicated cost, and persistent security risk. Deciding not to integrate is still a decision.
The Three Email Migration Scenarios in M&A
Every acquisition lands in one of three patterns. Recognising yours up front determines your timeline, tooling, and risk profile.
Google Workspace Migration M&A: What You Need to Know
Google Workspace migrations typically involve moving from on-premises Exchange, legacy hosting providers (like 1&1, GoDaddy email), or even personal Gmail accounts to a managed Google Workspace domain.
What migrates cleanly: Email, contacts, calendar events (with caveats-recurring events sometimes need manual reconciliation). Google's native migration tools handle IMAP sources well, including Exchange via IMAP or Google Workspace Migrate.
What doesn't: Google Docs, Sheets, and Slides created in one Workspace domain cannot be bulk-migrated to another while preserving sharing permissions and edit history. You're forced to either manually share across domains (clunky and insecure), export to Office formats (breaks live collaboration), or rebuild shared drives post-migration.
Real Talk: If the acquired company was already on Google Workspace and you're consolidating into your Google Workspace, expect friction. Google's cross-tenant migration tooling lags behind Microsoft's. Budget extra weeks for shared drive consolidation, permission mapping, and user retraining. It's not uncommon for roll-ups to leave an acquired Workspace domain running semi-independently for six months rather than force a painful Drive migration during peak season.
Microsoft 365 Migration Merger: Platform Consolidation Realities
Microsoft 365 migrations are the most common path-either consolidating acquired Exchange environments into your Microsoft 365 tenant, or moving from on-prem Exchange to cloud.
Three migration methods:
- Cutover migration – All mailboxes move in a single weekend. Works for <150 users. Fast but risky: any issue affects everyone simultaneously.
- Staged migration – Batches of users migrate over weeks. Reduces risk, enables piloting, but requires dual-running support and clear communication about who's moved when.
- Hybrid migration – On-prem and cloud coexist long-term. Best for 500+ users or complex Active Directory environments, but overkill for most roll-ups.
For post-acquisition scenarios, staged migration is the sweet spot. You can pilot with IT and a handful of power users, learn what breaks, fix it, then migrate the rest in controlled waves.
Cross-tenant mailbox migration (moving users from one Microsoft 365 tenant to another) is now a native feature in Exchange Online. It's faster and cleaner than it was five years ago, but calendar sharing, delegate permissions, and SharePoint/OneDrive links often need manual reconciliation.
Cross-Platform Migration: Google to Microsoft or Vice Versa
Cross-platform migrations-Google Workspace to Microsoft 365 or the reverse-are where things get interesting (and expensive).
The Conversion Trap: Files created in one ecosystem don't survive migration cleanly. Google Docs forced into Office 365 lose live collaboration, break embedded links, and sometimes corrupt complex formatting. Office files stored in SharePoint and moved to Google Drive lose metadata, version history, and sometimes filenames with special characters.
You'll need third-party migration tools-BitTitan MigrationWiz, SkyKick, or CloudM-and budget 20-30% more time for testing, file conversions, and user training. Users accustomed to Google Docs will resist Outlook's calendar interface: Outlook loyalists will hate Google Drive's sharing model.
The practical approach: If both companies are already consolidated onto different platforms (you're Microsoft, they're Google), evaluate whether full integration is worth the pain. Consider a system migration strategy that defers email consolidation and prioritises CRM, finance, and operational alignment first. In one common scenario, a landscaping roll-up left a 12-person acquisition on Google Workspace for 18 months because forcing them onto Microsoft would have cost more in productivity than the acquisition contributed in EBITDA.
When to Migrate Email: Timing Windows That Actually Work
Timing email migration isn't just about your project plan-it's about the acquired company's calendar, peak workload, and psychological readiness.
Ideal window: 4-12 weeks post-close. This gives you time to audit their environment, secure leadership buy-in, and plan properly-but moves fast enough that the acquired team still expects change. Wait six months and they've settled back into business-as-usual: forcing migration then feels like broken promises.
Avoid their busy season. If you've acquired an HVAC contractor, don't migrate email in July. Pest control? Skip spring. Accounting firms? Never touch email between January and April. One home services roll-up delayed a migration by eight weeks because the acquired company's field ops ran entirely through Outlook-synced mobile calendars, and disrupting that during peak season would have cost them customer appointments.
Coordinate with other integrations but don't wait for them. Email can and should move faster than CRM, ERP, or operational systems. Don't artificially delay email migration because "we haven't unified Salesforce yet." The two projects run in parallel, and email often enables CRM adoption because users get new credentials, training touchpoints, and a forcing function to adopt new workflows.
Allow 6-8 weeks end-to-end for a clean migration: 2 weeks audit and planning, 2 weeks prep and cleanup, 2 weeks pilot and technical migration, 1 week cutover, 1+ week hypercare. Compress that timeline and you'll pay for it in user frustration and rework.
The Five-Phase Email Migration Playbook
Here's the step-by-step sequence we use when migrating email and collaboration tools for roll-ups. This assumes a staged Microsoft 365 migration: adapt as needed for Google Workspace or cross-platform moves.
Phase 1: Audit and Decide (Weeks 1–2)
Map the current state:
- What platform(s) are they on? (Exchange on-prem, Microsoft 365, Google Workspace, legacy POP3/IMAP?)
- How many mailboxes, what sizes, and how much archival history?
- Shared mailboxes, distribution lists, and resource calendars (conference rooms, vehicles)?
- Who owns DNS? (Registrar login, current MX records, SPF/DKIM/DMARC configs?)
- Are there integrations that rely on email? (CRM email sync, helpdesk ticketing, automated alerts?)
Choose your destination platform. If you're already standardised on Microsoft 365 or Google Workspace, this is simple-bring them onto your tenant. If both companies run different platforms, now's the time to decide: full consolidation, dual-running, or deferred integration.
Select migration method and tooling. Native tools (Google Workspace Migrate, Microsoft's Exchange Admin Centre) work for straightforward IMAP or Exchange migrations. For cross-tenant or cross-platform moves, budget for third-party tools like BitTitan, SkyKick, or CloudM. They cost £3-8 per mailbox but save weeks of manual work.
Licensing and entitlements. Confirm you have enough Microsoft 365 or Google Workspace licenses to cover the acquired users. Don't assume you can just "add them"-check your enterprise agreement, verify pricing, and provision licenses before migration day.
Phase 2: Pre-Migration Planning (Weeks 3–4)
Domain verification and DNS prep. Add the acquired company's domain to your Microsoft 365 or Google Workspace tenant and verify ownership (typically via a TXT record). Don't cut over MX records yet-you're just proving you control the domain.
User provisioning. Create user accounts in your destination tenant. Decide on naming conventions (firstname.lastname@ or legacy username formats?), group memberships, and default permissions. This is where you also map job titles, departments, and manager hierarchies if you're unifying Active Directory or Google Workspace org units.
Data cleanup (ROT removal). Work with the acquired IT lead or power users to delete redundant, obsolete, and trivial emails. Empty deleted items and junk folders, archive old projects, and consolidate shared mailboxes that haven't been touched in a year. Migrating 20% less data can cut migration time by 30%.
Pilot group selection. Identify 5-10 users who will migrate first: IT staff, a department head, a couple of power users, and someone who's vocal and trusted. If the pilot goes well, they become your advocates. If it goes poorly, you learn what breaks before you've affected 50 people.
Communication plan. Draft the emails, Slack messages, or all-hands talking points that explain why migration is happening, when it affects each user, and what they need to do. Don't assume "IT will sort it" is enough-users need reassurance, timelines, and a clear escalation path if something breaks.
Phase 3: Technical Migration (Weeks 5–6)
Pilot migration. Migrate your pilot group's mailboxes first. Monitor the process in real time-watch for sync errors, oversized attachments that time out, calendar delegates that don't map cleanly. Have your migration tool dashboard open and your pilot users' phone numbers handy.
Test everything. After pilot mailboxes sync, check:
- Email sending and receiving (internal and external)
- Calendar invites and shared calendars
- Contacts (personal and shared)
- Mobile device sync (iOS Mail, Android, Outlook mobile app)
- Delegate and shared mailbox access
- Email signatures (often break and need reconfiguration)
Fix what broke. Pilot migrations always surface 2-5 issues you didn't anticipate. DNS records misconfigured. A shared mailbox that didn't migrate because it wasn't licensed. A user whose Outlook profile won't auto-configure because their laptop's still domain-joined to the old on-prem AD. Fix these now, document the workarounds, and update your runbook for the full migration.
Batch migration. Once the pilot's stable, migrate the rest in batches of 20-30 users per weekend (or overnight window). Staged cutover reduces risk and gives you time to address issues before they compound. Use your migration tool's scheduling feature to queue mailboxes, then monitor sync progress.
DNS cutover (MX records). Once mailboxes are migrated and tested, update the MX records to point to your new environment. This is the moment of truth-new emails start flowing to the new platform. Don't do this on a Friday afternoon. Do it Monday morning so you have the full week to catch issues.
Phase 4: User Cutover and Hypercare (Week 7)
User-facing cutover. Once DNS has propagated (allow 24-48 hours), users' email clients should auto-configure or prompt for new credentials. Have IT support or your migration team available for rapid response-expect 10-15% of users to need help with Outlook profile updates, mobile device reconfiguration, or password resets.
Hypercare support. For the first week post-cutover, someone needs to be on call for email issues. Questions will come in: "Where are my old emails?" "Why can't I see my colleague's calendar?" "My signature disappeared." Respond fast, document every issue and resolution, and update your knowledge base for the next acquisition.
Training and adoption reinforcement. If you've moved platforms (e.g., Google to Microsoft), run drop-in training sessions or record short how-to videos covering the basics: sending email, calendar sharing, accessing shared drives. Don't assume users will figure it out-small friction points compound into resistance.
Phase 5: Decommission Legacy Environment (Week 8+)
Verify completeness. Before you shut anything down, confirm all mailboxes migrated successfully. Compare source and destination mailbox sizes, spot-check a dozen users' inboxes, and verify shared mailboxes and archives didn't get missed.
Archival and compliance hold. If the acquired company has legal, compliance, or regulatory obligations to retain email (common in healthcare, finance, or government contracting), export and archive the old environment before decommissioning. Don't assume "it's all in Microsoft 365 now" covers you-some jurisdictions require native-format archival.
Decommission old systems. Once you're confident the migration is complete and stable, shut down the old Exchange server, cancel the old Google Workspace subscription, or close the legacy hosting account. Redirect the old domain to the new tenant (if you're keeping the domain) or let it expire if you're consolidating onto the acquirer's domain.
Cost reconciliation. Audit your licensing spend-confirm you've cancelled old subscriptions, reallocated unused licenses, and correctly sized your new tenant. It's common to find a roll-up still paying for an old Exchange hosting contract four months after migration because nobody had formally cancelled the service.
Common Pitfalls and How to Avoid Them
Underestimating shared mailbox complexity. Shared mailboxes (info@, support@, sales@) look simple but often have tangled permissions, multiple delegates, and years of unarchived email. Map these first in your audit, and migrate them early in your pilot so you can fix permissions before the full cutover.
Ignoring calendar delegates and shared calendars. Calendar permissions rarely migrate cleanly. Executive assistants who manage their boss's calendar will be the first to call you post-migration if delegation breaks. Test delegate access in your pilot, document the reconfiguration steps, and proactively reach out to known delegates before cutover.
DNS propagation surprises. MX record changes can take 24-48 hours to propagate globally, and some ISPs cache DNS longer than the TTL suggests. During that window, some emails may still route to the old server. Plan for dual-delivery or email forwarding rules to bridge the gap, and communicate to users that "some delay is normal for the first day."
The Conversion Trap (revisited). If you're moving Google Docs to Microsoft or Office files to Google, expect broken links, lost formatting, and user complaints. Test a representative sample of complex documents (spreadsheets with macros, presentations with embedded videos, collaborative docs with 10+ editors) before you migrate everything. Sometimes the best answer is "leave those files where they are and migrate selectively."
Mobile device configuration hell. Users expect their phones to "just work" post-migration. iOS and Android Mail apps sometimes cache old server settings and refuse to auto-detect the new environment. Have a one-page guide ready with step-by-step screenshots for removing old accounts and adding new ones. Better yet, if you have MDM (Intune, Google Workspace mobile management), push config profiles automatically.
Forgetting application integrations. Email isn't just Outlook. It's Salesforce email sync, Zendesk ticket routing, Xero invoice notifications, and a dozen other systems that rely on SMTP or IMAP connections. Audit these integrations in Phase 1, update credentials in Phase 2, and test them in Phase 3. One pest control roll-up forgot their field service platform emailed daily route sheets via an old Exchange mailbox-drivers didn't get routes for two days because the mailbox was decommissioned early.
Skipping hypercare. The week after cutover is where migrations succeed or fail in users' eyes. If issues linger unanswered for days, frustration builds and trust erodes. Staff your hypercare window properly-either internal IT, your migration partner, or a mix-and respond fast.
What Good Looks Like: Email Migration Success Metrics
How do you know your migration succeeded? Here's what to track:
Migration completeness: 100% of mailboxes migrated, with <2% requiring manual remediation. Shared mailboxes, resource calendars, and distribution lists all accounted for.
Data integrity: Mailbox size variance <5% between source and destination (after accounting for ROT cleanup). Spot-check sampling shows no missing folders, emails, or attachments.
User impact: <10% of users require support tickets post-cutover. Issues resolved within 24 hours. No escalations to leadership because "email is broken."
Timeline adherence: Migration completes within the planned 6-8 week window. No multi-month dragging or repeated postponements.
Cost efficiency: Old environment decommissioned within 30 days of cutover, eliminating duplicate license spend. New platform costs at or below projected budget.
Adoption and confidence: Acquired team reports email "just works" and feels supported through the transition. No attrition or morale hits attributable to migration.
Not luck. Rigor.
Frequently Asked Questions
How long does email migration take after an acquisition?
For a typical 20-80 person acquisition, plan 6-8 weeks end-to-end: 2 weeks audit and decision, 2 weeks prep and cleanup, 2 weeks technical migration and pilot, 1 week cutover, and 1+ week hypercare. Larger or more complex environments (500+ users, hybrid Exchange, cross-platform) can stretch to 12-16 weeks.
Should we migrate to Google Workspace or Microsoft 365?
If you're already standardised on one platform, bring the acquired company onto that. If both are starting fresh, Microsoft 365 has stronger enterprise tooling, better integration with Active Directory and on-prem systems, and superior cross-tenant migration features. Google Workspace is simpler, faster to deploy, and preferred by teams who prioritise real-time collaboration over heavy Outlook/Exchange workflows.
Can we migrate email ourselves or do we need a partner?
If your IT team has bandwidth, migration experience, and access to proper tooling, you can do it in-house. Most roll-ups find their IT teams are already stretched thin with BAU support, security, and infrastructure. Bringing in a specialist for the project work-audit, planning, execution, hypercare-lets IT stay focused on keeping the business running. We work with IT, not around them, and hand off cleanly once migration is complete.
What's the biggest risk in email migration after acquisition?
User trust. If people lose emails, can't access calendars, or feel unsupported through the change, you've damaged confidence in your ability to integrate the business. Technical risks (data loss, DNS misconfigurations) are manageable with proper planning and testing. Human risks-frustration, resistance, attrition-compound quickly if the migration feels rushed or poorly communicated.
Do we migrate email before or after CRM and ERP?
Email first. It's faster, affects everyone, establishes security and identity, and builds confidence that you can execute integrations competently. CRM and ERP migrations take longer, involve fewer users initially, and benefit from having unified email and collaboration already in place. System migration sequencing should always start with email and file storage before moving to operational systems.
What happens to old email addresses after migration?
You have three options: (1) Retire the old domain and force everyone onto the new domain (cleanest long-term but requires updating business cards, website, email signatures). (2) Maintain the old domain as an alias so emails to oldcompany.com still reach users at newcompany.com (adds complexity but preserves customer-facing continuity). (3) Keep both domains active with separate mailboxes (not recommended-doubles management overhead and confuses users).
How do we handle email migration if the acquired company has no IT lead?
Common in small acquisitions. Identify the most technically capable person on their team-often an office manager, power user, or someone who "fixes the printer." Partner them with your IT lead or migration team, involve them early in the audit, and rely on them as the on-the-ground contact during cutover. They know the team, the workflows, and the unwritten workarounds that won't show up in a systems audit.
