The useful lesson is not that cloud migration makes downtime disappear. It is that moving mailboxes and maintaining a usable email service are related—but distinctly different—jobs.
What changed for EMA Partners
According to NTT DATA’s case study, EMA Partners had been using shared email services delivered through the provider’s Managed Services portfolio. That on-premises environment needed upgrading and did not offer the broader combination of Teams, SharePoint and Office applications sought through Microsoft 365. Keeping disruption low was a central requirement.
NTT DATA reports that the migration met the customer’s availability requirements and enabled access to those additional applications under a bundled-cost arrangement. However, it provides no mailbox count, measured outage duration, cost comparison or productivity statistics. Nor does the page establish when the migration occurred. These are provider-reported outcomes, not an independently measured performance benchmark.
Why the cutover choice matters
Microsoft’s Exchange Online documentation describes cutover migration as moving an email organization’s mailboxes together. Although the method supports up to 2,000 mailboxes, Microsoft recommends limiting it to approximately 150 because of the time required to create and migrate users. That distinction matters: a supported ceiling is not a promise of a comfortable migration window.
EMA Partners’ undisclosed mailbox count means administrators cannot use this case alone to judge whether the same approach fits their organization.
The practical detail: DNS is part of the migration
Microsoft’s guidance highlights several responsibilities beyond copying mailbox contents:
- Verify domain ownership before migration.
- Assign licenses to migrated users.
- Change the MX record so incoming mail reaches Microsoft 365.
- Configure Autodiscover so Outlook and mobile clients locate their new mailboxes.
There is also an important timing distinction. Microsoft says outside email systems can take up to 72 hours to recognize an MX-record change and instructs administrators to wait at least that long before deleting the migration batch. That is a routing-propagation allowance—not a prediction of 72 hours of email downtime.
For an IT team evaluating a migration proposal, the practical question is therefore more demanding than “Did the mailboxes copy?” Ask who verifies incoming delivery, client connectivity and completion before the old migration path is removed.
A useful example, not a reusable runbook
EMA Partners’ experience supports a modest conclusion: documented procedures and continued user support deserve space in the migration plan, not just the mailbox-transfer schedule. NTT DATA’s public account does not disclose enough technical detail to reproduce the project or assess its rollback arrangements.
The sensible takeaway is to borrow the planning discipline, not assume the same cutover method will produce the same result everywhere. A successful mailbox move is an important milestone; users being able to get back to work is the finish line.