Testing After Major Change

Testing after a major change checks that a changed system still supports its critical functions, and that the change has not introduced a weakness that only appears in live use. Major changes are a known source of incidents, not because change is careless, but because change alters the system that previous testing examined. A core banking migration, a move to a new cloud platform, or a replacement of a payment supplier each create new paths, new data mappings, and new failure modes. Testing should therefore surround the change: before it, to establish a baseline; during cutover, to confirm the new system behaves as expected; and after it, to catch problems that only emerge once real customers and real volumes return.

A change is major when it could affect a critical function, its data, its suppliers, or its recovery. Replacing a core system plainly qualifies, but so does a smaller change with wide reach, such as a change to authentication for all customers, or a change to the data model behind settlement. The judgement should be based on blast radius, not on project size. A technically small change deployed to every customer at once can be more consequential than a large project confined to a single internal tool. The change record should state why the change was judged major, which functions it touched, and what testing that judgement triggered.

Before the change, testing should confirm that the new system handles the service's real journeys, including exceptions, and that data migrates correctly. A migration example makes this concrete. Account records, transaction histories, and standing instructions must arrive in the new system intact and in the right form, not merely in the right count. Tests should compare old and new outputs for the same inputs, check edge cases such as dormant accounts or disputed transactions, and rehearse the rollback: if the change must be reversed, can it be reversed, by whom, and with what effect on data created in the meantime. A change without a rehearsed rollback is a change without a safety net.

At cutover, testing becomes a series of checks that the live service is behaving as the tested service did: customers can log in, transactions flow, suppliers respond, and reconciliations balance. Afterwards, the testing does not stop. Post-change monitoring watches for the slow failures that cutover checks miss: a report that runs but produces subtly wrong figures, a batch job that completes late, or a supplier interface that degrades under real volumes. That period is also when staff are least familiar with the new system, so incident procedures and contact routes should be checked again, not assumed to carry over unchanged from the old system.

The familiar pitfall takes a specific form after a change. Testing is done in an environment that reflects the old production system, or a clean version of the new one, while live production carries years of accumulated data quirks, manual workarounds, and supplier variations. The test passes, the change goes live, and the first real customer journey encounters a case the test data never contained. Mitigation is unglamorous: use production-like data, include the awkward cases, involve the operations staff who know where the quirks live, and treat a discrepancy between test and production as a finding, not as an inconvenience to be explained away.

Change testing closes when the changed service has been shown, in live use, to support its critical functions, when open findings have owners and retests, and when the rollback decision has been formally retired rather than left ambiguous. Until that point, the change remains an open risk, however successful cutover appeared. The record should link the change, the tests, the findings, and the post-change observations together, so that a later reviewer can see not only that testing happened, but that it examined the change that actually went live. That linkage is what separates change testing from a generic test report filed alongside a project plan.