QA After a Migration or Replatform: What to Re-Test, as a Service

Post-migration QA is a one-off, fixed-scope regression test run after a replatform, database migration or infrastructure move. Testers compare behaviour against what the system did before, with attention on data integrity, the journeys the migration touched and every integration that now points somewhere new. You get a ranked bug report with severity, reproduction steps and a suggested fix for each issue.

This is the service, not the recovery guide. If a migration has already broken production, start with a database migration broke production; this post is about hiring the re-test that stops that happening.

Why does a migration need its own QA pass?

Because a migration changes the ground the whole app stands on without changing a single feature on screen. The code can look identical and still behave differently: a column that used to be non-null now allows nulls, a timezone default shifts, a foreign key is dropped, a rounding rule changes, an integration URL points at a new host. None of that shows up in a demo. It shows up weeks later as wrong totals, missing records or a report that no longer reconciles.

A feature test asks "does this work?". A post-migration test asks "does this still work the same way it did, with the same data, giving the same answers?". That is a different question, and it needs a before-and-after frame.

What should you re-test after a migration?

A fixed scope, agreed before it starts, weighted towards data and the seams the migration crossed.

Area	What gets tested	The failure it catches
Data integrity	Row counts, totals, relationships and sampled records, before vs after	Rows dropped, duplicated, truncated or re-typed in the move
Money and ledgers	Balances, invoices and reports that should reconcile across the migration	Rounding, currency or precision changes that quietly shift totals
Core journeys	Sign-up, the main workflow and anything that reads migrated data	Features that read a column or shape that changed underneath them
Integrations	Payments, email, webhooks and any third party now on a new host or key	Calls pointing at the old environment, or silently failing
Auth and access	Roles, sessions and tenant isolation after any schema or identity change	A permission or isolation regression introduced by the new structure
Performance	The queries and pages that depended on the old indexes or host	Pages that were fast before and crawl on the new database

Where the audit includes a security or accessibility smoke test, those follow OWASP guidance and WCAG 2.2 respectively; neither is a certified penetration test or a legal compliance certificate.

How do you compare before and after safely?

With a baseline taken before the cutover and checks run against both. The practical approach is to capture counts and key totals from the old system, keep a copy of the old environment reachable during the test window, and run the same journeys and queries on both. Where possible, the comparison is automated so it can run again on the next migration. Industry data shows why the effort is worth it: in Standish Group CHAOS research, the large majority of software projects are late, over budget or short on features, and a botched data migration is a classic way to join them (Standish Group CHAOS report). A before-and-after QA pass is cheap next to a silent data loss discovered a month in.

Buy, build or hire?

A post-migration QA pass is one of four routes to a trustworthy cutover.

Route	What it costs on the market	Choose this when	Watch out for
A tool or testing platform	Cloud browser and device testing from around $29 to $39 a month for one user (BrowserStack pricing)	Your developers already wrote migration checks and need somewhere to run them	A tool does not design the before/after comparison for you
Freelancers or crowdtesting	Upwork lists a median of $35 an hour for QA engineers (Upwork QA engineer rates)	A short, well-scoped re-test of a simple migration	Data-integrity testing needs someone who understands the schema
An in-house QA hire	The US median wage for QA analysts and testers was $104,300 in May 2025 (US Bureau of Labor Statistics)	Migrations are frequent and part of the standing roadmap	A migration is often a one-off spike, not a steady workload
A managed post-migration audit	Fixed price, quoted per migration scope after a free call	A specific replatform or data move is done and you need to trust it	Make sure the baseline is captured before cutover, not after

When don't you need a post-migration audit?

• When the migration was tiny and your automated suite already runs on the new environment and passes.
• When you are mid-incident with a broken migration. Recover first with a code rescue, then re-test.
• When you need a certified penetration test or a legal accessibility certificate. Those are separate, accredited engagements.
• When you want a tester embedded under your management. RAITHub does not offer staff augmentation.

How RAITHub would do this

RAITHub runs post-migration QA under its QA as a Service offering, as a fixed-price one-off audit.

• Scope: a free 15-minute call to learn what moved, what the old and new environments are, and which data and journeys matter most, then a fixed written quote.
• Baseline: capture counts, key totals and sampled records from the pre-migration state, ideally before cutover.
• Re-test: run the core journeys and queries on the new environment, compare against the baseline, and exercise every integration that changed host or key.
• Report: a ranked bug report in your tracker with severity, reproduction steps, evidence and a suggested fix, flagging data-integrity issues first.
• Fix, your choice: fix from the report with your own team, or have RAITHub engineers fix the issues under a separate fixed quote, then re-test.

RAITHub's data discipline is counted in its own platforms: Sundor Skin runs 530+ tests across 146 PostgreSQL tables with CI that replays every migration, PropDesk runs 1,024 tests, and this website 400+ in CI. There is no standalone post-migration case study yet, so judge the service on the free call and a written scope. You receive: the baseline, the comparison, the bug report, any automated checks in your repository, full IP and an NDA. Next step: a free 15-minute audit, then a written fixed quote; RAITHub publishes no rates.

To book one, tell RAITHub what you migrated and when. Running the cutover again, or another big release, soon? A release-gate audit covers that moment.

Frequently asked questions

What is post-migration QA?

A one-off, fixed-scope regression test run after a replatform, database migration or infrastructure move. It compares behaviour against the pre-migration baseline, with attention on data integrity, the touched journeys and every integration that now points somewhere new.

Why can't our existing tests cover a migration?

They can, if they already run on the new environment and check data integrity, not just features. Most suites test "does it work", not "does it give the same answers with the same data as before", which is the question a migration raises. The audit adds the before-and-after comparison.

What is the single biggest risk after a migration?

Silent data problems: rows dropped, duplicated or re-typed, or totals that shift by a rounding or currency change. They pass a demo and surface weeks later as wrong numbers. That is why the audit starts from a baseline taken before cutover.

How much does a post-migration QA audit cost?

RAITHub publishes no rates. It is a fixed price, quoted after a free 15-minute call once the scope is clear: what moved, which data and journeys matter, and which integrations changed. Marketplace QA engineers typically charge $20 to $60 an hour as a reference.

Do we need to keep the old system running during the test?

Where possible, yes, or at least a snapshot of it, so the before-and-after comparison is exact. If the old environment is already gone, the audit works from whatever baseline figures and exports you captured before cutover.

Can you test the migration before we run it in production?

Yes, and that is the safer order: run the migration against a copy, re-test there, fix what fails, then cut over for real. The engagement can be scoped as a dry-run audit rather than a post-cutover one.