Cloud Migration Planning: From Strategy to Execution
Note: This is general information and not legal advice.
On this page
Executive Summary
- "Lift and dump" migrations often cost more than expected and deliver less value
- Platform migrations (like Google to M365) break workflows if dependencies are not mapped
- Cloud costs grow over time - licensing changes, storage accumulates, egress fees surprise you
- You are planning to migrate workloads to cloud infrastructure or SaaS platforms
- Your organization is considering Google Workspace to Microsoft 365 (or vice versa)
- You need to project costs beyond year one and understand the total cost of ownership
- Every workload has a placement rationale - not everything belongs in SaaS or IaaS
- Platform migrations map all dependencies before move day - especially identity and SSO
- DR and backup strategy is defined before migration, not discovered after data loss
- We assess workloads and recommend the right placement - SaaS, IaaS, containers, or private infrastructure
- We plan and execute platform migrations with dependency mapping and rollback plans
- We design backup and DR strategies that work in your target environment
- Cloud migration is managed across our Managed IT and Professional Services offerings.
The "Lift and Dump" Problem
Moving a server to the cloud does not make it cloud-native. A "lift and dump" migration - taking on-prem workloads and moving them to cloud infrastructure without redesign - often costs more and performs worse than expected. The 1:1 fallacy assumes on-prem equivalents translate cleanly to cloud. They rarely do.
What people expect
- → Same server, lower cost in the cloud
- → File server to SharePoint is just a copy operation
- → Cloud provider handles all security and backups
- → Migration completes in weeks with minimal disruption
What actually happens
- × Cloud costs exceed on-prem due to egress, licensing, and over-provisioning
- × File permissions, folder structures, and workflows break without planning
- × Shared responsibility means you still own backup, identity, and configuration
- × Unexpected dependencies surface during migration, causing delays
Moving a file server to OneDrive or SharePoint without planning means losing folder structures, permission models, and workflows that people depend on. Proper migration requires mapping: what moves where, who gets what access, how shared folders translate, what happens to shortcuts and mapped drives, and how users are trained on the new system. The "just copy the files" approach fails.
Not Everything Belongs in SaaS
Moving a server to the cloud is not always SaaS. Sometimes IaaS (virtual machines) makes sense. Sometimes containers are better. Sometimes private infrastructure - a rack in a datacenter that N2CON manages for you - is the right answer. The question is workload fit, not ideology.
When to use
- → Commodity workloads (email, CRM, collaboration)
- → No custom integration requirements
- → Vendor roadmap aligns with your needs
When to use
- → Legacy apps that cannot be refactored
- → Need cloud elasticity with OS-level control
- → Temporary lift-and-shift while planning modernization
When to use
- → Applications designed for containerization
- → Need portability across environments
- → Microservices or cloud-native architectures
When to use
- → Performance consistency requirements (low latency LAN)
- → Predictable heavy workloads where cloud costs exceed CapEx
- → Strict data residency or control boundaries
N2CON offers private datacenter services for organizations with unique needs - we set up the rack, equipment, and manage it for you. The on-prem vs cloud guide covers workload placement decisions in depth.
The Platform Migration Trap
Google Workspace to Microsoft 365 (and vice versa) is much harder than people think. It is not just email - it is Drive to OneDrive/SharePoint, Google Meet to Teams, Google Chat to Teams, Google Sites, Shared Drives, identity provider changes, SSO federation, conditional access, and third-party app SSO that was using Google as IdP.
- → Email (Gmail to Exchange Online or vice versa)
- → Drive files to OneDrive/SharePoint with permissions intact
- → Calendar and contacts migration
- → Meet recordings and chat history (if retained)
- → Google Sites to SharePoint or alternative
- → Shared Drives to SharePoint sites or M365 Groups
If Google was your Identity Provider (IdP), what happens to all the third-party apps that rely on Google SSO? You need to map every app using Google authentication, plan the migration to your new IdP (Entra ID, Okta, etc.), update SAML configurations, test SSO for each app, and communicate changes to users. This is the most common failure point - and the hardest to fix after migration day.
Platform migrations require deep identity expertise. The identity foundations guide covers IdP architecture. The M365 security basics and M365 licensing guides cover Microsoft-specific considerations.
What You Forgot
Every migration plan has blind spots. These are the most commonly forgotten pieces that cause pain after migration day.
DR Planning
How does this migration fit into your Disaster Recovery plan? Cloud does not automatically mean "backed up." Did you define RTO/RPO for migrated workloads?
Backup Strategy
Cloud provider availability is not the same as recoverability. You need backups you control. Did you plan backup tools, retention, and restore testing?
Multi-year Costs
Did you project costs for 3-5 years, not just the migration year? Licensing changes. Storage accumulates. Egress fees surprise you.
Training & Change
Users need to learn the new system. Did you plan training, documentation, and support for the transition? Resistance kills adoption.
Data Governance
What data is moving? Who owns it? What is the retention policy? Did you classify data and apply handling requirements?
Compliance
Does the migration affect compliance obligations? HIPAA, GLBA, CMMC, or other frameworks may have specific requirements for data location and access.
Building a Migration Plan
A migration plan is more than a timeline. It is a sequence of decisions, tests, and checkpoints that reduce risk and catch problems early.
Inventory
Document what you have: applications, data, users, dependencies, integrations. You cannot migrate what you do not know exists.
Dependency Mapping
What depends on what? Which systems are interconnected? What breaks if X moves before Y? Map the relationships.
Pilot / Phased Approach
Start small. Migrate a pilot group or non-critical workload first. Learn what breaks. Adjust the plan. Then expand in waves.
Testing
Test functionality, performance, access controls, backups, and recovery. Verify everything works before declaring success.
Rollback Plan
What if migration fails? Define the rollback path before you start. How do you get back to the working state?
Post-Migration Optimization
Migration is not the end. Optimize costs, tune performance, clean up unused resources, and document lessons learned.
Technical depth on specific topics: cloud security controls, SaaS governance, application lifecycle, evaluating new tools, build vs buy, hosted app evaluation, vendor management, and IT roadmap planning.
Explore Deeper
Cloud migration touches many topics. Each guide goes deeper into the specifics.
Common Questions
How long does a typical cloud migration take?
It depends on scope, but plan months not weeks. Rushing causes the problems this guide describes - poor planning leads to higher costs, broken workflows, and security gaps. A phased approach with pilots and learning cycles is slower upfront but faster overall because you avoid rework.
Can we migrate in phases?
Yes, and you should. Start with a pilot group or non-critical workload. Learn what breaks, what users struggle with, and what costs surprise you. Then expand in waves. Phased migrations reduce risk and give you time to adjust the plan based on real experience.
What if our cloud costs are higher than expected after migration?
This is common with lift-and-dump migrations. Revisit workload placement - some workloads may be better suited to IaaS, containers, or even staying on-prem. Right-size instances, review licensing, and check for egress fees. The on-prem vs cloud guide covers workload placement decisions in depth.
Do we still need backups in the cloud?
Yes. Cloud availability is not the same as recoverability. The cloud provider keeps the platform running, but you are still responsible for restoring your own data. See our backup and DR guides for recovery planning.
What is the biggest mistake in platform migrations?
Not mapping dependencies - especially identity, SSO, and third-party app integrations. Moving from Google Workspace to Microsoft 365 (or vice versa) is not just email. You need to plan for Drive to OneDrive/SharePoint, Meet to Teams, Chat to Teams, Sites, Shared Drives, identity provider changes, conditional access, and any third-party apps that relied on your old IdP.
How does N2CON help with cloud migrations?
We plan, execute, and manage migrations that actually work - from workload assessment and platform selection through post-migration optimization and ongoing management. We have seen what breaks and plan for it upfront.
Related resources
Sources & References
Planning a cloud migration?
We help organizations plan and execute migrations that actually work - from workload assessment and platform selection through post-migration optimization and ongoing management.
Contact N2CON