Cloud migration checklist for small business

Cloud migrations fail the same way every time. Not because the cloud is hard, but because somebody skipped a step that seemed unimportant in the planning meeting and turned into a three-week incident at 2am on cutover weekend. The fix is not to be smarter on the day. It is to have a checklist that catches the boring stuff before the migration starts.

This article is that checklist. It walks through the three phases of a cloud migration – pre-migration, migration, and post-migration – with the specific items that need to be confirmed at each stage. It is written for small and mid-sized businesses migrating their first major workload to the cloud, whether that is email, a file server, line-of-business applications, or a full server. It assumes you have already read moving your business to the cloud: where to start and how to move your on-premises server to the cloud and you have a sense of what is moving. This article is about how to plan it without missing anything. If you are evaluating a managed migration partner to run the project for you, the parent service overview is cloud migration services for small business.

Short answer: the three phases of a cloud migration

A clean migration has three phases, and each has its own checklist:

1. Pre-migration. Inventory, vendor selection, stakeholder alignment, baseline backups, success criteria. Roughly 60% of the total project time.
2. Migration. Test environment, phased rollout, user communication, the cutover itself, day-of validation. The visible 20%.
3. Post-migration. Validation, monitoring, decommission, cost review, lessons learned. The 20% most businesses skip.

Skip pre-migration and the migration itself becomes a discovery exercise. Skip post-migration and you pay for two environments forever, your old data sits exposed, and you never learn from what went wrong.

Cloud migration phases at a glance

Phase	Typical duration	What you produce	What goes wrong if skipped
Pre-migration	4 to 12 weeks	Inventory, project plan, communication plan, verified backups	Migration becomes discovery, surprises drive scope changes mid-cutover
Test environment	1 to 3 weeks	Working copy of the destination, test users, validated runbook	Production cutover becomes the first real test
Phased rollout	2 to 8 weeks	Pilot group migrated, issues fixed, runbook refined	Whole-company cutover hits issues at scale with no rehearsal
Cutover	1 day to 1 weekend	Production traffic moved, old system in read-only or off	Without a defined cutover window, you run two systems indefinitely
Post-migration validation	1 to 2 weeks	Functional, performance, security, cost validation complete	Hidden issues only surface when somebody complains weeks later
Decommission	30 to 90 days	Old systems off, data securely destroyed, licenses cancelled	Pay for two environments, leave data exposed, license confusion

Pre-migration checklist

This is where most of the project actually lives. The migration day is fast if pre-migration is thorough, slow if it was not.

Inventory and discovery

• [ ] Every server, VM, and physical machine in scope is documented with its role, owner, and dependencies
• [ ] Every application is documented with its vendor, version, support contract, and cloud compatibility status
• [ ] Every database is documented with version, size, growth rate, and which applications connect to it
• [ ] Every file share is documented with size, permissions, and last-accessed dates
• [ ] Every scheduled task, batch job, PowerShell script, and cron job is found and documented
• [ ] Every integration to external systems (vendor APIs, EDI, SFTP, banking) is listed
• [ ] Every printer, fax, scanner, and other peripheral that depends on the current environment is noted
• [ ] DNS records that point at on-prem services are mapped (A records, MX, SPF, DKIM, DMARC)
• [ ] Every certificate in use is documented with expiry date and renewal owner
• [ ] Network topology is documented: VPN tunnels, firewall rules, VLANs, static routes

The single most common source of post-migration pain is something that was running on the old server that nobody knew about. Find them now.

Stakeholder alignment

• [ ] Project sponsor identified (typically owner, COO, or CFO at SMB scale)
• [ ] Technical lead identified (internal IT person, MSP engineer, or both)
• [ ] Department leads briefed and asked what their team uses on the affected systems
• [ ] Realistic budget approved (including a contingency line – 20% is reasonable)
• [ ] Realistic timeline approved (with a defined cutover window, not “by Q3”)
• [ ] Success criteria written down (“email works for everyone, no data loss, downtime under 4 hours” is fine – “modernize our infrastructure” is not)
• [ ] Decision-making authority is clear: who can approve scope changes, who can call a rollback

Vendor selection

