How to test an application after a cloud migration

Why this matters

Moving an application to a new cloud changes more than the server it runs on. It changes the network path, the identity model, storage permissions, DNS answers and the way logs and metrics arrive. A login page that loads proves very little. The failures that hurt show up later as timeouts, missing files, jobs that never run and permission errors that only one user role can trigger.

How to test an application after a cloud migration comes down to proving the same behavior under new conditions. You compare what users and downstream systems see now with what they saw before. You also prove you can recover when something breaks. A test pass is not a feeling. It is a set of recorded results you can show to the product owner and the person on call.

That work pays off in the first week of real traffic. A missed queue setting can stall orders. A wrong time zone can run a batch job twice. A TLS certificate that was not copied can break a partner integration. Testing catches those issues while the old environment is still warm and rollback is still open.

Before you start

Start with a baseline from the old environment. Export response times for your main flows, error rates by endpoint, batch job durations, queue depth and sample outputs. If you did not capture it before the move, pull it from logs that still exist. Without a baseline you can only ask whether the app works, not whether it works as well.

Write acceptance criteria per flow, not per server. A user should sign in with each role, upload a large file, search for a record, export a report and receive a confirmation email. Each criterion needs a test account, test data and an expected result. Cover unicode names, empty fields, duplicate requests and dates near a month boundary.

Freeze nonessential changes during the test window. Stop deploys, schema changes and DNS edits unless they are part of the migration. Name a rollback owner and a window when you can switch traffic back. Make sure test accounts exist in the new identity provider and secrets resolve from the new store. Check that you can reach the test environment from the networks your users and partners use.

How to do it

Run tests in layers. Start with a smoke test that proves the app starts, reaches its database and serves one page. Then test each flow end to end, including email, file storage and any external payment or messaging provider. Only after those pass should you run performance tests, security checks and failure drills. A failure early saves hours later.

Keep a log with time, user role, input, expected result and actual result. Capture the request ID or trace ID for every failure. Compare timings with your baseline and note any new error class in the logs. Use a canary first: send a small slice of real traffic to the new environment and watch error rate, latency and queue depth before you move the rest. Keep the old environment running until the canary is clean.

1. List critical flows. Write down the five to ten flows that would stop the business if they failed, such as sign in, checkout, file upload and report export. Give each one an owner and a pass condition.
2. Capture a baseline. Pull response times, error rates, job durations and sample outputs from the old environment. Store them next to the test plan so reviewers compare numbers, not memories.
3. Prepare test accounts and data. Create accounts for each role, plus a test tenant and seed records. Cover empty fields, large files, unicode text and dates at month end.
4. Run a smoke test. Check that the app starts, resolves DNS, connects to the database, reads a secret and serves one page. Fix basic connectivity before testing features.
5. Test integrations and async jobs. Send a test message to every queue, run each cron job manually and confirm emails, files and webhooks arrive. Check dead letter queues and retry settings.
6. Run load and failure tests. Replay a typical load against the new environment and compare it with the baseline. Kill a node, block a subnet or revoke a permission to see how the app and alerts behave.
7. Check access and security. Test each role against the new IAM policies, security groups, bucket policies and secret permissions. Confirm that a low privilege user cannot reach admin data.
8. Run acceptance and rollback drills. Have real users complete the main flows in a test tenant. Then switch a small slice back to the old environment to prove DNS, certificates and data sync still work.

How to check it worked

Evidence should line up in the test log, the dashboards and the logs. Every critical flow needs a pass with a timestamp and a named tester. Dashboards should show latency, error rate and saturation near the range you saw before the move. Logs should show no new exception types and no repeated permission errors.

Check the quiet parts. Queues should drain to zero after a test burst. Scheduled jobs should run once, at the right time in the right time zone. Backups should finish, and a restore into a scratch database should return the same row counts and key records. Certificate expiry, DNS TTL and health check paths should match the plan. With autoscaling, confirm that a new instance joins the pool and gets traffic.

Force a test error and confirm the alert reaches the on call person with the right service name and runbook link. Move one small service back to the old environment to prove rollback still works. Then watch the new environment for a full business cycle, including month end or payroll, before you retire the old one. Sign off with what passed, what failed, what was fixed and what remains open.

Mistakes to avoid

Testing only the happy path is the most common gap. A user who can log in may still fail when they export a large report or call a partner API. Test negative cases: wrong password, expired token, missing file, full queue and duplicate submission. Those paths often depend on network and identity settings that changed.

Do not reuse production data without masking it. Test copies spread across buckets and databases, and they can leak into logs. Build a small synthetic set that covers edge cases. Keep it under version control so the next run uses the same inputs.

Ignore async work at your peril. Cron jobs, queue consumers, webhooks and scheduled reports are easy to forget because no user clicks a button. Run each one manually and check the output. Watch for duplicate runs caused by time zone changes or overlapping schedules.

Do not call the migration done when the canary passes. Remove old DNS records only after the rollback window closes. Keep the old environment read only for a while and keep its backups. If you want help shaping the test plan, Cloudverg's Discovery and roadmap sprint is a two-week fixed price engagement at $9,500 that ends with an architecture, a phased roadmap and a fixed quote for phase one. It is one option among others; your test log is still the proof.

Frequently asked questions