Cloud migration sounds like a single event: one weekend, the website moves from an old server to AWS, Azure or Google Cloud. In practice, a successful migration is a project with distinct phases - and almost every painful migration story we hear comes from skipping one of them. Emails stop working because nobody listed the MX records. A payment callback fails because the new server's IP was not whitelisted. A forgotten scheduled job stops sending invoices.
This checklist walks through each phase in order. It applies whether you are moving a single WordPress site, a Laravel or Node.js application, or a set of internal tools.
Phase 1: Assess what you have
You cannot move what you have not listed. Build a simple inventory.
Applications and services
- Websites, web apps, admin panels and APIs
- Mobile app back-ends
- Background jobs, queues and scheduled tasks (cron)
- Third-party integrations - payment gateways such as Razorpay, SMS and WhatsApp providers, ERPs, shipping and accounting tools
Data
- Databases (type, version, size, growth)
- Uploaded files and media
- Logs and backups that must be retained
Network and domains
- Domain registrar and DNS provider
- All DNS records - A, CNAME, MX, TXT (SPF, DKIM, DMARC), and verification records
- SSL certificates and how they renew
- IP addresses that partners or banks have whitelisted
People and dependencies
- Who uses each system and when it is busiest
- Who has access today
- Business impact if each system is unavailable for an hour, a day, a week
Phase 2: Choose a strategy for each workload
Not everything should move the same way. Industry guidance commonly describes several approaches, often called the "Rs" of migration.
| Strategy | What it means | When it fits |
| --- | --- | --- |
| Rehost (lift and shift) | Move as-is to cloud virtual machines | Fast moves, legacy apps, tight timelines |
| Replatform | Small changes, such as a managed database or object storage for media | Quick wins in reliability with limited code change |
| Refactor | Redesign for containers, serverless or managed services | Products that need to scale or change rapidly |
| Repurchase | Replace with a SaaS product | Commodity tools such as email, HR or ticketing |
| Retire | Switch off | Unused or duplicate systems |
| Retain | Leave where it is for now | Systems with constraints or low benefit from moving |
Many businesses rehost first to get out of an ageing server, then replatform or refactor gradually.
Phase 3: Design the target environment
Region and availability
Choose a region close to your users - for most Indian audiences, a region in India. Decide whether you need multiple availability zones for resilience.
Accounts and access
- Separate environments (development, staging, production), ideally in separate accounts or projects
- Role-based access with least privilege
- Multi-factor authentication for every human user
- No shared root or admin logins
Networking and security
- Private networks for databases, with only necessary ports exposed
- Firewalls or security groups, a web application firewall where useful
- Encryption at rest and in transit
- Secrets stored in a secrets manager, not in code
Our cyber security team can review this design before anything goes live.
Backups, monitoring and logging
Set these up before migration, not after. Define backup retention, alerts for downtime and errors, and central logging.
Compliance and data
If you process personal data of Indian users, keep the Digital Personal Data Protection Act, 2023 and its rules in mind. Regulated sectors may have specific data localisation expectations. Confirm with your compliance advisor.
Phase 4: Prepare and test
- Build the target environment, ideally with infrastructure as code so it can be recreated.
- Copy the application and a recent data snapshot.
- Test every critical journey: login, forms, search, checkout, payment callbacks, emails, file uploads, admin functions and integrations.
- Run a basic load test if traffic is significant.
- Inform partners whose systems whitelist your IP addresses.
- Write a cutover runbook: every step, who does it, expected time and how to verify it.
- Write a rollback plan: what triggers it and how to switch back.
Phase 5: Migrate data and cut over
- Lower DNS TTL values a day or two before the move.
- Announce a short maintenance window if needed, at a quiet time.
- Freeze changes on the old system, or set up continuous data replication.
- Run the final data sync and verify record counts and recent entries.
- Switch DNS or the load balancer to the new environment.
- Run the post-cutover test checklist immediately.
- Watch error logs, payment confirmations, form submissions and email delivery closely for the first hours and days.
- Keep the old environment available for a defined period as a fallback.
Email warning: if mailboxes are hosted on the old server, treat email migration as a separate, carefully planned task. Changing MX records without a plan is one of the fastest ways to lose business email.
Phase 6: Optimise and hand over
Migration is complete when the new environment is stable, documented and efficient - not just when DNS points to it.
- Right-size servers based on real usage after a few weeks.
- Switch off old servers, unused snapshots and test resources.
- Enable autoscaling or scheduled scaling where it helps.
- Review security findings and access permissions.
- Document architecture, runbooks and contacts.
- Set up automated deployments so future releases are consistent - see our separate CI/CD guide on this blog.
The checklist at a glance
| Phase | Must-have before moving on |
| --- | --- |
| Assess | Complete inventory of apps, data, DNS, integrations and owners |
| Strategy | Agreed approach per workload |
| Design | Region, accounts, access, network, backups, monitoring defined |
| Prepare | Target built and tested, runbook and rollback plan written |
| Cut over | Final sync verified, tests passed, close monitoring in place |
| Optimise | Right-sized, old resources removed, documentation complete |
Common migration mistakes
- Forgetting DNS records other than the website - especially email and verification records
- Not informing payment gateways, banks or partners about new IP addresses
- Migrating without tested backups of the old system
- Copying old security problems (open ports, shared passwords) into the new environment
- Leaving test servers running long after the project ends
- No single owner for the cutover decision
Who should be involved
Even a small migration benefits from clear roles. Someone from the business side should confirm which journeys matter most and sign off the test checklist. A technical lead should own the runbook and the go or no-go decision on cutover day. Someone should be responsible for talking to partners such as the payment gateway, the email provider and any vendor that connects to your systems. If any integrations were built years ago by a developer who has moved on, budget extra time to understand them - they are where surprises usually hide.
Key takeaways
- Start with a complete inventory; most surprises come from forgotten pieces.
- Choose a strategy per workload - rehost, replatform, refactor, repurchase, retire or retain.
- Design access, security, backups and monitoring before migrating.
- Test thoroughly, write a runbook and a rollback plan, and plan email separately.
- Optimise and document after the move so the cloud setup stays healthy.
Planning a move to the cloud? Book a free consultation with our cloud and DevOps engineers in Jaipur. We will review your current setup, recommend the right migration approach and share a written plan. If your application needs changes to run well in the cloud, our custom software development team can handle that too.
