Every failed cloud migration we've been called in to rescue skipped steps that take days, not months. This is the checklist CloudSwift runs before migrating any Indian enterprise workload to Azure — use it to audit your own plan or your partner's.

Phase 0: Discovery and business case

  1. Inventory everything. Run Azure Migrate discovery for at least 30 days to capture real utilization — sizing from nameplate specs over-provisions by 40–60%.
  2. Map application dependencies. The app nobody documented talking to the database nobody owns is what causes cutover-night failures.
  3. Model TCO honestly. Include Azure Hybrid Benefit (existing Windows Server / SQL licenses cut compute costs by up to 40%), reserved instances or savings plans, and egress costs.
  4. Classify data for residency. Under the DPDP Act and sector rules (RBI for financial data, IRDAI for insurance), decide per-dataset whether it must stay in Indian regions.

Phase 1: Foundation — the landing zone

  1. Choose regions deliberately. Central India (Pune) and South India (Chennai) offer zone-redundant pairs for in-country DR; the Hyderabad region adds further capacity. Latency from Bengaluru to Chennai is typically under 10ms.
  2. Deploy a landing zone before the first VM. Management groups, Azure Policy guardrails, hub-and-spoke networking, centralized logging to Log Analytics, and Defender for Cloud enabled from day one.
  3. Identity first. Entra ID with Conditional Access and PIM configured before workloads arrive — retrofitting identity governance onto a live estate is 10x harder.
  4. Set up cost management. Budgets, alerts, and a tagging taxonomy (CostCenter, Environment, Owner) enforced by policy, not by memo.

Phase 2: Migration waves

  1. Wave the portfolio. Start with low-risk, low-dependency workloads (dev/test, file servers) to prove the pipeline; save the ERP for wave three.
  2. Pick the right R per workload: rehost (lift-and-shift), replatform (SQL to Azure SQL Managed Instance), or refactor. Rehosting everything wastes Azure's economics; refactoring everything blows the timeline.
  3. Rehearse cutover. Test failback, not just failover. Agree maintenance windows and rollback criteria in writing.
  4. Validate performance post-move against the baseline captured in discovery, then right-size within 30 days.

Phase 3: Operate

  1. 24/7 monitoring with real escalation paths — Azure Monitor alerts that page a human with an SLA, not a mailbox.
  2. Patch and backup compliance: Update Manager schedules, Azure Backup with tested restores, and immutable backup for ransomware resilience.
  3. CERT-In readiness: log retention (180 days minimum), NTP synchronization to Indian sources, and a 6-hour incident-reporting runbook.
  4. Monthly cost reviews: reservation coverage, orphaned disks, idle IPs, and storage lifecycle policies.

A disciplined mid-size migration (50–200 VMs) takes 3–6 months end to end. If a proposal promises less without a discovery phase, that's your first red flag. CloudSwift runs funded Azure migration assessments for qualifying Indian enterprises — request one here.