Cloud Migration Strategy.

/ 01Why move to the cloud (and when not to)

Cloud migration is sold by every vendor as universal progress. It's not quite that simple. For most SMBs, moving to the cloud delivers real benefits — but for specific workloads, on-premise remains the better answer. Be honest about both.

The case for cloud

• Predictable monthly costs instead of $30K-$80K hardware refresh cycles every 4-5 years
• No more aging server hardware failing at 2 AM on a Saturday
• Better security at the infrastructure layer — physical security, DDoS protection, hardware redundancy you couldn't possibly build
• Easier remote work — your data isn't tied to a single physical location
• Built-in disaster recovery — cloud providers replicate across regions; your old server in the back closet does not
• Scalability — when you grow or shrink, you pay accordingly; you don't buy hardware ahead of demand or sit on unused capacity
• Modern features — collaboration, real-time co-authoring, mobile access, AI-assisted everything — that on-prem versions of software don't offer

When on-prem still makes sense

• Latency-sensitive workloads — high-end CAD, video editing, 3D rendering work better on local hardware with local storage
• Specialized hardware requirements — control systems for manufacturing, lab equipment with USB licensing dongles, hardware that requires direct serial/USB connections
• Highly regulated data with explicit on-prem mandates — some defense contractor work, some healthcare research, some financial scenarios
• Existing infrastructure you've already paid for — if your server is 18 months old, the math doesn't favor immediate cloud migration
• Persistent high-bandwidth needs — if you move a TB of data daily, internet bandwidth costs and latency may favor on-prem storage
• Limited or unreliable internet — rural locations with marginal connectivity should think carefully before becoming cloud-dependent

/ 02The 6 R's of cloud migration

Originally an AWS framework, the 6 R's are a standard vocabulary for evaluating each workload. Different workloads get different treatments.

For an SMB, Repurchase and Retain dominate the practical strategy. Rehost applies to the handful of apps that don't have SaaS versions yet but you want out of your closet.

/ 03What to move first

The order matters. Get the foundation right and the rest gets easier; do it backwards and you'll fight the same battles three times.

Phase 1: Identity and email (months 1-2)

Move to Microsoft 365 or Google Workspace first. This establishes:

• Your cloud identity directory (Azure AD / Google Identity)
• Email in the cloud with proper security baseline
• The platform for everything else that follows

If you're not on M365 or Google Workspace yet, this is the prerequisite step. See our M365 Migration Playbook.

Phase 2: Files (months 2-4)

Once email is in the cloud, file storage is next. OneDrive for personal files, SharePoint or Google Drive for shared files. Retire your file server when:

• All active data has been migrated to the cloud equivalent
• Users have been trained on the new locations
• You've verified backups of the file server data (kept for at least 90 days post-cutover as a safety net)
• Departmental sign-off that nothing's missing

Phase 3: Backup & DR (months 3-5)

With M365 in place, set up cloud backup for the M365 environment itself (Microsoft does not back up your data — they keep it available but don't protect against accidental deletion, ransomware, malicious admin actions). Veeam, Datto SaaS Protection, AvePoint, Skykick all offer M365 backup. Plan for the on-prem servers being retired to be backed up to cloud archive storage (Azure Backup, AWS S3 Glacier) for 90-day-or-longer post-retirement coverage.

Phase 4: Line-of-business applications (months 4-12)

One at a time. For each business-critical app:

1. Check if the vendor offers a SaaS or cloud-hosted version (most do now)
2. If yes, evaluate the upgrade — usually involves vendor-led migration, new training, new licensing
3. If no, evaluate whether you can lift-and-shift to an Azure or AWS VM (rehost)
4. If neither, plan to retain on a small dedicated server until the vendor offers a better option or you switch products

Phase 5: Retire physical infrastructure (months 12+)

Once everything's moved or accounted for, retire the physical servers. Wipe drives (DoD 5220.22-M three-pass or NIST 800-88), donate or recycle hardware responsibly, document the changes, update your insurance and asset records.

/ 04The cost reality

Cloud-vs-on-prem cost comparisons are often misleading because they only compare the obvious line items. Here's a realistic side-by-side for a typical 25-user Tennessee SMB:

The cloud-first scenario looks cheaper, and it usually is once you account for everything. The places it can get more expensive: very heavy compute workloads, very large data egress (downloading lots of data from cloud), or pursuit of premium SKUs without business justification (Microsoft E5 instead of Business Premium for a small team that doesn't need the extras).

/ 05Security in the cloud

Cloud platforms are highly secure at the infrastructure layer. SMB cloud breaches almost always come from misconfiguration, not platform compromise. The shared responsibility model:

• Cloud provider handles: physical security, hardware, hypervisor, network infrastructure, platform availability, basic DDoS protection
• You handle: user accounts, permissions, MFA, data classification, application security, data protection, configuration

For M365 specifically, this means:

• Microsoft secures the platform (you don't need to patch Exchange Server anymore)
• You enforce MFA, configure Conditional Access, manage Information Protection policies, classify data, and backup the data Microsoft hosts but doesn't protect from user actions

Cloud security wins for SMBs largely because:

• Microsoft's threat detection and response capabilities exceed any SMB's internal capacity
• Patching is largely handled for you
• Physical and infrastructure security is no longer your problem
• Identity-centric security (Conditional Access, MFA, risk-based authentication) is dramatically more effective than perimeter-centric on-prem security

What it requires from you:

• Configure security defaults / Conditional Access from day one
• Enforce MFA for everyone, no exceptions (except documented break-glass accounts)
• Don't disable security features because they're inconvenient
• Treat admin accounts with extreme care — they're now the keys to the kingdom
• Monitor sign-in logs for anomalies
• Back up M365 data — Microsoft does not

/ 06Execution playbook

A condensed playbook for actually doing the work:

Pre-migration (weeks -8 to -4)

1. Inventory current state: every server, application, license, data store, integration
2. Pick your cloud platform (M365 or Google Workspace as foundation; Azure or AWS for any IaaS workloads)
3. Pick your migration partner (internal IT, MSP, specialized migration consultant)
4. Develop a migration plan workload-by-workload using the 6 R's framework
5. Budget approval and timeline confirmation
6. User communication plan: what changes, when, what to expect

Foundation phase (months 1-2)

1. M365 / Google Workspace tenant established with security baseline applied
2. Domain ownership verified, email migrated, DNS cutover completed
3. MFA enforced organization-wide
4. Conditional Access policies applied
5. Intune / device management deployed

Files and shares (months 2-4)

1. SharePoint site architecture designed (one site per department/team typically)
2. File shares migrated via SharePoint Migration Tool or third-party
3. OneDrive Known Folder Move deployed to all workstations
4. Users trained on new file locations and search
5. Old file server access removed, server kept read-only for 30-60 days as safety net, then retired

Applications (months 4-12)

One at a time. Each app gets its own mini-project with vendor coordination, user testing, training, and cutover.

Infrastructure retirement (months 12+)

Server retirements, drive wipes, hardware disposal, asset documentation updates. End of major project.

Ongoing

Cloud isn't done after migration — it requires ongoing management. Cost optimization (right-sizing licenses, archiving unused data), security posture management, license true-up annually, ongoing user training as features evolve.