• [ ] Cloud platform chosen and justified (Azure for M365-heavy environments, AWS for broader service catalog, smaller providers for specific cases – see Azure vs AWS for small business for the full comparison)
• [ ] Migration strategy selected per workload (lift-and-shift, re-platform, re-architect, repurchase, retain, or retire) – see lift and shift vs re-platform vs re-architect: choosing the right cloud migration strategy for the per-workload decision tree
• [ ] Migration tooling selected per workload (SharePoint Migration Tool, Azure Migrate, Microsoft Migration Manager, third-party tools)
• [ ] If using a managed provider for the migration, the engagement scope is in writing including what is and is not included
• [ ] License changes priced (M365 plan changes, Windows Server licensing in the cloud, SQL Server licensing model)
• [ ] Network changes priced (additional bandwidth, ExpressRoute or Direct Connect if needed)

Backup and rollback

• [ ] Full backup of every system in scope, verified by restoring at least one file or VM to a separate location
• [ ] Backup retention extended to cover the migration window plus 90 days minimum
• [ ] Database transaction log backups configured for the cutover window so a point-in-time restore is possible
• [ ] Rollback plan written: if the migration fails, what gets restored, in what order, by whom, against what success criteria
• [ ] Rollback plan has a deadline: at what point during the cutover do we stop trying and roll back

A migration plan without a rollback plan is gambling, not engineering. The discipline of writing one usually surfaces issues with the migration plan itself.

Documentation and runbook

• [ ] Migration runbook written with every step, in order, with the person responsible
• [ ] Estimated duration noted next to each step (so the day-of team can tell whether they are ahead or behind)
• [ ] Decision points marked where the runbook may branch (rollback vs continue)
• [ ] Communication script for users prepared (what they will see, when, and what to do if something is wrong)
• [ ] Post-cutover verification checklist prepared and tested in the test environment first

Migration phase checklist

The migration phase is the most visible part of the project but should be the least eventful if pre-migration was done right.

Test environment

• [ ] Test environment built that mirrors the destination as closely as practical
• [ ] At least one test user from each department migrated to the test environment
• [ ] All major workflows tested in the test environment (sending mail, opening file shares, running line-of-business apps, printing)
• [ ] Performance benchmarked in the test environment against the current production environment
• [ ] Issues found in the test environment fixed and re-tested

User communication

• [ ] First announcement sent at least 4 weeks before cutover (what is changing, why, when)
• [ ] Detailed instructions sent 1 week before cutover (how to log in, what to expect, where to get help)
• [ ] Reminder sent 24 to 48 hours before cutover with the specific cutover window
• [ ] Help desk staffed for the first 1 to 2 weeks after cutover with extended hours
• [ ] Internal champion or super-user in each department identified to handle quick questions

The communication step is the one most often underdone at SMB scale. People do not resist change. They resist surprise. Email migrations specifically need extra communication because users notice the change immediately at their desk and on their phone – see how to migrate email to Microsoft 365 from an old Exchange server or Gmail for the day-of communication template and the Outlook re-profiling step that drives most of the post-cutover help desk load.

Phased rollout

• [ ] Pilot group selected (5 to 10% of users, ideally a mix of technical and non-technical, ideally one full team rather than scattered individuals)
• [ ] Pilot users migrated and using the new system for at least 1 to 2 weeks
• [ ] Issues from pilot logged, triaged, and either fixed or accepted
• [ ] Runbook updated with anything learned during pilot
• [ ] Wave 2 group migrated, then validated
• [ ] Final wave migrated only after waves 1 and 2 are stable

For workloads where phased rollout is not possible (full file server cutover, full email migration), the test environment work has to do the job a pilot group would have done. Take it seriously.

Cutover day

• [ ] Cutover window communicated and confirmed
• [ ] Out-of-office or maintenance banner up before the window starts
• [ ] Backups taken immediately before the cutover (the most recent possible)
• [ ] Old system put into read-only mode at the start of cutover (no new writes the migration tool will not capture)
• [ ] Migration runbook followed step by step, with each step checked off as it completes
• [ ] DNS changes scheduled and verified at low TTL well in advance
• [ ] Smoke tests run before declaring cutover complete (login, send mail, open a file, print)
• [ ] Rollback decision point reached and decision made: continue or roll back
• [ ] Cutover complete announcement sent

