Most cloud migrations that go wrong don't fail because of the cloud. They fail because nobody knew what was actually running on the old server, the cutover happened on a busy Monday, or the first month's bill was double the estimate. This guide gives you a step-by-step plan, from inventory to post-launch cost control, that keeps the business running while you move.
It applies whether you're moving one ERP system or your whole stack to AWS, Microsoft Azure or Google Cloud.
First, be clear about why you're moving
"Everyone is moving to the cloud" is not a reason. Write down the two or three outcomes you want; they decide which workloads move first, how much downtime is acceptable, and whether you move servers as-is or rebuild applications.
The usual triggers we see:
- Hardware is due for renewal. A server refresh or end-of-support operating system is often the cheapest moment to move.
- Capacity limits. Slow applications, full disks, or seasonal peaks (a festive-season sale, year-end close) the current box can't handle.
- Painful remote access. Staff rely on fragile VPNs to reach on-premises apps.
- Weak disaster recovery. Backups sit on one external drive in the same building as the server.
- Blocked capabilities. Analytics, automation or AI features that are hard to bolt onto legacy infrastructure.
Turn these into measurable targets, for example "restore any system within four hours", "provision a new environment in under a day" or "keep monthly infrastructure spend within ₹X". You'll use them to judge whether the migration worked.
Step 1: Inventory everything and map dependencies
You can't migrate what you haven't found. Build a register (a spreadsheet is fine) of every server, VM, database, application, file share, scheduled job and integration, recording:
- What it does and who owns it in the business
- How critical it is (what happens if it's down for an hour? a day?)
- Operating system, database engine and versions
- Licensing terms (some licences don't transfer to the cloud cleanly)
- What it talks to: other databases, APIs, payment gateways, email relays, identity systems, hard-coded IP addresses
The dependency column is where migrations break: an app that passed testing fails in production because a nightly report still reads from a database that stayed on-premises. Provider tools such as Azure Migrate can map server-to-server connections automatically, but confirm with the people who use the systems.
Also capture a performance baseline (CPU, memory, disk growth, network traffic, response times) over a few normal weeks including a busy period. It drives correct sizing and gives you something to compare against after cutover.
Step 2: Decide what happens to each workload (the 7 Rs)
Not every application should move the same way, and some shouldn't move at all. The "7 Rs" framework, popularised by AWS, gives you a vocabulary for deciding per workload.
| Strategy | What it means | Good fit for |
|---|---|---|
| Retire | Switch it off | Apps nobody uses; duplicates found during inventory |
| Retain | Leave it where it is, for now | Systems tied to special hardware, licences or regulation |
| Rehost ("lift and shift") | Move the server as-is to a cloud VM | Fast moves, stable apps, hardware deadlines |
| Relocate | Move a whole virtualised platform (e.g. VMware) to a compatible cloud service | Large VMware estates |
| Replatform | Small changes, such as moving the database to a managed service | Getting quick wins without a rewrite |
| Repurchase | Replace with a SaaS product | Commodity functions: email, CRM, HR, accounting |
| Refactor | Re-architect for cloud-native services (containers, serverless, auto-scaling) | Core products that need to scale or change often |
For most SMBs the answer is a mix: retire a few things, move email and office tools to SaaS, rehost or replatform line-of-business apps, and refactor only where scale or speed really matters. Refactoring delivers the most long-term value but costs the most time, so don't make it the default.
Step 3: Choose your platform and deployment model
All three major providers are reliable enough for a typical business. The real question is which fits what you already run and the skills you have.
| Provider | Tends to suit |
|---|---|
| AWS | The broadest service catalogue and ecosystem; teams that want the widest choice of managed services |
| Microsoft Azure | Businesses already on Microsoft 365, Windows Server, Active Directory / Entra ID, SQL Server or Dynamics; hybrid setups |
| Google Cloud | Data-heavy and analytics-led products, Kubernetes-first teams, AI/ML workloads |
All three operate data-centre regions in India (AWS in Mumbai and Hyderabad; Azure in Pune, Chennai and Mumbai; Google Cloud in Mumbai and Delhi), which helps with latency for Indian users and with any data-residency requirements in your sector. Make sure personal data is handled in line with India's Digital Personal Data Protection (DPDP) Act, and check any sector-specific requirements, such as RBI rules for payment data, rather than assuming.
On deployment model: public cloud is the default for most SMBs and startups; a private cloud (dedicated infrastructure) costs much more and is usually justified only by strict regulation; hybrid, with some systems staying on-premises, is common during a phased move and a sensible long-term state if a few systems must stay local.
Either way, success depends far more on planning and execution than on the logo. For a second opinion on platform fit, our cloud infrastructure and DevOps team can review your inventory with you.
Step 4: Build the landing zone before moving anything
A "landing zone" is the foundation every migrated workload sits on. Skip it and you get a cloud account that's harder to secure than the server room you left. Set up first:
- Identity and access: individual accounts (no shared admin logins), MFA for all privileged users, least-privilege roles, and the root/owner account locked away.
- Networking: virtual networks, subnets, security groups, DNS, and a secure link (site-to-site VPN or private connection) to anything staying on-premises.
- Naming and tagging: consistent resource names plus tags for owner, environment and cost centre, so cost reports are readable later.
- Logging and monitoring: audit logs, metrics and alerts switched on from day one, so problems after cutover are spotted by you rather than by customers. Our monitoring and observability service covers this in depth.
- Infrastructure as code: define the environment in Terraform, Bicep, CloudFormation or similar, so it's repeatable and reviewable rather than clicked together.
Photo: VGrigas (WMF) · CC BY-SA 3.0 · Wikimedia Commons
Step 5: Build security and compliance into the design
Providers secure the data centres and core infrastructure; you remain responsible for your data, access, configuration and applications. Misunderstanding this shared responsibility model is behind most cloud security incidents: public storage buckets, overly broad permissions, unpatched VMs.
Before you migrate:
- Classify your data as public, internal, confidential or highly sensitive (customer, financial, payment, health). Each class gets its own access, encryption and backup rules.
- Encrypt in transit and at rest: TLS on every connection; storage and database encryption on, with provider- or customer-managed keys.
- Lock down identity: connect cloud sign-in to your existing directory, enforce MFA, review access regularly, log every admin action.
- Check compliance fit early: if you need ISO 27001, SOC 2, PCI DSS or sector controls, confirm the services you plan to use support them before designing around them.
- Turn on configuration scanning that flags public storage, open ports and excessive permissions from day one.
For regulated workloads, our security and compliance work covers the controls auditors typically ask for.
Step 6: Pilot first, then migrate in waves
Now the moving begins, in order of risk, lowest first.
Run a pilot. Migrate a non-critical workload, such as an internal tool or test environment, end to end. You'll learn how long transfers really take and what your runbook is missing, without risking customers.
Take and test backups. Before every wave, take independent backups of everything you're moving and prove you can restore them. A backup you haven't restored is an assumption, not a backup.
Move in waves. Move each app together with its database and integrations. Internal systems go first; customer-facing and revenue-critical systems go last, once the process is routine.
Work out how the data will travel. Do the arithmetic early: at a sustained 100 Mbps, 1 TB takes roughly a day of continuous transfer, before any slowdowns or competing office traffic. Up to a few hundred gigabytes, online transfer (AWS DataSync, AzCopy, Google's Storage Transfer Service, or plain rsync/robocopy) is usually fine. For multiple terabytes over a modest connection, ask your provider about offline transfer appliances such as Azure Data Box or Google Transfer Appliance (availability varies by region and changes over time), or move the historical bulk early and sync only recent changes later.
Keep downtime short with replication. Rather than one giant copy during a long outage, replicate databases continuously to the new environment, then do a short final sync and switch traffic over. The providers' own services handle much of this: AWS Application Migration Service and AWS Database Migration Service, Azure Migrate and Azure Database Migration Service, and Google Cloud's Migrate to Virtual Machines and Database Migration Service.
Script the cutover. A typical runbook for each wave:
- A day or two before, lower the DNS TTL on the records you'll change, so the switch propagates quickly.
- Stop writes on the old system (maintenance mode or read-only).
- Run the final sync and confirm replication lag is zero.
- Validate the data: row counts per table, file counts and sizes, checksums, and a spot-check of real records.
- Update DNS, connection strings and any hard-coded IP addresses found in Step 1.
- Start the applications, run smoke tests, and watch logs and metrics closely for the first 24–48 hours.
Write the rollback plan before cutover. Decide in advance what failure looks like, who makes the call, and exactly how traffic goes back to the old system. Keep the old environment intact until the new one has proved itself.
Tell people. Give staff, customers and partners advance notice of maintenance windows, and schedule cutovers for your quietest period, not the end of the month or the day before a sale.
Step 7: Test before you switch anything off
A migration that "completes" isn't one that works. Before decommissioning the old environment, check:
| Test | What to check |
|---|---|
| Data integrity | Record and file counts match the source; checksums agree; reports for a recent period give the same totals |
| Functional | Logins, payments, reports, integrations, scheduled jobs, emails and notifications all behave as before |
| Performance | Response times and throughput against the baseline from Step 1, under realistic load |
| Security | Access controls, encryption, firewall rules, audit logging, vulnerability scan |
| Disaster recovery | Restore from backup and fail over in a controlled test; time how long it takes |
| User acceptance | People from each department run their normal daily tasks and sign off |
User acceptance testing is the most often skipped, yet it catches what technical teams miss, like a changed export format that breaks someone's monthly process.
Step 8: Prepare your people
A technically perfect migration still disappoints if people don't know how to work with it. Train by role:
- IT administrators: the cloud console, monitoring, backups, access management and cost reporting.
- Developers: deployment pipelines, managed services, and how the new environments differ from the old servers. Automating releases with CI/CD pipelines is usually worth doing at this stage.
- Everyone else: how to access applications, what has changed in their workflow, and the updated security rules (MFA, approved devices).
Keep short, current documentation, name a go-to person in each team, and explain why the move is happening.
Step 9: Monitor, optimise and control costs
Go-live is the start of operating in the cloud, not the end. The biggest ongoing risk for SMBs is cost creep: resources are easy to create and easy to forget.
- Set budgets and alerts from day one (for example at 50%, 75% and 90% of the monthly budget, plus a forecast alert), so overspend is flagged within days, not at month-end.
- Right-size after a few weeks: downsize instances that are mostly idle.
- Clean up regularly: unattached disks, old snapshots, stopped VMs, forgotten test environments.
- Use commitment discounts (reserved instances, savings plans, committed-use discounts) for steady workloads once usage is stable.
- Schedule non-production environments to shut down outside working hours.
- Keep security continuous: patching, access reviews and configuration scans don't stop after migration.
Performance tuning, such as caching, a CDN, database indexing and auto-scaling, belongs in the same regular review.
What a cloud migration actually costs
Budget for more than the monthly cloud bill. The main cost lines are:
- Cloud resources: compute, databases, storage, backups, networking, monitoring. Size from your baseline, not by copying today's hardware.
- Data transfer: data into the cloud is usually free, but data going out (to users, on-premises, between regions) is charged and easy to underestimate.
- Parallel running: for a while you pay for both old and new environments.
- Tooling and expertise: core migration services are low-cost or free, but you may need specialist help with planning, security and cutover.
- Training: for both technical staff and end users.
- Licences: check whether existing software licences can be brought to the cloud or need replacing.
Compare the three-year total against the full cost of staying put: hardware refreshes, maintenance contracts, power, backup infrastructure and staff time. That comparison, not the first invoice, tells you whether the move pays off.
How long does it take, and will there be downtime?
It depends on the number of applications, data volume and how tangled the dependencies are. A business with a handful of servers can often finish a well-planned migration in a few weeks; dozens of interconnected applications usually means several months in phases. Zero downtime isn't always realistic for older systems, but replication plus a rehearsed cutover at a quiet time keeps most interruptions to a short planned window.
Key takeaways
- Goals and success measures written down; full inventory, dependency map and baseline done
- A 7 Rs decision for every workload, including what to retire
- Landing zone ready: identity, MFA, networking, tagging, logging, IaC
- Data classified; encryption and compliance designed in
- Pilot done, backups restored, rollback plan written, cutovers at quiet times
- Functional, performance, security, DR and user acceptance tests passed
- Budgets, alerts and a monthly cost and security review in place
If you'd like help planning or running your move, from the first inventory to post-launch optimisation, see our cloud infrastructure and DevOps services or get in touch for a free consultation and a no-obligation chat with TrackMy Tech. We'll be happy to help, and if it's a fit, we can also help make your product or platform DPDP-compliant as part of the move.