Migrations Are Boring When Planned Properly
Email, file, and server migrations with a written plan, a tested pilot, a cutover scheduled around your business, and a rollback path if something goes sideways.
45 min · Free · No commitment
Everyone has heard about the migration that went badly
The stories are consistent: mail stopped flowing on Monday morning, historical email was missing, shared calendars broke, half the team could not open files, and the provider who ran it was unreachable for three days. That experience is why so many businesses stay on infrastructure they know is failing.
Almost all of it traces to skipped preparation. Nobody inventoried the mailboxes and shared resources. Nobody tested a pilot group before moving everyone. Nobody worked out that a line-of-business application had a hardcoded mail server address. And nobody wrote down how to reverse the change.
Facet MSP runs migrations as projects with phases: discovery, a written plan you approve, a pilot group, then a cutover scheduled outside your business hours with a rollback path defined before we begin. The goal is a Monday morning where nobody notices anything happened.
Discovery, pilot, cutover, verify
Discovery & Inventory
Every mailbox, shared mailbox, distribution list, calendar, public folder, file share, and application that touches mail or files. Migrations fail on the objects nobody remembered existed, not the ones on the list.
Written Migration Plan
Sequence, timing, who is affected when, what changes for users, DNS and TTL changes, and the rollback procedure — approved by you before anything moves. If it is not written down, it has not been planned.
Pilot Group First
A small representative group moves first and runs on the new platform for a real business week. This is where hardcoded settings, application integrations, and mobile device quirks surface — with five people affected instead of fifty.
Email Migration
Full mailbox history, calendars, contacts, and shared resources moved with delta syncs so nothing lands after the cutover and gets stranded. Historical mail arriving intact is the thing users judge a migration by.
File & Server Migration
File shares moved to SharePoint or Azure with permissions deliberately mapped rather than blindly copied, and servers migrated or replaced with the application dependencies understood in advance.
Out-of-Hours Cutover
The disruptive step happens on a Friday evening or a weekend, with our team available through it and on Monday morning. Cutting over at 10 a.m. on a Tuesday to suit a vendor calendar is not a plan.
Post-Migration Verification
Mail flow tested in both directions, authentication records updated, mobile devices reconnected, and a punch list worked until it is empty. A migration is finished when the list is clear, not when the data has moved.
A Monday nobody remembers
- Historical email and calendars arrive complete
- Application dependencies are found before cutover, not after
- The disruptive work happens outside business hours
- A rollback path exists before anything changes
- Mobile devices reconnect without a queue at the help desk
- Email authentication is updated so mail keeps being delivered
The unglamorous parts are the whole job
We pilot before we commit.
A week with a small group surfaces the surprises while they are cheap. Skipping the pilot is how a migration becomes a story people tell for years.
Rollback is planned, not improvised.
We define how to reverse the change before we start. Knowing the exit exists is what makes it reasonable to walk through the door.
We do not forget DMARC.
Changing mail platforms without updating SPF, DKIM, and DMARC means your legitimate mail starts failing authentication. It is a routine step that routinely gets missed.
Migration questions
How long will it take, and how much downtime?
A straightforward email migration for a small team typically runs two to three weeks end to end, with most of that being preparation and pilot rather than cutover. Actual user-facing downtime is usually minutes, scheduled outside business hours. Larger or messier environments take longer, and we will say so in the plan.
Will we lose any old email?
No. Full mailbox history moves, with delta syncs afterward so mail arriving during the transition is not stranded on the old platform. Verifying that history arrived intact is an explicit step on the punch list, not an assumption.
What about our line-of-business application that sends email?
That is exactly what discovery is for. Applications with hardcoded mail server settings are among the most common migration surprises, which is why we inventory them upfront and test them in the pilot rather than discovering the problem on cutover night.
Can you migrate us away from another MSP mid-contract?
Yes, and we handle it regularly. We will need administrative access and reasonable cooperation on the handover; where cooperation is not forthcoming, there are established ways to migrate without it. Check your notice period first — that is usually the binding constraint on timing.
What happens if something goes wrong on cutover night?
We work the issue with our team available through the window, and if the problem is fundamental we execute the rollback we planned before starting. Then we diagnose, fix the root cause, and reschedule. That is what a rollback path is for.
Ready to take this off your plate? Six questions.
Spend 90 seconds answering. We'll spend a few hours putting together a written assessment of where your IT stands — and a 45-minute call with one of our engineers.