How to run a pilot and migrate to Microsoft 365 without downtime

A pilot migration sets the pace for a smooth Microsoft 365 rollout. Microsoft MVP Andy Huneycutt shares how to run one right—so you can move forward with confidence.

By the time you reach the migration phase, a lot of groundwork is already done. You have a solid plan, your content is cleaned up, and everyone is aligned on what’s happening next. Now it’s time to put that plan into motion.  

To make things go smoothly, there are two things that are especially important in a Microsoft 365 migration: running a pilot migration and then rolling out the full migration with minimal (ideally zero) downtime.

A pilot lets you catch and fix issues on a small scale before they impact the whole organization. And with a well-executed strategy, the full migration can feel seamless for your users.  

In this article, we’ll cover how to run an effective pilot and best practices when it's time for the big move.

Watch the full session on-demand: Conquer the biggest Microsoft 365 migration challenges.

‍

Why every great migration starts with a pilot run

A pilot migration is essentially a test run of your migration. It involves migrating a limited set of data and/or a subset of users to Microsoft 365 as a proof of concept and trial.

A pilot helps you:

• Validate your migration approach and tools in a real-world scenario
• Uncover any technical problems or edge cases that weren’t evident during planning
• See how users are affected and how your support and communications hold up
• Get feedback from users in the new environment, which can help you refine your training or adjust theMicrosoft 365 migration process itself

Choosing a pilot group

Select pilot participants and content that are representative of your broader migration, but low-risk enough that any issues won’t severely impact the business. This could be one or two non-critical departments or a mix of volunteers from different teams.

Make sure your group is big enough to provide meaningful feedback. Migrating a single user’s files might not tell you much, but a small department’s SharePoint site, OneDrives, and mailboxes? That’s better.

Include a mix of content types, like one SharePoint site, a batch of mailboxes, and files from a network drive, to test the range of migrations you’ll be doing. It’s your chance to see how well everything works before scaling up.

Setting up the pilot

Run the pilot just like your real migration, but on a smaller scale. Follow your runbook, use the same tools and methods, and make sure to:

• Migrate pilot data using your chosen migration tool (think a few hundred GB of files or some mailboxes)
• Have users start working in Microsoft 365 (Teams, SharePoint, Outlook, etc.) once the pilot migration is complete
• Offer support and create a feedback channel—maybe a chat or scheduled check-ins
• Monitor the results—verify permissions, check that files open correctly, version history is intact, emails landed properly, and so on

Evaluating the results

After the pilot, meet with your project team to review:

• Did the migration tool perform as expected? Any errors, slowdowns, or connector issues?
• Did any content fail to migrate—and why? For example, maybe files with “&” in the name didn’t transfer cleanly. Now you know.
• Did the timeline match your estimates? If migrating 50 GB took 3 hours, you can use that to scale your full migration plan.
• What did users experience? Interview or survey them. Were they confused at cutover? Did they find their files? Their feedback will help improve training and support—like highlighting how to find archived email if that tripped people up.

Making adjustments

Use the pilot findings to tweak your migration plan. This could mean technical adjustments (like updating a mapping file or allocating more bandwidth) and/or procedural tweaks (like reworking a comms email or assigning IT buddies for cutover support). The pilot essentially gives you the chance to spot issues early, improve your approach, and reduce surprises when it’s go time.

Go time: Running your full migration with confidence

With the pilot behind you and lessons learned in hand, you're ready to roll out the full Microsoft 365 migration. Whether you choose a big bang or phased approach, here are best practices that apply to any strategy:

1. Communicate final reminders

As the migration date gets closer, make sure to send out final reminders to your users. These messages should include:

