Most cloud migrations fail because of planning, not technology. Seven steps, in order, with a verification gate after each one. Skip a step and you'll feel it during cutover when it's hardest to fix.
- Step 1 · Assessment: 1–3 days
- Step 2 · Platform selection: 1–2 days
- Step 3 · Migration plan: 2–5 days
- Step 4 · Security setup: 1–3 days
- Step 5 · Data migration: 1–14 days
- Step 6 · Testing: 1–3 days
- Step 7 · Cutover & support: Ongoing
The quick answer
If you just need the timeline: email-only migrations take 1–2 weeks end to end. Full infrastructure migrations take 4–8 weeks for a typical small business. Rushing either is the most common cause of downtime and rolled-back projects.
The harder question with cloud migration isn't how long but what order. Most small business migrations fail because someone moved files before securing the destination, or migrated email before they'd cleaned up the user list, or skipped testing because they were behind schedule. The order matters more than the speed.
This checklist is the same 7-step process we run for every BadgerLayer migration engagement. It works for Microsoft 365, Google Workspace, Azure, AWS, or hybrid setups.
Why most migrations fail
Cloud platforms themselves are reliable. Microsoft, Google, Amazon, and Apple don't lose your data. But migrations still go wrong, and almost always for the same reasons.
The platform never causes the failure. The handoff does.
Three patterns we see repeatedly:
- Discovery shortcuts. Someone assumes they know what's on the network. They don't. The line-of-business app nobody mentioned, the printer everyone forgot about, the shared mailbox three people use without anyone admitting it — that's where cutovers stall.
- Security configured last. Data gets migrated first "to make sure it works," then MFA gets enabled later. In between, the new tenant runs without proper access controls. Most cloud breaches happen during this gap.
- Cutover under pressure. The project ran long, the budget's tight, the cutover gets crammed into a weekday afternoon with no rollback plan. This is how migrations turn into outages that hit Monday morning.
Every step below is designed to prevent one of these three failure modes. The order isn't arbitrary.
Platform decision matrix
Before any of the seven steps matter, you need to know where you're going. Most small business migrations land on one of four platforms, sometimes a mix of two. Here's how the choice typically breaks down.
Microsoft 365 and Google Workspace are competitors. Azure and AWS aren't — they're the layer below, used alongside Microsoft 365 or Google Workspace when on-premise servers also need to move. Most small business migrations are simpler than people fear: pick the productivity suite, then deal with servers separately if any exist.
Step 1: Cloud migration assessment
Before anything moves, you need a complete picture of what you have. The assessment covers your existing infrastructure, data volumes, application dependencies, user counts, and compliance requirements. This is not optional. Skipping it is the #1 cause of surprise costs and blown timelines.
Time investment: 1–3 days. The longer end is for environments with multiple offices, on-premise servers, or line-of-business applications nobody fully documented.
- Inventory all servers, workstations, and network devices
- Document every software and line-of-business application
- Map application dependencies (what talks to what)
- Measure total data volume across all systems
- Identify compliance requirements (HIPAA, GLBA, PCI, SOC 2, CMMC)
- Document current backup and recovery procedures
- Note legacy applications that may not be cloud-compatible
- Measure internet bandwidth at each office location
- List every shared mailbox, distribution list, and group
- Identify accounts belonging to former employees
The output of this step is a written environment document. If you can't produce one, you haven't finished the assessment yet.
Step 2: Choose your cloud platform
Platform selection should be driven by your assessment findings, not by what's familiar or cheapest upfront. Use the matrix above as a starting point, then validate against the specific software your team uses every day.
Time investment: 1–2 days. Most of this time is spent verifying that line-of-business apps work in the chosen platform.
- Compare Microsoft 365 vs Google Workspace against your team's actual workflow
- Confirm cloud compatibility for every line-of-business application
- Calculate total cost of ownership including licenses, storage, and add-ons
- Verify compliance certifications for regulated industries
- Evaluate Azure vs AWS if any server workloads need to move
- Plan a hybrid setup if specific systems must stay on-premise
- Confirm tenant region and data residency requirements
- Pick licensing tiers per user role (not everyone needs the top tier)
Step 3: Build your migration plan
The migration plan defines what moves when, in what order, and who is responsible for each piece. The most important decision is migration sequencing: what to move first.
For most small businesses, the right order is: email first, then file storage, then applications, then servers. Email migration is the lowest risk and gives users early wins. Moving servers last means you have a functioning cloud environment to fall back on if problems arise.
Time investment: 2–5 days. The plan itself doesn't take long to write — the time goes into stakeholder alignment, scheduling, and getting the right people to commit to the timeline.
- Define migration phases and sequence (email, files, apps, servers)
- Set realistic timelines with buffer for each phase
- Schedule cutover windows during off-hours or weekends
- Assign owners for each migration task
- Define rollback procedures for each phase
- Plan user communication: notify staff before major changes
- Schedule user training sessions before or during cutover
- Document go/no-go criteria for each phase
- Identify the single point of contact who can approve changes
Rather hand this off?
BadgerLayer runs cloud migrations end to end. Free assessment, transparent pricing, off-hours cutover.
Step 4: Cloud migration security setup
This is the step most small business migrations cut corners on, and it's where breaches happen. Security can't be bolted on after migration is complete. It has to be configured before any production data moves.
Time investment: 1–3 days. The work is mechanical — tenant settings, conditional access policies, MFA enforcement — but it has to happen before data lands.
- Enable multi-factor authentication for every account before cutover
- Configure role-based access controls with minimum necessary permissions
- Verify encryption at rest and in transit on all storage
- Create and verify full backups before migration starts
- Set up cloud backup and retention policies in the new environment
- Disable legacy authentication protocols (basic auth, SMTP relay)
- Configure conditional access policies for remote access
- Audit admin accounts and remove unnecessary admin privileges
- Set up audit logging and alerting for suspicious activity
- Document the decommission procedure for old systems
If you're in a regulated industry (healthcare, financial services, federal contracting), this step doubles in importance and length. HIPAA, GLBA, and CMMC requirements often dictate specific tenant configurations that have to be in place before any PHI, financial data, or CUI ever touches the cloud. We add a compliance review step here for regulated clients.
Step 5: Data migration
This is the step everyone focuses on, and it's actually less risky than security setup if done correctly. The key is migrating in batches with verification at each stage, not moving everything at once and hoping for the best.
Before migrating anything, clean up the data. Old files, duplicate mailboxes, orphaned user accounts, and outdated shared folders all add migration time and cost. A cleanup pass before migration typically reduces total data volume by 20–40%.
Time investment: 1–14 days. The wide range reflects the spread between email-only migrations (1–3 days) and full file server moves with hundreds of gigabytes (up to two weeks).
- Clean up data before migrating: delete duplicates, archive old files
- Create a verified backup of all data before starting
- Migrate in phases: email first, then files, then applications
- Verify each batch after migration, not just at the end
- Test file permissions: confirm users can only access what they should
- Confirm email history, contacts, and calendars migrated correctly
- Validate database integrity for any migrated databases
- Keep source systems live until migration is fully verified
- Monitor migration tooling for failed items, not just successes
Always verify each batch before starting the next. Migrations fail in silence; verification is how you hear them fail.
Step 6: Testing before cutover
Testing is the step most businesses rush or skip because they're anxious to be done. It's also the step that prevents migration from becoming a crisis. Test with real users on real workflows before flipping the switch.
Time investment: 1–3 days. Skipping this step saves no time — it just shifts the cost from controlled testing to chaotic post-cutover firefighting.
- Test email send and receive for every migrated mailbox
- Verify calendar and contact sync across devices
- Test file access from office, remote, and mobile devices
- Confirm every line-of-business application functions in the new environment
- Test printer and shared device connectivity
- Run through the rollback procedure in a test scenario
- Have a sample of end users test their daily workflows
- Verify backup and restore works on the new environment
- Document every issue found and resolve before scheduling cutover
Step 7: Cutover, training & post-migration support
Cutover is the moment you switch users to the new environment and stop relying on the old one. Do this after hours. Have your IT team on standby. Don't decommission old systems until everything has been working for at least one full business day.
User training is the most underestimated part of any cloud migration. Even a simple email migration generates support tickets if users aren't shown what changed and why. Plan for at least a brief orientation before or during cutover.
Time investment: Cutover window 2–6 hours, post-migration support ongoing. The 30 days after cutover are where small issues get caught and resolved before they become institutional knowledge gaps.
- Schedule cutover during off-hours with IT on standby
- Notify all staff before cutover with clear instructions
- Redirect DNS and MX records at the cutover window
- Monitor for errors in the first 24 hours post-cutover
- Confirm every user can log in and access their data
- Train users on new workflows, apps, and access methods
- Keep old systems live for at least 48 hours as a fallback
- Decommission old systems only after full sign-off
- Update IT documentation to reflect the new environment
- Set a 30-day review to assess performance and address issues
Cutover happening this month?
We schedule cutovers during off-hours so your team walks in to a working environment Monday morning.
The most common cloud migration mistakes
These are the failures we see in migrations that came to us after someone else attempted them. Most are preventable with discipline at one of the seven steps above.
| Mistake | Where it happens |
|---|---|
| Skipping the assessment | Step 1 — undiscovered dependencies |
| Not cleaning data first | Step 5 — migrating years of duplicates |
| Configuring security after migration | Step 4 — gap in access control |
| Rushing the cutover window | Step 7 — no rollback plan, business hours |
| Ignoring user training | Step 7 — tickets surge week one |
| Decommissioning too fast | Step 7 — no fallback if issues surface |
| Underestimating bandwidth need | Step 1 — throughput bottlenecks during data move |
| Migrating shared mailboxes wrong | Step 5 — permissions don't carry over cleanly |
Should you DIY this or hire it out?
The question every cloud migration starts with. Here are the four rules we use to honestly tell prospects whether they should run the migration themselves or hand it to an MSP.
At BadgerLayer, every cloud migration starts with a free assessment that produces a written plan whether or not you hire us. We're honest about what you can do yourself and what we'd recommend handing off. Sometimes the right answer is "handle it internally with our help on a few specific pieces."
Ready to start?
Free migration assessment. We're based in Whitewater, Wisconsin and run migrations for businesses across the Midwest and beyond.