Post-migration checklist

This is the phase that separates a migration from a project that drags on for six months without anyone admitting it is not done.

Functional validation (week 1)

• [ ] Every department lead confirms their team’s primary workflows work
• [ ] Every line-of-business app is tested by an actual user, not just IT
• [ ] Email flow tested: internal, external in, external out, mailing lists, shared mailboxes
• [ ] File access tested: opening, saving, sharing, syncing on mobile
• [ ] Printing tested for every printer in active use
• [ ] Backup of the new environment is running and a test restore has been verified
• [ ] Monitoring and alerting is configured against the new environment

Performance validation (weeks 1 to 2)

• [ ] Compare actual performance to the test-environment benchmarks
• [ ] Identify any operations that got noticeably slower (this happens, especially if the network path changed)
• [ ] Tune anything that is unacceptable (right-size compute, change storage tier, add caching, fix DNS)
• [ ] Document any deliberate trade-offs (slightly slower app open in exchange for never running out of disk again is fine, as long as it is intentional)

Security validation (weeks 1 to 2)

• [ ] MFA enforced on every cloud account
• [ ] Conditional access policies tested and confirmed working (how to configure conditional access in Microsoft 365 covers the specifics)
• [ ] Permissions reviewed – SharePoint sites, OneDrive shares, file shares, mailboxes
• [ ] Admin accounts reviewed and break-glass account verified
• [ ] Logging and audit trail configured and exported to a place where they survive an account compromise
• [ ] Vulnerability scan run against the new environment
• [ ] Old credentials and service accounts that were specific to the old environment are deactivated

The security side of the post-migration audit deserves its own walkthrough – migration credentials, replicated permissions, parallel-environment leak risks, and the destination tenant audit. See how to keep your data safe during a cloud migration for the full security playbook.

Cost validation (week 4 to month 3)

• [ ] First full month of cloud spend reviewed against the original estimate
• [ ] Surprises explained (egress charges, license tier changes, premium storage that should have been standard)
• [ ] Unused or oversized resources identified and downsized
• [ ] Reserved instance or savings plan opportunities evaluated for steady-state workloads
• [ ] Cost ownership assigned (who is the named owner of the cloud bill)
• [ ] Alert configured for budget threshold (so the next bill surprise is caught early, not at month-end)

The first cloud bill is almost never the steady-state cloud bill. Plan to revisit cost at month 1 and month 3. After steady-state, drift is the silent killer – see cloud cost management for small business: how to stop overpaying for the monthly review cadence that keeps drift under control.

Decommission (weeks 4 to 12)

• [ ] Old system kept in read-only standby for at least 30 days after cutover
• [ ] Confirmation in writing from each department that they no longer need the old system
• [ ] DNS records pointing at the old system removed
• [ ] Firewall rules pointing at or from the old system removed
• [ ] Backup jobs targeting or sourcing the old system removed
• [ ] Monitoring agents and dashboards pointing at the old system removed
• [ ] Software licenses tied to the old system cancelled or transferred
• [ ] Server physically powered down for 14 to 30 days while still in place (final pause for “wait, we still need that”)
• [ ] Data destroyed using a documented standard (DoD 5220.22-M wipe, NIST SP 800-88 sanitization, or physical destruction for regulated data)
• [ ] Decommission certificate or sign-off filed

The decommission phase is the one most likely to be quietly skipped. Six months later somebody is still paying for an old server in a closet that nobody has logged into and that has stopped getting security patches. That is a breach waiting to happen, not a migration completed. See how to decommission old servers after a cloud migration for the full sequence: validation, standby window, data destruction standards by regulatory framework, hardware disposition, and the documentation that closes the loop.

Lessons learned

• [ ] What worked well, written down
• [ ] What did not work, written down honestly
• [ ] Estimate vs actual cost, time, and downtime captured for the next migration
• [ ] Documentation of the new environment updated to match the as-built state, not the planned state
• [ ] Runbook archived with notes for the next person who runs a similar project

Common mistakes that this checklist catches

