DIY vs Migration Partner: When to Bring in a Specialist

We sell migration services, so you should read this article with that in mind. But precisely because migrations are all we do, we have no incentive to pretend every project needs us. Some genuinely do not, and we will start there, because a DIY article from a migration partner that never says "do it yourself" is not worth your time.

When DIY is the right answer

Run your own migration when most of these are true:

• The environment is small and clean. A dozen mailboxes, one domain, no public folders, no compliance holds, no mystery applications sending mail. Microsoft's native tooling handles this case well.
• Someone on staff has done one before. Not read about one: done one, including the cutover and the week after. The second migration is dramatically easier than the first, because Exchange migration difficulty lives almost entirely in the surprises.
• Downtime tolerance is real, not aspirational. If mail being weird for a day or two would be an annoyance rather than a revenue event, you have room to learn on the job.
• There is slack in the calendar. A first-time migration done carefully takes elapsed weeks: planning, trial syncs, the cutover, cleanup. If your team can absorb that alongside their day jobs, the labor is already paid for.

If that describes you, take the win: read the vendor documentation thoroughly, pre-stage your data, test mail flow both directions before flipping MX, and keep the old system readable until you have verified item counts. Plenty of small organizations do exactly this and are fine.

The parts that bite first-timers

The mechanics of copying mailboxes are the easy 80 percent. Projects fail, or limp, on the other 20:

• Discovery gaps. The scanner that emails PDFs, the ERP that relays through the server, the alarm system with a hardcoded SMTP address. Anything not inventoried before cutover fails silently after it.
• Public folders and permissions. Legacy public folder trees migrate badly by default, and delegated calendar and shared mailbox permissions have to be rebuilt precisely or the front desk cannot see the boss's calendar on Monday.
• Throttling and the calendar. Cloud ingestion is rate-limited. Teams that discover this during cutover weekend, rather than during planning, end a weekend with half-copied mailboxes and a hard choice.
• Autodiscover and device chaos. Outlook profiles and phones follow DNS breadcrumbs. Get the order of operations wrong and every device in the company asks for a password at 8 a.m.
• The old server's afterlife. DIY projects routinely end with the legacy Exchange box still running, unpatched and internet-facing, "just in case." That is the single most dangerous machine in the building, and decommissioning it properly is part of the job.

None of these are unsolvable. All of them are the kind of problem that takes a first-timer a day and a veteran ten minutes, because the veteran has seen the exact error before.

The real cost comparison

Professional migration services commonly land in the low to mid hundreds of dollars per mailbox, all-in, for SMB projects (the full breakdown is in How Much Does an Exchange Migration Cost?). DIY looks free next to that until you price it honestly:

For many organizations, the staff-time line alone, priced at real loaded rates, approaches or exceeds the partner's fee. Which means the decision usually is not about money. It is about risk and about what your team should be spending its weeks on.

Signals you should bring in a specialist

1. You are on Exchange 2010 or 2013. The modern, forgiving migration paths do not fully apply to these versions. Legacy moves need a playbook: staged approaches, PST fallbacks, public folder handling, and a decommission plan. This is specialist territory, and it is most of what we do.
2. Mail downtime is a business event. If a day of broken email means missed orders or breached client SLAs, the premium for a rehearsed cutover with a rollback plan is cheap insurance.
3. Nobody owns it. If the migration has been "on the roadmap" for over a year, the constraint is not knowledge, it is attention. A partner brings a schedule and the accountability to hit it.
4. Complexity flags are present. Public folders, litigation holds, journaling, multiple domains, tenant-to-tenant moves after an acquisition, or a hosted provider shutting down around you. Each one multiplies DIY risk.
5. The destination itself is undecided. If you are still weighing cloud against Exchange Server SE or a hybrid design, a specialist earns their fee before migration even starts, by stopping you from migrating to the wrong place.

What a specialist actually changes

It is not secret tooling; much of the software is available to anyone. What you are buying is:

• Pattern recognition. Your migration is our hundredth. The gotchas that cost a first-timer a weekend (throttling, autodiscover, the 80 GB mailbox) are things we plan around before they happen, because they always happen.
• A fixed scope in writing. Discovery first, then a price and a dated plan. If discovery turns up something ugly, the quote changes before the work starts, not after.
• A rehearsed cutover. Trial syncs, verified item counts, mail-flow tests in both directions, and a rollback plan that exists before it is needed. "No lost mail" is a process, not a promise.
• A finished ending. Devices reconfigured, users supported on day one, the old server actually decommissioned, and documentation handed over. Optionally, ongoing management of the Microsoft 365 tenant afterward, so the environment stays as clean as it landed. The ongoing economics of that landing zone are covered in our Exchange Online vs on-premises cost comparison.

The honest summary: if your environment is small, clean, and low-stakes, do it yourself and spend the savings elsewhere. If it is legacy, complex, or business-critical, the math and the risk both point the same way, and the earlier a specialist sees the environment, the cheaper the project tends to be.