Cloud migration checklist for Indian companies

Moving to AWS, Azure or Google Cloud is mostly planning. This checklist covers what to do before, during and after the move, including the parts that are specific to India: local regions, the DPDP Act, CERT-In’s log rules and sector regulators.

Updated 6 October 20269 min readBy Effred editorial team

Start with an honest inventory

You cannot plan a move for systems you do not know you run. Before you compare clouds, list every application, server, database, scheduled job, file share and integration. Include the quiet ones: the macro that feeds payroll, the SFTP folder your bank drops statements into, the reporting server someone set up years ago.

For each application, record:

Owners — one on the business side and one technical.
Users and peaks — who uses it and when: month-end payroll, GST return dates, the March year-end close, festive-season sales.
Dependencies — what it calls, what calls it, and any hard-coded IP addresses.
Data — size, growth, and whether it holds personal data, payment data or anything a regulator cares about.
Recovery targets — how much data you can afford to lose (RPO) and how long it can be down (RTO).
Licences — whether your current licences allow cloud use, and what changes if you move.
Today’s cost — hardware, licences, AMC, power, space and people, so the comparison is honest.
Support status — operating system and database versions, and when their support ends.

Collect real utilisation data for a few weeks that include a month-end. It shows what to resize and what to switch off. AWS’s migration guidance, for example, treats applications averaging under 5% CPU and memory use as candidates to retire.

Decide what happens to each application: the 7 Rs

AWS groups migration strategies into seven Rs, and Azure and Google Cloud use similar ideas. Choose one per application, not one for the whole estate.

Strategy	What it means	A typical case
Retire	Switch it off and archive the data	An old intranet or report nobody has opened in months
Retain	Leave it where it is for now	A system tied to factory hardware, or one you upgraded last year
Rehost	Move it as it is to cloud virtual machines (“lift and shift”)	A stable line-of-business app on Windows Server
Relocate	Move servers to a cloud version of the same virtualisation platform, without changing the applications	A large virtualised estate that must leave a data centre by a deadline
Repurchase	Replace it with a SaaS product	An on-premise HR and payroll system replaced by a cloud HRMS such as Effred One
Replatform	Move it with a few changes, such as a managed database	A SQL Server database moved from a virtual machine to a managed database service
Refactor	Redesign it to use cloud-native services	A monolith that cannot cope with sale-day traffic

AWS advises against refactoring in the middle of a large migration. Move first by rehosting, relocating or replatforming, then modernise once you are in the cloud. And look hard for things to retire: every one is a server you never have to move, secure or pay for again.

Choose regions: what each cloud has in India

All three large clouds now run at least two regions in India, so you can keep both your main copy and a disaster-recovery copy in the country. As of October 2026:

Cloud	Region and code	City	Worth knowing
AWS	Asia Pacific (Mumbai), `ap-south-1`	Mumbai	Enabled by default; three Availability Zones
AWS	Asia Pacific (Hyderabad), `ap-south-2`	Hyderabad	Opt-in: enable it in your account first; three Availability Zones
Azure	Central India, `centralindia`	Pune	Three availability zones
Azure	India South Central, `indiasouthcentral`	Hyderabad	Opened in August 2026 with three availability zones; services are still being added
Azure	South India, `southindia`	Chennai	No availability zones; paired with Central India
Azure	West India, `westindia`	Mumbai	No availability zones; paired with South India
Google Cloud	`asia-south1`	Mumbai	Three zones
Google Cloud	`asia-south2`	Delhi	Three zones

Before you commit, check three things. First, service availability: not every service or machine type exists in every region, and new regions start with fewer. Second, price: the same resource can cost different amounts in different regions. Third, proximity: keep each application next to its database, and both close to the systems they talk to most.

Data residency, the DPDP Act and sector rules

Many people believe Indian law makes all personal data stay in India. It does not — but some data must, and the security rules are getting more specific.

The DPDP Act and Rules

The Digital Personal Data Protection Act, 2023 allows personal data to be transferred abroad unless the government restricts transfers to a notified country (section 16). The DPDP Rules, 2025 add that you must meet any requirements the government sets about making data available to a foreign state (rule 15). Section 16(2) keeps stricter sector laws in force, so a regulator’s localisation rule still applies.

The Rules also set minimum security safeguards (rule 6): encryption, masking or tokenisation; access control; logs, monitoring and review; backups so processing can continue; logs and personal data kept for one year to investigate breaches; and security terms in contracts with processors, such as your migration partner. A breach must be reported to the affected people without delay, and to the Data Protection Board — straight away, then in detail within 72 hours (rule 7). These duties apply from May 2027, eighteen months after the Rules were published in November 2025 (check MeitY’s website for any later amendment). Build them into the new environment now rather than retrofitting them.

