Most "cloud migration strategies" fail for a boring reason: they start with a go-live date and work backwards. The ones that succeed start with an honest inventory, a written decision framework, and a landing zone that exists before the first workload moves. This is the cloud migration planning playbook CloudSwift runs for Indian enterprises — use it as your project plan, your RFP checklist, or your audit of a partner's proposal.
What a cloud migration strategy actually is
A cloud migration strategy is not a slide saying "lift and shift to Azure." It is a documented plan that answers five questions for every application and dataset:
- Why move? Cost, agility, end-of-support hardware, M&A consolidation, or compliance — pick the primary driver or the programme will thrash.
- What moves, and in what order? Wave design based on dependency maps, not org-chart politics.
- How does each workload move? The 6Rs: rehost, replatform, refactor, repurchase, retain, retire.
- Where does it land? Region, landing-zone controls, identity, networking, and data-residency constraints (critical for India under DPDP / RBI / sector rules).
- Who operates it after cutover? FinOps, patching, backup, monitoring, and an SLA — or the migration "succeeds" and Day-2 collapses.
If a proposal skips discovery or quotes a fixed timeline before dependency mapping, it is a guess, not a strategy.
Phase 0 — Discovery (2–6 weeks)
Run continuous discovery long enough to capture real utilisation, not nameplate specs. For Azure estates we typically use Azure Migrate for 30+ days; for AWS, Application Discovery / Migration Hub; for databases, native tooling plus AWR/ASH or equivalent.
- Inventory: servers, containers, databases, file shares, SaaS integrations, batch jobs, and the "shadow" apps nobody owns.
- Dependency mapping: the undocumented chat between App A and Database B is what breaks cutover night.
- TCO model: include reserved/savings commitments, Hybrid Benefit / BYOL where applicable, egress, and the cost of the landing zone itself.
- Data classification: which datasets must stay in Indian regions, which can leave, and what logging retention CERT-In expects (180 days minimum in practice).
Phase 1 — Choose the R for every workload
A single R applied to the whole estate is how programmes overspend. Our default decision tree is covered in depth in the dedicated spoke: The 6 Rs of Cloud Migration. Summary:
- Rehost (lift-and-shift) for stable apps with short remaining life or tight cutover windows — fastest path, weakest cloud economics.
- Replatform when a managed service removes ops toil without rewriting the app (e.g. SQL Server → Azure SQL Managed Instance, Oracle → Autonomous or OCI DB systems).
- Refactor only when the business case funds it — usually customer-facing or high-churn systems.
- Repurchase when a SaaS product retires a custom stack (CRM, HR, expense).
- Retain / Retire deliberately — not every VM deserves a cloud bill.
Document the R per application in a migration strategy document your steering committee can approve. Ambiguity here is the #1 cause of scope fights mid-programme.
Phase 2 — Build the landing zone before wave 1
No production workload should enter a subscription that lacks identity, policy, networking, logging, and budgets. For Microsoft estates that means management groups, Azure Policy, hub-and-spoke (or Virtual WAN), Entra ID Conditional Access + PIM, Defender for Cloud, and Log Analytics. Equivalent patterns exist on AWS (Control Tower / Organizations) and GCP (folders + org policies).
India-specific notes we bake into every cloud migration roadmap:
- Prefer Central India / South India (or equivalent in-country regions) for regulated data; design DR across Indian paired regions where zone redundancy is insufficient.
- Wire CERT-In-ready log retention and NTP to Indian time sources from day one — retrofitting after go-live is expensive.
- Tagging taxonomy (CostCenter, Environment, Owner) enforced by policy, not by email reminders.
Phase 3 — Wave planning and the project plan
A workable cloud migration project plan sequences waves by risk and dependency, not by "which VP shouted loudest":
- Wave 0: landing zone + pilot (dev/test or a low-traffic app) that proves tooling, IAM, and cutover runbooks.
- Wave 1: low-dependency production (file servers, print, simple web).
- Wave 2+: line-of-business apps with rehearsed cutovers.
- Final waves: ERP, core banking, tightly coupled Oracle/SQL estates — only after the pipeline is proven.
Each wave has entry criteria, a cutover checklist, automated validation (not "the app looks fine"), and a written rollback. Rehearse failback, not just failover.
Phase 4 — Execution patterns that avoid outages
- Continuous replication until the cutover window — stop-and-copy migrations are how you get multi-hour deltas.
- Pilot in a staging twin for databases and ERP; never learn Oracle character-set issues in production.
- Right-size within 30 days of move — discovery sizing is a starting point, not a forever SKU.
- Hand into operations with monitoring, backup restore tests, and a named SLA. A migration without an operate plan is a deferred incident.
For Oracle-specific estates (Database, E-Business Suite, GoldenGate/Data Guard topologies), use our dedicated Oracle Cloud migration service. For the decision framework in depth, read The 6 Rs of Cloud Migration. For Azure landing-zone detail, see the Azure migration checklist for Indian enterprises. For post-move cost control, see our guide on cloud cost optimisation and CERT-In compliance.
Timeline and cost reality checks
For a mid-size Indian estate (50–200 VMs), a disciplined programme is typically 3–6 months: 2–6 weeks discovery, 2–4 weeks landing zone, then 2–4 week waves. Quotes that promise "everything in six weeks" without discovery are marketing. Budget for the landing zone, tooling licences, parallel-run cloud spend, and post-move FinOps — not just the partner SOW.
Cloud migration strategy document — minimum contents
When stakeholders ask for a "strategy document," include at least:
- Business drivers and success metrics (cost, risk, agility).
- Inventory summary and dependency diagram.
- Per-application R decisions and rationale.
- Target architecture and region/residency choices.
- Wave plan with owners and windows.
- Risk register (licence, latency, skills, rollback).
- Operate model and FinOps cadence after go-live.
Where CloudSwift fits
CloudSwift is a Bengaluru-based Azure Expert MSP. We run funded assessments, write the migration roadmap, execute waves under change control, and take the estate into 24/7 managed cloud operations with a 99.97% uptime SLA. If you need a second opinion on a plan you already have — or a partner to own discovery through operate — start with our cloud migration services or talk to an architect.
