A structured, phase-by-phase framework for migrating your on-premises infrastructure to AWS or Azure — covering pre-migration assessment, the 7R strategy selection, workload migration execution, security and compliance hardening, cutover planning, and post-migration cost optimization.
Cloud migration is not simply moving servers from a datacenter to AWS or Azure — it is a structured program that requires careful assessment of every workload, a deliberate strategy for each application, phased execution to manage risk, and post-migration optimization to deliver the promised cost and agility benefits.
Organizations that migrate without a structured framework typically end up with cloud bills higher than their on-premises costs, applications performing worse than before, and security gaps that did not exist in the previous environment. This guide provides the framework to avoid those outcomes.
A thorough pre-migration assessment is the most important investment in the migration program — it takes 2–4 weeks but prevents months of rework and unexpected costs during execution. Skip this phase and you are making expensive decisions without the data to support them.
| Assessment Area | Green ✅ | Yellow ⚠️ | Red 🚫 |
|---|---|---|---|
| Application architecture | Stateless, API-driven, containerizable | Stateful but documented dependencies | Tightly coupled, undocumented, monolithic |
| Data volume | < 1TB — network transfer feasible | 1–10TB — plan dedicated transfer window | > 10TB — requires AWS Snowball / Azure Data Box |
| Licensing | BYOL supported or cloud-native licensing | License review needed | No cloud licensing available — vendor lock-in |
| Internet connectivity | 100 Mbps+ ILL to cloud region | 50–100 Mbps — plan transfer schedule | < 50 Mbps — offline migration required |
| Team cloud skills | AWS/Azure certified staff available | Basic cloud exposure — training needed | No cloud experience — need external partner |
| Compliance requirements | No special data residency requirements | Data must stay in India — use ap-south-1 | Sector regulation prohibits cloud (rare) |
✅ Pro Tip: Use AWS Application Discovery Service (free) or Azure Migrate (free) to automate the discovery and dependency mapping phase. Deploy their lightweight agents on all on-premises servers — within 48 hours, both tools generate complete dependency maps, utilization baselines, and cloud cost estimates automatically. This replaces weeks of manual spreadsheet work and produces more accurate data than manual interviews.
Not every workload should be migrated the same way. The 7R framework (originally 5R, expanded by AWS and Gartner) provides a strategy for each application based on its complexity, cloud-readiness, business value, and migration urgency.
✅ Strategy Mix for Most Indian Enterprises: A typical 50-server migration portfolio breaks down as: Retire 10% (5 servers), Retain 15% (7–8 servers), Rehost 40% (20 servers — fastest to migrate), Replatform 25% (12–13 servers — managed DB, managed cache), Re-architect 10% (5 servers — only strategic apps). Start with Rehost for speed and quick wins, then progressively optimize Rehosted workloads toward Replatform over the following 6–12 months.
For most Indian enterprises, the cloud provider and region decisions are straightforward — but they deserve deliberate consideration rather than defaulting to the most-advertised option.
| Decision Factor | AWS | Azure |
|---|---|---|
| India regions | ap-south-1 (Mumbai), ap-south-2 (Hyderabad) | Central India (Pune), South India (Chennai), West India (Mumbai) |
| Best for | Greenfield cloud, DevOps-heavy teams, startups, e-commerce | Microsoft-heavy enterprises, hybrid AD environments, Office 365 shops |
| Managed DB | RDS (MySQL/PostgreSQL/SQL Server/Oracle), Aurora, DynamoDB | Azure SQL, Cosmos DB, PostgreSQL Flexible Server |
| Active Directory | AWS Directory Service (requires setup) | Azure AD / Entra ID — native, seamless |
| Hybrid connectivity | AWS Direct Connect, VPN Gateway | Azure ExpressRoute, VPN Gateway |
| Marketplace | Larger — more third-party tools available | Comprehensive — strong Microsoft ecosystem |
| Support (India) | Developer: $29/month, Business: $100+/month | Developer: $29/month, Standard: $100+/month |
A migration program is organized into waves — groups of related workloads migrated together. Each wave follows the same lifecycle: plan, build landing zone, migrate, test, cut over, optimize.
Build the cloud foundation before migrating any workloads. Set up AWS Organizations or Azure Management Groups with a multi-account/subscription structure. Configure VPC/VNet with production, dev, and shared services accounts. Deploy Direct Connect or Site-to-Site VPN to connect on-premises to cloud. Enable CloudTrail/Azure Monitor logging, GuardDuty/Defender, and AWS Security Hub/Defender for Cloud. Apply resource tagging policies and cost management budgets. Establish IAM roles and break-glass emergency access. This phase is non-negotiable — migrating into an unlocked, unlogged cloud account creates security and governance debt that is expensive to fix retroactively.
Migrate development, test, and staging environments first — these have no production SLA, so any issues discovered are low-cost learning opportunities. Dev/test migrations also validate the migration tooling, network connectivity, DNS cutover process, and monitoring configuration before touching production. Target 5–10 servers in Wave 1. Run parallel for 1 week — on-premises and cloud environments both active — before decommissioning on-premises dev servers.
Migrate internal-facing, lower-criticality production workloads — internal tools, reporting servers, backup systems, internal web applications. Apply lessons learned from Wave 1. These workloads are production but have higher tolerance for brief disruption. Target 10–20 servers. Perform cutovers during weekend maintenance windows. Keep on-premises as fallback for 2 weeks post-cutover before decommissioning.
Migrate customer-facing and revenue-critical applications — ERP, CRM, primary databases, public websites, payment systems. Requires detailed cutover runbooks, tested rollback procedures, stakeholder communication plan, and hypercare support for 2 weeks post-migration. Plan cutovers for lowest-traffic periods (typically Saturday 2–4 AM). Maintain on-premises as warm standby for 4 weeks before decommissioning.
Decommission remaining on-premises infrastructure, cancel datacenter contracts, return leased hardware. Begin cloud optimization sprint — right-size instances based on 30-day cloud utilization data, purchase Reserved Instances for stable production workloads, implement auto-scaling for variable workloads, and begin Replatform initiatives for Rehosted applications identified as optimization candidates.
Data migration is the highest-risk component of any cloud migration — data loss or corruption is irreversible, and large data volumes can take days or weeks to transfer. A structured data migration approach with verification at every step is essential.
| Data Volume | Method | Estimated Transfer Time | Tool |
|---|---|---|---|
| < 100 GB | Online transfer over ILL | 1–4 hours | rsync, AWS CLI S3 cp, AzCopy |
| 100 GB – 1 TB | Online transfer — scheduled off-peak | 4–48 hours | AWS DataSync, Azure Data Factory |
| 1 TB – 10 TB | Online with compression + dedupe OR offline | 2–14 days | AWS DataSync, Azure Data Box Edge |
| 10 TB – 80 TB | AWS Snowball Edge / Azure Data Box | 1–3 weeks (device shipping) | AWS Snowball, Azure Data Box |
| > 80 TB | AWS Snowmobile / Azure Data Box Heavy | Weeks (physical truck) | AWS Snowmobile |
🚨 Critical: Always verify data integrity after migration — do not assume the migration completed correctly just because the tool reported success. Run row count comparisons on all tables, checksum validation on critical tables, and application-level smoke tests before cutting over production traffic. For financial databases, run a parallel reconciliation — compare transaction totals on source vs target for the same time period. Data discrepancies discovered after cutover are far more costly to resolve than a delayed go-live.
Cloud environments require a different security model than on-premises — the shared responsibility model means the cloud provider secures the infrastructure, but you are responsible for everything above the hypervisor: OS hardening, access management, data encryption, network controls, and application security.
The cutover — the moment traffic shifts from on-premises to cloud — is the highest-risk event in the migration program. A well-documented cutover runbook with clear go/no-go criteria, tested rollback procedures, and defined communication protocols is the difference between a smooth go-live and a weekend crisis.
⚠️ Warning: Reduce DNS TTL to 60 seconds at least 24 hours before cutover — not at the time of cutover. DNS TTL changes take time to propagate. If your DNS TTL is 3600 seconds (1 hour) and you reduce it at cutover time, old TTL values are still cached across the internet for up to 1 hour — meaning rollback via DNS change will take up to 1 hour to take effect. Reducing TTL 24 hours in advance ensures the 60-second TTL is fully propagated before the cutover window begins.
Migration is not the finish line — it is the starting point for cloud optimization. The first 90 days after migration are the most valuable window for right-sizing, architecture improvements, and cost reduction, when utilization data is fresh and the team is most engaged with the environment.
Full monitoring coverage active. All alerts tuned — reduce false positives, ensure critical alerts page on-call. Runbooks for top 10 most likely operational issues documented. Performance baseline established — response times, error rates, DB query performance. Team trained on cloud console operations, log analysis, and alert response. Cost dashboard reviewed weekly — identify any unexpected charges immediately.
Right-size EC2/VM instances based on 30-day utilization data — instances consistently below 30% CPU are over-provisioned. Purchase 1-year Reserved Instances or Savings Plans for stable production workloads — saves 30–40%. Enable auto-scaling for workloads with variable traffic patterns. Move infrequently accessed S3 data to S3-IA or S3 Glacier. Enable RDS storage auto-scaling and review DB instance size against actual query load.
Begin Replatform initiatives — migrate Rehosted RDS-compatible databases from self-managed EC2 MySQL to Amazon RDS. Implement infrastructure as code (Terraform or AWS CloudFormation) for all cloud resources — eliminates manual configuration drift. Enable AWS Config or Azure Policy for continuous compliance checking. Evaluate containerization opportunities for Rehosted application servers. Document architecture decisions and lessons learned for future migration waves.
✅ Pro Tip: The single highest-value post-migration action is running the AWS Compute Optimizer or Azure Advisor at the 30-day mark and acting on every right-sizing recommendation. In practice, Lift-and-Shift migrations consistently result in over-provisioned cloud instances — organizations map a 4-core on-premises server to a 4-vCPU EC2 instance without accounting for the fact that on-premises server was running at 8% CPU. Acting on Compute Optimizer recommendations at day 30 typically reduces EC2 costs by 25–35% with no performance impact.
EnterWeb IT Firm manages end-to-end cloud migrations for Indian enterprises — from pre-migration assessment and landing zone setup through phased workload migration, security hardening, cutover execution, and post-migration optimization on AWS and Azure.