Cloud migration testing strategy: phases, test types and a checklist
A cloud migration testing strategy defines what you test before, during and after each migration wave, and the pass/fail criteria that decide whether a workload goes live. It covers functionality, data integrity, performance, security and rollback. The method: measure a baseline on the old platform, run a test migration, compare, and only cut over when the numbers match.
Key takeaways
- Capture baselines before you move anything: response times, error rates, batch run times and row counts.
- Agree pass/fail criteria and rollback triggers before the first wave, not during the cutover.
- Use the migration tools' own test features: Azure Migrate test migrations and AWS DMS data validation exist for this purpose.
- Test types scale with the migration path. A lift-and-shift mainly needs parity checks; a refactor needs full functional and integration testing.
- Run test migrations in an isolated network. Microsoft warns against test migrations into a production virtual network.
- Keep testing after cutover: watch service level indicators (SLIs) for at least one full business cycle.
What is cloud migration testing?
Cloud migration testing is the set of checks that prove an application, its data and its infrastructure work at least as well after the move as before it. It runs across the whole migration, not just at the end.
It differs from ordinary release testing in three ways:
- The platform changes, not the code. In a lift-and-shift the code is the same, so you test the environment: networking, identity, storage performance, DNS and time zones.
- Data moves. You must prove that every row and file arrived, unchanged, and that ongoing changes kept syncing until cutover.
- The cloud behaves differently. Autoscaling, managed service limits, regional latency and shared infrastructure can change performance even when nothing else changed.
The success criteria stay the same as on-premises: functions must work, data must be complete and correct, and users must not notice a drop in speed.
The four phases of a migration testing strategy
Split testing into four phases, each with its own evidence and sign-off.
| Phase | Goal | Main checks | Evidence |
|---|---|---|---|
| 1. Plan and baseline | Know what "good" looks like today | Dependency map, critical user journeys, current response times, batch durations, data volumes | Baseline report, agreed pass/fail criteria |
| 2. Test migration | Prove the workload runs on the target | Boot and connectivity, functional smoke tests, integrations, data validation, performance under load | Test results per workload, defect list |
| 3. Cutover | Switch safely, with a way back | Final data sync and validation, DNS and certificate checks, smoke tests, go/no-go | Cutover runbook with timings, signed go/no-go |
| 4. Post-migration | Confirm stability and tune | SLI monitoring, user acceptance, backup and restore test, cost check | Hypercare report, closed defects |
Phase 1: plan and baseline
Start with an inventory of applications, databases, interfaces and scheduled jobs, then rank them by business risk. For each workload, record the numbers you will compare against later: p95 response time for key transactions, error rate, nightly batch duration, database size and row counts.
Turn those into criteria. For example: "order search p95 within 10% of baseline", "zero row mismatches in finance tables", "nightly batch finishes before 06:00". Google's SRE book defines an SLI as "a carefully defined quantitative measure of some aspect of the level of service" and an SLO as a target value for it (Google SRE book). Writing your criteria in that form makes the go/no-go decision objective.
Phase 2: test migration
Migrate a copy of the workload to the target and test it there while the source keeps running. Both major platforms support this:
- Azure Migrate offers a test migration that launches replicated VMs in a virtual network you choose. Microsoft's guidance says that test migrating into a production virtual network is not recommended, because open connections to on-premises can cause duplicate VMs or DNS changes.
- AWS Application Migration Service (MGN) launches test instances from continuously replicated servers, and replication continues after the test. AWS calls it a best practice to test at least two weeks before the planned cutover, so there is time to fix what you find.
Use this phase to find the surprises: hard-coded IP addresses, missing firewall rules, licence checks tied to hardware, and jobs that call servers you forgot to migrate.
Phase 3: cutover
Cutover is a rehearsed runbook, not an improvisation. Freeze changes, run the final data sync, validate the data, switch DNS or load balancer targets, and run smoke tests. Each step has an owner, a planned time and a rollback action.
Define rollback triggers in advance, for example: "if smoke tests fail or data validation shows mismatches 60 minutes after the switch, revert DNS to the source". Rehearse the rollback at least once during test migrations.
Phase 4: post-migration validation
After go-live, compare SLIs against the baseline for at least one full business cycle, including month-end or peak days if possible. Run user acceptance tests, test a restore from the new backups and check the first cloud bill against the estimate. Only then decommission the source.
Which test types should you run?
Match the test types to the risk of each workload. Not every application needs every test.
| Test type | What it proves | Typical tools |
|---|---|---|
| Functional and regression | Features and user journeys still work | Selenium, Playwright, existing test suites |
| Integration | APIs, message queues, file transfers and third-party services connect | Contract tests, API test tools, synthetic transactions |
| Data validation | Every row and file arrived and matches | AWS DMS data validation, checksums, row counts, database diff tools |
| Performance and load | Response times and throughput meet targets, autoscaling works | JMeter, k6, Gatling |
| Security and compliance | Access, encryption, network rules and logging are correct | Cloud security posture tools, vulnerability scans, IAM reviews |
| Resilience and DR | The workload survives failures and can be restored | Failover drills, backup restores, AWS Fault Injection Service |
| User acceptance | Business users confirm the system is fit for use | Scripted UAT with sign-off |
For realistic load tests that match your peak traffic, see our load testing service.
How do you validate data during a migration?
Validate data at three levels: counts, checksums and row-by-row comparison for critical tables.
- Counts: rows per table, files per bucket, total bytes. Fast and catches gross errors.
- Checksums and aggregates: sums of amounts, hashes of key columns. Catches truncation and encoding problems.
- Row-level comparison: for databases, AWS DMS data validation compares each source row with its target row and reports mismatches, including changes captured during ongoing replication.
Two practical limits from the AWS documentation are worth planning for: validation needs a primary key or unique index on each table, and it adds query load on both source and target. Schedule heavy validation runs outside business hours, or run them as separate validation-only tasks.
Also test what changes on purpose. If you convert from Oracle to PostgreSQL, data types, collation and sort order differ, so compare query results, not just stored values. Our database migration service covers these conversions.
How testing changes with the migration path
- Rehost (lift and shift): focus on environment parity. Check networking, DNS, identity, storage throughput, backup jobs and monitoring agents. Functional testing can be a smoke test plus the critical journeys.
- Replatform: when you move a database to a managed service or an app to containers, add data validation, performance tests and checks of managed service limits such as connection counts.
- Refactor: treat it as new software. Run full functional, integration and performance testing, and use canary or blue/green releases with feature flags to limit exposure.
Cloud migration testing checklist
- Inventory and dependency map complete for the wave
- Baselines recorded for critical journeys, batch jobs and data volumes
- Pass/fail criteria and rollback triggers signed off by the business owner
- Test environment isolated from production networks
- Infrastructure defined as code so test and production match (see our Terraform infrastructure-as-code service)
- Test data masked where it contains personal data
- Test migration done, defects fixed and retested
- Data validation passed for all tables in scope
- Load test at expected peak passed
- Security review done: IAM, encryption, security groups, logging
- Rollback rehearsed and timed
- Cutover runbook with owners and timings approved
- Post-migration monitoring dashboards and alerts live
- Backup restore tested on the new platform
How Opsio helps
Opsio plans and runs cloud migrations with testing built into each wave. For SilverRail Technologies, Opsio moved the company's Nordic branch onto AWS and merged it with the global organisation. The Mobilize phase included a pilot test migration of selected workloads, and the migration process and AWS services were adjusted based on that testing. Data moved with native PostgreSQL tools under a detailed cutover plan, and cutovers ran in tight service windows to limit customer impact. Read the SilverRail case study.
Frequently asked questions
What is a cloud migration testing strategy?
It is a plan that defines which tests run before, during and after each migration wave, the pass/fail criteria for each, and who signs off. It covers function, data, performance, security and rollback.
What are the phases of cloud migration testing?
Plan and baseline, test migration, cutover, and post-migration validation. Each phase produces evidence, such as baseline reports, test results, a signed go/no-go and a hypercare report.
How do you test data after a cloud migration?
Compare row counts and checksums for all tables, and run row-level comparisons for critical data. On AWS, DMS data validation compares source and target rows and reports mismatches; it needs a primary key or unique index on each table.
How is testing a lift-and-shift different from a refactor?
A lift-and-shift mainly needs parity checks of the environment and critical journeys, because the code does not change. A refactor needs full functional, integration and performance testing, as you are effectively releasing new software.
How long should you monitor after cutover?
At least one full business cycle, including peak days such as month-end, before you decommission the source systems. Keep the rollback option open until the agreed criteria hold.
Related Articles
About the Author
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