• Migrating before backing up. Always take a fresh backup at the start of cutover, not just “the nightly from yesterday.”
• No defined cutover window. “We’ll move it sometime this month” turns into running two systems for a year.
• Skipping the test environment because it is “the same as production.” It is not. The DNS path, the network latency, the auth flow – something is different, and the cutover is the wrong time to find out.
• No rollback plan. A rollback plan is not pessimism, it is engineering hygiene. Write it before you start.
• Migrating without department leads informed. They will find a workflow IT did not know about, the day after cutover, and it will be on a list of “things that broke.”
• Pilot group of one. A single user is an anecdote. A team of 5 to 10 with a mix of roles is data.
• No post-cutover review of permissions. Migration tools migrate permissions. They do not audit them. The cutover is a good moment to clean up access that should have been removed years ago – see the Microsoft 365 security audit checklist for SMBs for the specifics.
• No cost review at month 1. Cloud bills surprise everybody who does not look at them. Budget is a process, not an estimate.
• Decommissioning too fast. 30 days minimum in standby. Some data only matters at month-end or quarter-end.
• Decommissioning too slow (or never). Six months later you are paying for two environments and exposed to the old one’s vulnerabilities.

How long should each phase take

The honest answer is “longer than the sales pitch suggests, shorter than your worst fears.” For most SMB migrations:

Migration scope	Pre-migration	Migration	Post-migration	Total
Email only (M365 cutover)	2 to 4 weeks	1 to 2 weeks	2 to 4 weeks	5 to 10 weeks
File server to SharePoint	4 to 8 weeks	2 to 6 weeks	4 to 8 weeks	10 to 22 weeks
Single line-of-business app to SaaS	2 to 6 weeks	1 to 3 weeks	2 to 4 weeks	5 to 13 weeks
Full on-prem server to cloud (mixed workloads)	8 to 12 weeks	4 to 8 weeks	8 to 12 weeks	20 to 32 weeks
Full multi-server environment migration	12 to 24 weeks	8 to 16 weeks	12 to 24 weeks	32 to 64 weeks

These are working timelines, not crash schedules. The crash schedule shaves 30 to 50% off these numbers and trades that time for project risk – which usually shows up as post-cutover rework.

Cost realities to plan for

Cloud migration cost is not just the migration tool licenses or the engineer hours. The hidden costs that catch SMBs out include:

• Double infrastructure during the parallel period. You are paying for both the old and the new environment during the test, pilot, and stabilization phases.
• Egress fees during the migration itself. Moving large data volumes out of the old environment can incur charges depending on the destination platform.
• License changes. M365 plan upgrades, Windows Server cloud licensing, SQL Server BYOL vs license-included.
• Bandwidth upgrades. If your office bandwidth was sized for “everything is local,” it may not be sized for “everything is in the cloud.”
• Productivity dip during transition. Real and unavoidable. Plan for 2 to 4 weeks of measurable productivity drag, longer for complex migrations. Budget for it as a soft cost.
• Training time. Even if the new tools are familiar, the way they fit into existing workflows is not. Underbudgeting training is a classic SMB mistake.

The cheapest migration quote is usually the most expensive in the long run because it is the one that skipped the unglamorous pre-migration and post-migration work. The full breakdown – one-time project fees, ongoing monthly bill, hidden costs, three-year TCO comparison vs staying on-prem – lives in how much does cloud migration cost for a small business.

When to use this checklist with a managed provider

If you are doing the migration internally, this checklist is the bare minimum. If you are working with a managed provider, the checklist is what you use to evaluate whether they have a real plan or are improvising.

A good provider runs every item on the pre-migration checklist as part of their discovery phase. They produce written deliverables for inventory, runbook, rollback plan, and communication plan, and they expect you to read and approve them before cutover. They have a defined post-migration phase with cost and security validation built in, not optional. They do not skip the decommission step or treat it as your problem.

If a provider’s pitch jumps from “yes we can move you to the cloud” to “let’s start next week,” they are skipping pre-migration. Push back. Skipping pre-migration is the single most reliable predictor of a bad migration outcome.

How Sequentur can help

If you are planning a cloud migration and want help with any part of it – or just a second pair of eyes on your plan – schedule a call.