Legacy applications are rarely moved to the cloud on a whim. Hardware refresh cycles, data centre contracts, rising virtualisation licensing costs, operating systems and databases reaching end of support, and the need for scalability and AI-ready data all push organisations to migrate.
The technology to migrate is mature. What still goes wrong is planning: applications moved without understanding dependencies, landing zones built after workloads arrive, and cloud bills that grow faster than expected. This cloud migration checklist walks through the four phases of a successful migration, with practical items for each.
Common triggers for migrating now
- End of support: Windows Server 2012 and 2012 R2 reached end of extended support in October 2023, SQL Server 2014 in July 2024 and SQL Server 2016 in July 2026, while Windows Server 2016 extended support ends in January 2027. CentOS 7 reached end of life in June 2024.
- Virtualisation licensing changes that have significantly increased costs for some on-premises estates.
- Data centre contract renewals and hardware refresh cycles.
- Scalability and resilience requirements that are expensive to meet on-premises.
- Data and AI initiatives that need modern data platforms.
What are the 7 Rs of cloud migration?
| Strategy | What it means | Use it when |
|---|---|---|
| Retire | Decommission the application | It has few users or its function exists elsewhere |
| Retain | Keep it where it is for now | It is due for replacement, highly specialised or blocked by regulation |
| Rehost (lift and shift) | Move virtual machines as they are | You need speed, low risk or a data centre exit deadline |
| Relocate | Move a virtualised platform to a cloud-hosted equivalent | You want to move many VMs quickly without changing them |
| Replatform (lift and reshape) | Make targeted changes, such as moving to managed databases | You want quick cloud benefits without a rewrite |
| Repurchase | Replace with a SaaS product | A commodity capability has good SaaS options |
| Refactor (re-architect) | Rebuild using cloud-native services such as containers, serverless and managed data | The application is strategic and needs scale, agility or major new features |
Repurchase decisions are covered in more detail in our build versus buy guide.
Phase 1: Assess
- Build a complete application inventory: owners, users, business criticality and lifecycle plans.
- Discover infrastructure automatically with provider tools, such as Azure Migrate, Google Cloud Migration Center or AWS discovery and migration services, alongside existing monitoring data.
- Map dependencies between applications, databases, file shares, batch jobs and external interfaces.
- Capture performance baselines: CPU, memory, storage, IOPS and network throughput at peak.
- Record licensing constraints for operating systems, databases and third-party software.
- Identify compliance and data residency requirements for each application.
- Estimate current total cost of ownership, including hardware, facilities, licences and staff time.
- Assign a 7 Rs strategy and a target architecture to every application.
- Build the business case, including dual-running costs during migration.
What is a cloud landing zone?
A landing zone is the secure, well-architected foundation that every migrated workload lands in. It defines how cloud accounts or subscriptions are organised, how people and systems authenticate, how networks connect to offices and data centres, which security and compliance guardrails are enforced automatically, and how logs and costs are collected. Each major cloud provider publishes reference guidance for building one. Building the landing zone before the first production application moves avoids retrofitting security and networking around live systems later, which is slower, riskier and more expensive.
Phase 2: Plan and prepare the landing zone
- Account or subscription structure separating production, non-production and shared services.
- Identity and access: single sign-on, least privilege, MFA and break-glass accounts.
- Networking: address ranges, hub-and-spoke or equivalent topology, hybrid connectivity and DNS.
- Security baseline: encryption defaults, key management, security monitoring and guardrail policies.
- Logging and monitoring centralised from day one.
- Backup and disaster recovery with defined recovery point and recovery time objectives per application.
- Cost management: mandatory tagging, budgets and alerts.
- Infrastructure as code so environments are repeatable and reviewable.
- Wave plan: group applications by dependencies and risk, starting with a low-risk pilot wave.
- Runbooks and rollback plans for every application cut-over.
Phase 3: Migrate
- Run a pilot wave to validate tooling, runbooks and team roles.
- Choose a data migration method per system: offline transfer, continuous replication or application-level synchronisation.
- Lower DNS time-to-live values ahead of cut-over.
- Test functionality, performance, integrations and security in the target environment before switching.
- Agree a change freeze and communication plan with business owners.
- Execute cut-over with go/no-go checkpoints and a defined rollback deadline.
- Monitor closely during hypercare and keep the source environment available until sign-off.
- Update documentation, support procedures and configuration management records.
Phase 4: Optimise
- Rightsize compute and storage based on real utilisation after two to four weeks.
- Apply committed-use discounts, reservations or savings plans to steady workloads.
- Schedule non-production environments to shut down outside working hours.
- Move suitable components to managed services to reduce operational effort.
- Review security posture findings and fix high-risk items.
- Establish monthly FinOps reviews with application owners.
- Plan the next modernisation steps, such as containerisation or refactoring strategic applications.
Who should be on the migration team?
- Executive sponsor who owns the business case and resolves priority conflicts
- Cloud architect responsible for the landing zone and target architectures
- Migration lead who runs wave planning, runbooks and cut-overs
- Application owners who know how each system is used and sign off testing
- Security and compliance lead involved from design, not just before go-live
- Database and infrastructure engineers for data migration and platform build
- FinOps owner who tracks spend against the business case from the first wave
AWS vs Azure vs Google Cloud: how to choose
| Consideration | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Often chosen for | Breadth of services, mature ecosystem, wide partner and marketplace options | Microsoft-centric estates, Windows and SQL Server workloads, Microsoft identity integration | Data analytics, machine learning and Kubernetes-based platforms |
| Licensing considerations | Bring-your-own-licence options vary by product | Licence benefits for existing Windows Server and SQL Server customers | Bring-your-own-licence options vary by product |
| Data and AI platforms | Broad analytics and AI services, including managed foundation models | Strong integration with Microsoft data and productivity tools | Highly regarded analytics warehouse and AI platform |
| Skills | Large talent pool | Natural fit for Microsoft-skilled teams | Smaller but strong specialist talent pool |
Many enterprises end up multi-cloud for specific workloads, but migrating most applications to one primary provider keeps governance, skills and costs simpler.
Security and compliance essentials
- Understand the shared responsibility model: the provider secures the cloud; you secure what you run in it.
- Encrypt data at rest and in transit, and control who manages keys.
- Centralise audit logs and retain them according to policy.
- Scan infrastructure as code and container images before deployment.
- Test backups and disaster recovery, not just configure them.
- Document data locations for GDPR, sector regulations and customer contracts.
Cost pitfalls to avoid
- Moving over-provisioned servers like for like
- Forgetting data transfer and egress charges between regions and out to the internet
- Leaving test environments running around the clock
- Unplanned licensing costs for databases and third-party software
- Long dual-running periods caused by slow cut-over decisions
- No ownership tags, so nobody knows who can switch things off
How long does a cloud migration take?
| Estate size | Typical approach | Indicative duration |
|---|---|---|
| Up to 10 applications | Mostly rehost and replatform | 2 – 4 months |
| 10 – 50 applications | Waves, mixed strategies | 6 – 12 months |
| 50+ applications or full data centre exit | Migration factory, phased modernisation | 12 – 24 months |
Automate testing and deployment as you migrate
A migration is the ideal moment to introduce CI/CD pipelines and automated testing, so future releases are faster and safer. Our quality assurance services and article on release pipelines and test automation explain how.
Plan your cloud migration with Groviya
Groviya’s cloud and DevOps engineers assess application estates, design secure landing zones and migrate workloads to AWS, Azure and Google Cloud in well-governed waves, with delivery from India and teams in the UK and USA. Offshore delivery can reduce migration cost significantly, as explained in our offshore buyer’s guide. Explore our services or request a migration assessment.