• The timeline: Spell out exactly when things will happen. For example, “On Friday at 5 PM, your systems will go read-only. By Monday morning, you’ll be using the new Microsoft 365 apps.”
• What they need to do: In many cases, end users don’t need to lift a finger. But if they do—like logging out, closing files, or setting up OneDrive—make those instructions crystal clear.
• How to get help: Share your support contact details—whether it's a helpdesk email, phone number, or a dedicated Teams channel. Reassure users that you're there for them.
• What to expect: Set expectations to reduce anxiety and minimize the flood of “where’s my stuff?” questions. For example, “Your N: drive files will now be in the Company Documents SharePoint site, accessible via the Office 365 portal or Teams. Here’s a quick link.”

2. Prepare the team and back up your data

Behind the scenes, your IT team should be just as ready. Take one last backup or snapshot of critical data—this is your safety net. Make sure every team member knows their role. They should all stick to the runbook. Plus, keep an open line of communication among the migration team during the event (like a conference call bridge or a Teams chat) so the IT project team can coordinate in real-time.

3. Migrate during off-peak hours

If possible, schedule the heavy lifting for nights or weekends. It might mean late hours for your IT team, but it helps avoid disrupting day-to-day operations. If that’s not feasible (like in 24/7 environments), break the migration into smaller chunks—by department or site—with tailored comms for each group.

4. Use incremental migration

A common approach for migrating file and SharePoint content is to do an initial migration pass well ahead of cutover using incremental migration techniques. This copies most of the data, even while people are still actively working in the old system. Then, during cutover, you run a delta migration to sync any last-minute changes.

Migration tools like ShareGate support this by letting you re-run migration jobs and only copy what’s changed. The same idea applies to mailboxes: you can use a staged Exchange migration or a third-party tool to gradually sync mailboxes, and then switch MX records or run a final delta sync at cutover.

The goal is to have as little data left to move as possible when it’s time to switch, so your window for read-only access or downtime is minimal.

Be sure to test this process during your pilot or in a dry run. Confirm that your incremental updates catch all changes, and after cutover, double-check that no one snuck in edits during the freeze.

5. Monitor the migration

During the migration, continuously monitor your tools and systems. Most migration tools provide logs or dashboards showing how many files have migrated, what’s pending, and whether any errors have occurred. Keep an eye out for any failures.

If issues arise, assess their importance. Some errors might be harmless—like a skipped system file—while others could require immediate attention. Knowing which is which helps you avoid unnecessary delays.

It’s smart to build a buffer into your timeline. For example, aim to finish the bulk of your migration by Saturday at noon. That gives you the rest of the weekend to troubleshoot any lingering problems or re-run failed jobs. If everything goes off without a hitch, great—you can relax. If not, you’ve set yourself up with time to fix things before users are back online.

6. Cut over and switch over

Once the data has been successfully migrated, it’s time to execute the cutover steps to direct users to the new environment. This might include updating shortcuts or internal links, such as pointing the company intranet to new SharePoint Online sites and switching DNS entries if you're using vanity URLs for SharePoint.

You’ll also want to instruct users on what to do next; for example, letting them know they should begin using Office 365 apps on Monday morning.

In the case of email migrations, this could involve redirecting mail flow to Exchange Online by updating DNS MX records, and prompting users to restart Outlook so it connects to the new server. Follow your runbook carefully. These final steps are crucial to ensure users land in the right place and everything runs smoothly on the next work day.

7. Post-migration smoke test

Before declaring “all clear,” it’s time for your IT team to roll up their sleeves and run a round of smoke tests in the live environment. This quick-but-critical check makes sure everything’s working as expected—and helps catch any last-minute surprises before your users do.

Here's what to cover:

• Open a few sample files in SharePoint and OneDrive to make sure they’re accessible and that permissions carried over correctly. This step confirms that the SharePoint migration was successful and secure.
• ‍Check key SharePoint sites to see if they’re up and fully populated with content.
• ‍Log in as a few test users to confirm they can access their email, calendar, and files without hiccups.
• Check Microsoft Teams (if it was part of the migration). Make sure chats, channels, and membership are intact—especially for tenant-to-tenant moves, which can be trickier.
• Run automated checks with your migration tool to validate that everything intended to be migrated actually made it. Some migration tools give a summary like “X of X items succeeded.” You’re aiming for 100%—or at least clear visibility into what didn’t transfer and why.

