Most cloud migrations that go wrong don't fail on the technology. They fail because nobody wrote down what "done" actually looks like before starting.
Moving email, files, servers, and line-of-business applications to the cloud is routine work at this point, but routine doesn’t mean simple. The businesses that get through a migration cleanly are almost always the ones who mapped out what needed to happen before touching anything, not the ones who moved fastest.
This checklist is for owners and operations leads at small and mid-sized Ontario businesses planning a move to Microsoft 365, SharePoint and OneDrive, or Azure, whether that means retiring an aging on-premise server, moving file shares, or getting an accounting or practice management application off hardware that’s out of support. It follows the same order ACT360 uses for cloud migration projects, which is discovery, then planning, a phased move, and validation afterward.
Where a recommendation comes from Microsoft’s own migration guidance or the Canadian Centre for Cyber Security, we link to it. Where it comes from our own projects, we say so.
TL;DR. Most migration trouble starts before anything moves. Inventory every system and integration, including the small ones, classify your data, and pick an approach per system, whether that’s lift-and-shift, re-platform, or rebuild. Write the rollback plan first. Move in phases, lower-risk systems before critical ones, and keep the old environment running until the new one is proven. Afterward, verify data, rebuild and test backups, and tighten any permissions loosened along the way.
What Should You Do Before a Cloud Migration?
Before anything moves, inventory every system and integration in use, classify your data by sensitivity, choose a migration approach for each system, and write a rollback plan. Microsoft’s Cloud Adoption Framework treats this planning as its own phase, and in our experience it’s where most avoidable migration problems are either caught or created.
- Inventory everything that’s actually in use. Not just the systems everyone remembers, but the smaller integrations and legacy tools that quietly connect to them. In a typical small business, that means mailboxes in on-premise Exchange or Microsoft 365, file shares, Active Directory accounts and group policies, accounting or practice management software, and things like scan-to-folder copiers and logon scripts. Microsoft’s own Azure Migrate dependency guidance makes the point that analyzing dependencies “helps ensure that nothing is left behind.”
- Classify data by sensitivity and compliance requirement. Where data can live, and what has to happen to it during the move, depends on what kind of data it is and what regulations apply. Moving to the cloud doesn’t move accountability either. Microsoft’s shared responsibility model is clear that customers always keep responsibility for their data, endpoints, accounts, and access management, and the Canadian Centre for Cyber Security warns that using cloud services doesn’t automatically apply protections to your assets. If client files or health records are involved, this is where our cybersecurity team usually gets involved.
- Choose a migration approach for each system. A straight lift-and-shift, a re-platform onto a managed cloud service, or a full rebuild are different amounts of work with different outcomes. The right choice varies system by system, not business-wide, and the table in the next section lays out the trade-offs.
- Set a rollback plan before starting, not during a problem. Microsoft’s migration planning guidance calls for a defined rollback plan so teams can reverse changes quickly when something fails. In practice, that means knowing which backup you’d restore from, who makes the call, and how long reverting would take. It’s also where migration planning overlaps with business continuity and disaster recovery.
Which Migration Approach Fits Each System?
Most small businesses choose between 3 practical approaches. Lift-and-shift moves a system as it is, re-platforming moves it onto a managed cloud service with small changes, and rebuilding replaces it with something designed for the cloud. Microsoft’s Cloud Adoption Framework lists these alongside options to retire, replace, or retain a system.
| Migration Approach | Best For | Advantages | Risks | When Not to Use It |
|---|---|---|---|---|
| Lift-and-shift (rehost) | Stable servers or apps that mainly need to get off aging hardware quickly | Fastest route, fewest changes, little retraining for staff | Carries old problems and messy configuration straight into the cloud, and running costs can surprise you | The system is already unstable, or its configuration is part of the problem |
| Re-platform | File shares moving to SharePoint and OneDrive, on-premise Exchange moving to Exchange Online, databases moving to a managed service | Less hardware to maintain, plus built-in remote access and version history | Folder structures and permissions need rethinking, and users will notice the change | A vendor-supported application isn’t supported on the target platform |
| Rebuild | Legacy or custom applications that are obsolete or can’t move as they are | A clean start designed around how the business works now | Longest timeline and highest cost, with real testing and training needs | The timeline is tight, or an off-the-shelf cloud application would do the job |
Terminology follows Microsoft’s cloud migration strategies, where lift-and-shift is called rehost.
Sometimes the right answer is not to move a system yet. A 35-person commercial painting contractor came to ACT360 with a failing server and a $60,000 replacement quote from its previous provider. Discovery turned up a planned ERP replacement that would move its Sage accounting system off-premise within a couple of years. Rather than migrating Sage twice, we sized a bridge server for $25,000, including installation and migration, and built the plan around the ERP timeline. The full painting contractor case study has the details.
What Happens During a Cloud Migration?
During the migration, systems move in phases, lower-risk ones first, with integrations tested at each step, staff told about timing in advance, and the old environment kept running until the new one is confirmed working. Microsoft recommends moving non-production environments before production for the same reason.
- Migrate in phases, not all at once. Moving lower-risk systems first validates the process before anything business-critical is on the line. Microsoft’s migration planning guidance makes the same recommendation, migrating development and test environments before production to validate readiness.
- Test connectivity and integrations at each phase. A system that worked fine on its own can still break the moment it needs to talk to something that moved separately or hasn’t moved yet. For file shares, tools like Microsoft’s Migration Manager can move content into SharePoint, OneDrive, and Teams in batches, which makes phase-by-phase testing practical.
- Communicate timing to staff in advance. A migration that surprises the team with unexpected downtime creates more disruption than the migration itself usually causes.
- Keep the old environment available until the new one is confirmed working. Decommissioning too early removes the safety net exactly when it might still be needed.
Testing each phase matters because migrations surface things nobody documented. During an Ontario law firm’s move from a vendor-locked Remote Desktop Services environment to Microsoft Azure, ACT360 found data bleed-through between client files and years of accumulated group policy that was causing instability. We rebuilt the group policy framework instead of carrying it over and fixed the data segregation as part of the project. Before the move, opening a Word document took 3 to 5 minutes. After it, the same tasks completed immediately, and support tickets dropped significantly. The law firm cloud migration case study covers the full project.
What Should You Check After a Cloud Migration?
After the move, confirm data integrity rather than just presence, rebuild and test backups in the new environment, review access permissions, and watch performance for the first few weeks. Only then should the old environment be retired.
- Confirm data integrity, not just data presence. Files and records showing up isn’t the same as them being complete, correctly formatted, and accessible the way they were before.
- Test backups in the new environment. A backup strategy that worked in the old setup needs to be reconfigured and verified in the new one, not assumed to have carried over. Our guide to how often to test your backups covers what a real restore test involves.
- Review access permissions. Migrations are a common point where access controls get rebuilt loosely just to get things working, then never tightened back up. After a file share moves to SharePoint or OneDrive, check that site and library permissions match who should actually see what, since old folder permissions don’t always map cleanly onto how SharePoint works.
- Monitor performance for the first few weeks. Some issues, particularly around speed and integration reliability, only show up once real day-to-day usage resumes at full volume.
How Does ACT360 Approach Cloud Migration?
ACT360 puts the Assess and Comprehend steps of its ACTION methodology ahead of any migration plan, so the plan is built around what’s actually connected to what. Systems then move in phases, each one validated before the next, with the same 2 people involved from assessment to the last validated system.
In ACT360’s experience, one of the most common problems we’re brought in to fix is a migration that moved before anyone understood the dependencies. The other is a business that migrated once under deadline pressure, got burned, and is now afraid to touch it again. Both trace back to skipped discovery, which is why our cloud migration services start there rather than with a quote.
Adam Bowles and Jeffrey Bowles plan and run ACT360 migrations together, and ACT360 has worked with more than 2,700 Ontario businesses over 16 years. If you’re not sure yet what’s in your environment, what to expect during an IT assessment explains how that discovery work runs.
Questions About Planning a Cloud Migration
How long should cloud migration planning take before execution starts?
In ACT360’s experience, a few weeks for most small and mid-sized businesses, covering a full inventory, dependency mapping, and a phased plan before any data moves. It stretches when there are several locations, an on-premise server running a line-of-business application, or integrations nobody has documented.
How much downtime should we expect during a cloud migration?
With a phased plan, most staff should see little or none. Cutovers for email or file shares are usually scheduled outside business hours, and the old environment stays available until the new one is confirmed working. The systems most likely to cause visible disruption are line-of-business applications and anything with undocumented dependencies, which is exactly what discovery is meant to find.
Should every system be migrated the same way?
Not necessarily. Some systems are good candidates for a straight lift-and-shift, while others benefit from re-platforming onto a managed cloud service or a fuller rebuild. The right approach is usually decided system by system, and occasionally the answer is to leave a system where it is until a planned replacement arrives.
Do we really need a rollback plan if the migration is well planned?
Yes, and the better the plan, the easier the rollback plan is to write. It defines how you’d revert to the old environment if something goes wrong mid-migration, who makes that call, and within what window. Working it out during an active problem costs time the business usually can’t afford.
What usually causes cloud migrations to run into trouble?
In ACT360’s experience, one of the most common causes is incomplete discovery, where a smaller integration or legacy tool that was never inventoried breaks when the system it depends on moves. A thorough inventory before planning starts is the best protection against it.
Do backups automatically carry over correctly during a migration?
Not automatically. Backup configurations often need to be rebuilt and tested specifically in the new environment, since assuming they carried over from the old setup is a common and preventable gap. Confirm a successful restore before retiring anything.
Final Thought
A cloud migration checklist isn’t about following steps mechanically. It’s about answering the questions that matter before they turn urgent, and 3 of them carry most of the weight.
- Inventory everything, including the small integrations nobody remembers, because that’s where migrations usually break.
- Decide the approach system by system, and write the rollback plan before the first system moves.
- Don’t retire the old environment until data, backups, and permissions have been verified in the new one.
The businesses that plan for those upfront are the ones who barely notice the migration happened. If you’d like a clear picture of what’s running and what’s connected to what before you start, ACT360’s IT Readiness Assessment is a free, no-obligation place to begin.
Call 705-739-2281 or email [email protected]