CERT-In directions

CERT-In’s directions of 28 April 2022 apply to every body corporate. They require you to report specified cyber incidents within six hours of noticing them, keep logs of all ICT systems for a rolling 180 days, and synchronise system clocks with NIC or NPL time servers, or sources traceable to them. The directions say the logs must be maintained within Indian jurisdiction, but CERT-In’s May 2022 FAQs (Q35) allow them to be stored outside India if you can produce them to CERT-In in reasonable time; logs and records of financial transactions must stay in India. In cloud terms: an Indian-region log archive is the simplest way to comply; keep logs for at least 180 days (a year where DPDP rule 6 applies) and point servers at an approved time source.

Sector regulators

Some sectors go further. RBI’s 2018 directive requires payment system providers to store all payment system data only in India. Banks, NBFCs, brokers, insurers and healthcare providers should check their own regulator’s outsourcing and cloud rules before choosing a region.

This is a summary, not legal advice. If you handle financial, health or children’s data, ask counsel to review your region and logging plan before the first wave.

Build the landing zone first

A landing zone is the prepared cloud environment your applications move into: accounts, network, identity, logging and guardrails. Each cloud publishes a reference design — AWS Control Tower, Azure landing zones and Google Cloud’s landing zone guides. Build it, test it and write it as code before the first application moves.

Separate accounts, subscriptions or projects for production, non-production, shared services, logging and security.
Single sign-on through your identity provider, multi-factor authentication for everyone, and the root or global-admin account locked away.
An IP address plan that does not clash with your offices or data centre, plus a VPN or private connection back to them.
Private subnets for databases and internal services. Nothing public by default.
A central log archive in an Indian region, with the retention you need and protection from deletion.
Guardrail policies that block unapproved regions, public storage and unencrypted disks.
A tagging standard — owner, application, environment, cost centre — enforced from day one.

Keep the landing zone itself in infrastructure as code and review changes like any other code. Our DevOps team can set this up alongside a migration.

Set a security baseline

Encryption at rest and in transit by default, with keys in the cloud’s key management service and a rotation plan.
Secrets in a secrets manager, never in code or configuration files.
Least-privilege roles for people and for automation, and no shared logins.
Hardened images based on the CIS Benchmarks, and a patching schedule.
Backups you have actually restored, at least once, before go-live.
Vulnerability scanning and the cloud’s threat detection service switched on.
A security review, and a penetration test for anything facing the internet, before cut-over.

The security pillar of the AWS Well-Architected Framework, and its Azure and Google Cloud equivalents, make good checklists to review against.

Plan migration waves

Move in waves of applications that depend on each other, so you never run half a system in each place for long.

Pilot waveOne or two low-risk internal applications. The aim is to prove the landing zone, network, backups, monitoring and runbooks, not to save money.
Early wavesInternal tools and non-critical systems, mostly rehosted or replatformed.
Core wavesCustomer-facing and core systems, grouped by dependency, each with its own test and rollback plan.
Last waveThe hard cases — mainframes, hardware-bound systems, anything being refactored — or a decision to retain them.

Plan the calendar around the business. Do not move payroll in the last week of the month, finance systems near the March year-end close, or an online store in the run-up to Diwali. Every wave needs an owner, a runbook, a test plan, go/no-go criteria, a rollback plan and a note to users.

Cut over with a rollback ready

Cut-over is the moment real traffic moves. Two patterns keep it reversible:

Blue-green. Run the new environment alongside the old one, switch traffic with DNS or a load balancer, and keep the old one ready until you are sure. Rolling back means switching traffic back.
Canary. Send a small share of users or traffic to the new environment first, compare error rates and response times, then increase in steps.

Data is the hard part. Replicate databases continuously until cut-over, pause writes briefly for a final sync, and compare row counts or checksums. Lower DNS time-to-live values a few days before, so a switch — or a switch back — takes effect quickly.

Cut-over day checklist

Replication is current and a fresh backup exists.
Users, support and partners know the change window.
Changes on the old system are frozen.
The final sync is done and the data checked.
Traffic is switched.
Smoke tests pass on key journeys: sign in, place an order, run a payroll report.
Named people watch the dashboards for an agreed period.
The old system stays available, read-only, until sign-off.

Write the rollback trigger down before cut-over — for example, an error rate above an agreed level for fifteen minutes. Deciding under pressure at 2 a.m. is how short outages become long ones.

This is how we plan cloud migrations: every wave has a rollback ready before it starts.

Keep costs under control after go-live

Cloud bills creep up quietly: oversized machines, forgotten test environments, old snapshots and data transfer nobody planned for. Put these controls in place in the first month:

Budgets and alerts for every account, subscription or project, using AWS Budgets, Azure Cost Management or Google Cloud Billing budgets. An alert warns you; it does not switch anything off unless you set up an action.
Tags on everything, and a monthly review of spend by application and owner.
Right-sizing after a few weeks of real usage, not on day one.
Schedules that switch off development and test environments outside working hours.
Commitment discounts — AWS Savings Plans or Reserved Instances, Azure reservations, Google Cloud committed use discounts — only for the steady baseline you are sure of.
Storage lifecycle rules that move old data to cheaper tiers and delete what you no longer need.
One named owner for the cloud bill, with a monthly review alongside finance.

Then keep going. Review costs every quarter and the architecture every year: some of the biggest savings come later, when you replatform or refactor what you first lifted and shifted. If you would like a second pair of eyes on your plan, ask us for a migration assessment. After the move, DevOps for growing companies covers pipelines and monitoring, and Effred SIM can put AI agents on the production applications you run there.

Common questions

What are the 7 Rs of cloud migration?

They are the seven strategies in AWS’s migration guidance: retire, retain, rehost, relocate, repurchase, replatform and refactor (or re-architect). You choose one for each application, based on its value, its risk and how much you want to change it.

Does the DPDP Act require data to be stored in India?

Not in general. The DPDP Act allows transfers abroad unless the government restricts a notified country, but stricter sector rules still apply: RBI, for example, requires payment system data to be stored only in India. CERT-In also requires ICT system logs to be kept for 180 days and produced on request; logs of financial transactions must be kept in India.

Which cloud regions are available in India?

As of October 2026: AWS Mumbai (ap-south-1) and Hyderabad (ap-south-2); Azure Central India (Pune), South India (Chennai), West India (Mumbai) and India South Central (Hyderabad); and Google Cloud Mumbai (asia-south1) and Delhi (asia-south2).

How do you migrate to the cloud without downtime?

Replicate data continuously, then cut over with a blue-green or canary approach so traffic can move back quickly. Lower DNS time-to-live values in advance, agree a rollback trigger and keep the old system available until sign-off. Some systems still need a short, planned window for the final data sync.

How long does a cloud migration take?

Start with an assessment — ours takes two weeks — that maps your workloads and dependencies and ends with a plan dating each migration wave. After that, it depends on how many applications move and how much changes on the way.

Sources

AWS Prescriptive Guidance — migration strategies (the 7 Rs) (opens in a new tab)docs.aws.amazon.com
AWS Regions — AWS documentation (opens in a new tab)docs.aws.amazon.com
List of Azure regions — Microsoft Learn (opens in a new tab)learn.microsoft.com
Microsoft’s India South Central region goes live, 6 August 2026 — Microsoft (opens in a new tab)news.microsoft.com
Cloud Storage locations (asia-south1, asia-south2) — Google Cloud (opens in a new tab)docs.cloud.google.com
Digital Personal Data Protection Act, 2023, section 16 — MeitY (opens in a new tab)meity.gov.in
Digital Personal Data Protection Rules, 2025, rules 1, 6, 7 and 15 — MeitY (opens in a new tab)meity.gov.in
CERT-In directions under section 70B(6) of the IT Act, 28 April 2022 (opens in a new tab)cert-in.org.in
CERT-In FAQs on the Cyber Security Directions, May 2022 (Q35 and Q36, where logs may be stored) (opens in a new tab)cert-in.org.in
Storage of Payment System Data, 6 April 2018 — Reserve Bank of India (opens in a new tab)rbi.org.in
What is AWS Control Tower? — AWS documentation (opens in a new tab)docs.aws.amazon.com
Azure landing zones — Cloud Adoption Framework, Microsoft Learn (opens in a new tab)learn.microsoft.com
Landing zone design in Google Cloud — Google Cloud (opens in a new tab)docs.cloud.google.com
CIS Benchmarks — Center for Internet Security (opens in a new tab)cisecurity.org
AWS Well-Architected Framework — security pillar (opens in a new tab)docs.aws.amazon.com
Blue/green deployments on AWS — AWS whitepaper (opens in a new tab)docs.aws.amazon.com
Canarying releases — Google SRE Workbook (opens in a new tab)sre.google
Managing your costs with AWS Budgets — AWS documentation (opens in a new tab)docs.aws.amazon.com
Create and manage budgets — Azure Cost Management, Microsoft Learn (opens in a new tab)learn.microsoft.com
Create, edit or delete budgets and budget alerts — Google Cloud Billing (opens in a new tab)docs.cloud.google.com

First published 5 October 2026. Spotted something out of date or unclear? Email info@effred.com and we will look at it.