If something’s missing—say, a key file or mailbox didn’t migrate—you’ve got options. You can restore from backup or do a quick re-migration of that piece. In rare, worst-case scenarios (like if core systems aren’t functional), you may need to delay go-live and keep users on the old system temporarily.

That said, if you’ve run a pilot, followed your plan, and done your dry runs, odds are you’ll be high-fiving the team and celebrating a successful migration.

Help your users feel right at home

The true mark of success during the execution phase is that users barely notice the change. From their perspective, it should feel like one day they were working in the old system, and the next day they're in Microsoft 365—with everything important right where they need it, fully functional.

Creating that seamless experience means:

No data loss

Users should open the new system and find everything right where they left it—emails, files, and other content fully intact. We can't emphasize this enough: always verify data integrity. If users find things missing, it can quickly erode trust. Encourage pilot users or key stakeholders to double-check that their content made it over. You can even offer early access so a few users can validate data before everyone goes live.

Minimal noticeable downtime

If you've followed best practices, you likely scheduled a read-only window or short downtime and gave everyone a heads-up. Because you communicated clearly (and maybe even timed it for off-hours), most users won’t notice anything at all. The goal is to avoid that dreaded “I couldn’t work this morning” moment.

Smooth onboarding to Microsoft 365

Make that first login feel effortless. A “Welcome to Microsoft 365” email with helpful links and key tips (sent to their new Outlook inbox) can set the tone. If you’ve changed the login process—say, switching to Azure AD credentials—make sure it’s clearly explained and SSO is working. The smoother the login, the better the first impression. Ideally, apps like OneDrive and Outlook just work, thanks to tools like Azure AD Connect and Autodiscover.

Support is standing by

Be ready. The first few days are critical, and having a “war room” (even a virtual one) where IT is on standby makes a big difference. Fast responses squash concerns before they spread. Track every issue, and if you notice repeat questions, send a quick FAQ update: “Some of you asked about X—here’s how to find it.” It shows you’re on top of things and boosts confidence across the board.

Let users help validate

Invite users to poke around and flag anything off. A message like, “Please check your team’s SharePoint files and let us know if anything looks missing,” gives them a sense of ownership. When they do report issues and you fix them fast, it reinforces that everything’s under control—and builds trust in the process.

Special considerations (if applicable)

While that covers most migrations, some projects have special considerations to keep in mind.

Coexistence periods: If you’re running old and new systems side by side—like when some users are still on the old email platform while others have moved—make sure there are clear rules in place. You might need email forwarding or syncing between environments during transition waves. Coexistence can get messy fast, so keep it short or bring in expert help if it gets too complex.

Tenant-to-tenant migrations: Moving between Microsoft 365 tenants—often after a merger or acquisition—adds some extra layers. Things like Teams and OneDrive migrations can be tricky when user accounts don’t match up. Tools like ShareGate help smooth things out, but you’ll also need to reassign licenses, reconfigure Office apps, and document everything in your execution plan.

Hybrid setups: If part of your setup is staying on-prem—like a hybrid Exchange or SharePoint environment—make sure the integration is seamless for users. For example, in a hybrid Exchange, calendar info like free/busy time should still sync properly between cloud and on-prem during the transition.

Go into the execution phase with a bit of professional paranoia—expect bumps in the road, keep your eyes open, and stay flexible. But also trust the prep work you’ve done. Stick to your plan, monitor your progress, and adjust as needed.

By the end of this phase, you’ll have successfully moved all (or most) users and content to Microsoft 365. That’s a huge win—congrats! Just remember, migration success isn’t only about the move. It’s about getting everyone working confidently in the new environment. That’s where post-migration support becomes your next big focus.

Check out the rest of our migration blog series with MVP Andy Huneycutt:

• Microsoft 365 migration challenges and how to solve them
• Best practices for Microsoft 365 migration planning
• Microsoft 365 migration clean up: How to prepare what (and what not) to migrate

‍

‍

‍