A cloud migration moves each workload to a cloud region you chose on purpose, with a tested way back. This guide gives eight steps in order. The Indian checks sit in steps 2, 3 and 7: classify your data, decide where it may live, and keep the logs the law asks for.
Last reviewed 8 November 2026 against the sources listed at the end. This is a planning guide, not legal advice. Have your counsel read the texts linked at the end.
Step 1: List what you run
Write one row per application. Record the owner, the users, the data it holds, what it connects to, and how much it is used.
Use the usage column to cut the list. AWS's migration guidance suggests retiring "zombie" applications with average CPU and memory under 5 percent, and checking applications with no inbound connection for 90 days. Every application you retire is a workload you do not pay to move.
Step 2: Classify the data in each application
Mark each application with the kinds of data it holds. Three kinds change your plan.
- Personal data of customers, patients, students or staff. The Digital Personal Data Protection (DPDP) Act, 2023 applies.
- Payment data, if you run a payment system. RBI's 2018 circular on payment data applies.
- Logs and security records, which every system produces. CERT-In's Directions apply.
An application with none of these has the most freedom of choice. One with all three needs the plan below.
Step 3: Decide where data may live
The rules and what each one forces
Read each rule once, then write the result as a line in your plan. Do this before you choose a region or a provider.
|
Rule |
What it says |
What it forces in the plan |
|---|---|---|
|
DPDP Act, 2023, section 16 |
The Central Government may restrict transfers of personal data to countries it notifies. |
Keep a list of every country your data and backups touch, so you can react to a notification. |
|
DPDP Rules, 2025, rule 15 |
Data may leave India, subject to requirements the Government sets for making it available to a foreign State or its agencies. |
Record which foreign-owned processors or support staff can reach your data. |
|
DPDP Rules, 2025, rule 6 |
Safeguards must include encryption, masking or tokens, access control, logs and monitoring, backups, and a contract clause binding the processor. |
Put these in the landing zone (step 5) and in the provider contract. |
|
DPDP Rules, 2025, rules 6 and 8 |
Logs and personal data are kept for one year, unless another law says longer. The Rules' own example says a cloud provider hosting customer records must keep data and logs for that year too. |
Set provider retention to match. Do not delete old environments early. |
|
CERT-In Directions, 28 April 2022 |
Report listed incidents within 6 hours of noticing. Keep logs for a rolling 180 days within Indian jurisdiction. Sync clocks to NIC or NPL time servers. |
Ship logs to storage in India. Configure time sync. Name who reports. |
|
Per RBI, payment system data is stored only in India. Processing abroad is allowed if the data returns within one business day or 24 hours, whichever is earlier. |
Pin payment workloads to Indian regions. Check any foreign processing leg. |
|
|
Per MeitY's guidelines, it has empanelled cloud providers for public, virtual private and government community cloud models, for use by departments at the Centre and States. |
If you sell to or run for a government body, check the tender for empanelled offerings. |
What empanelment does and does not decide
Empanelment is a procurement route for government bodies. The DPDP Act does not require a private company to use an empanelled cloud. Check your own tender documents and your sector regulator's directions before you assume either way.
MeitY's procurement guidelines say a government department can buy cloud services directly from a provider, through a managed service provider, or end to end through a system integrator, with empanelled offerings published through GeM. The guidelines call themselves advisory. If you serve a government body, ask which empanelled offerings its tender accepts before you pick a region.
Step 4: Choose a strategy per workload
Each workload gets one of seven treatments. AWS names them the 7 Rs.
|
Strategy |
Meaning |
Use when |
|---|---|---|
|
Retire |
Switch it off |
Step 1 showed no use |
|
Retain |
Leave it where it is |
A data-residency rule or plant hardware blocks the move |
|
Rehost |
Move servers unchanged ("lift and shift") |
You need speed and the application is stable |
|
Relocate |
Move to the same platform in the cloud |
The platform exists as a cloud service |
|
Repurchase |
Replace with a SaaS product |
A packaged product fits the process |
|
Replatform |
Move with small changes, such as a managed database |
You want lower running cost without a rewrite |
|
Refactor |
Redesign for the cloud |
The application blocks the business and you accept the cost |
AWS advises against refactoring during a large migration. Move first, then modernise once the workload runs in the cloud. AWS also lists machines in a manufacturing plant, and mainframe or AS/400 applications, as common reasons to retain.
Step 5: Build the landing zone first
A landing zone is the set-up every workload will sit in. Build and review it before any workload moves.
- Separate accounts or subscriptions for production, testing and shared services
- Named roles with least privilege, and no shared logins
- Encryption at rest and in transit, with keys you control
- Central logging to Indian storage, with time sync
- Backups, tested by restoring them
- Cost tags on every resource: owner, application, environment
These items map to the safeguards in DPDP rule 6 and the logging in the CERT-In Directions. Writing them once here saves repeating them per application.
Step 6: Set cost guardrails before the first move
Plan for three things that inflate a first cloud bill. Old and new systems run side by side. Servers are sized to the old hardware, not the real load. Nobody owns each line of the bill.
- Set a budget and an alert per application, using the tags from step 5.
- Size servers from measured usage in step 1, not from the old specification.
- Agree how long the old system runs alongside the new one, and put the end date in the plan.
- Review the bill monthly with the application owner for the first quarter.
- Delay long-term commitments until you have a few months of real usage.
Treat the dual-running period as a budget line with an end date.
Step 7: Move in waves, with a rollback written down
Start with a low-risk workload that exercises the whole path: network, access, logging, cutover. Learn there. Then move in waves, grouping applications that depend on each other.
Write the rollback plan before the first cutover, and rehearse it.
Rollback checklist, per wave
- The trigger is written: which failures, measured how, by whom, within what time.
- The old system stays intact and recoverable until the trigger window closes.
- Data written in the cloud during the window can be copied back, or you have decided to accept its loss.
- The cutover has been rehearsed end to end on a copy.
- Access to the old environment is kept until the window closes.
- One named person decides to go or to roll back.
Rehearsal matters most for the database. A migration that cannot be reversed is a bet, not a plan.
Step 8: Run it, then close the old estate
After cutover, test the things a migration quietly breaks: incident reporting within CERT-In's 6 hours, log retention, backup restores and the failover drill.
Then switch off the old estate. Keep the one-year log and data retention in mind first (step 3), and archive what the law requires you to keep. Running old and new together with no end date is a cost you can avoid.
Close each wave with a short written review: what the move cost against plan, what broke, and which entries in the rules table changed. File it with the migration plan so the next wave starts from facts, not memory.
Who owns each step
A migration stalls when nobody owns a step. Name one person for each.
- Steps 1 and 2: the application owners, with IT. Only they know what the data is and who uses it.
- Step 3: your legal or compliance lead, who signs the data-location decisions.
- Steps 4 and 5: the cloud architect, who proposes the strategy per workload and builds the landing zone.
- Step 6: finance with IT, who agree budgets and review the first bills.
- Step 7: a cutover lead for each wave, who holds the go or rollback decision.
- Step 8: operations, who run incident reporting, backups and the switch-off of the old estate.
One executive sponsor settles disputes between them. Without that role, a data-location question can sit unanswered for weeks while engineers wait.
Questions teams ask
Do we have to host personal data in India?
The DPDP Act does not require it. Section 16 lets the Government restrict transfers to countries it notifies, and other laws may be stricter. Per RBI's FAQ on its 2018 circular, payment system data must be stored only in India.
Does a private company need a MeitY-empanelled cloud?
Empanelment governs what central and state government bodies buy. A private company follows its own contracts, its regulator and the rules above. If you serve government clients, expect their tender to ask for it.
How long does a migration take?
It depends on how many workloads you move, their dependencies, and the condition of the data. Step 1 gives you the count; ask any provider to size the plan from that list.
Where Brihat fits
Brihat Infotech's cloud architecture and migration service plans each workload move with a rollback and a cost view. Start a conversation.
Sources and primary texts
- Digital Personal Data Protection Act, 2023 (MeitY, PDF)
- Digital Personal Data Protection Rules, 2025, Gazette of India, 13 November 2025 (MeitY, PDF)
- CERT-In Directions under section 70B(6), 28 April 2022
- RBI: Storage of Payment System Data, FAQ on the 6 April 2018 circular
- MeitY: Guidelines for Procurement of Cloud Services (PDF)
- MeitY AMBUD portal for cloud empanelment
- AWS Prescriptive Guidance: migration strategies