How Do I Move to the New System Without Stopping Work?

You move without stopping work by not switching off the old system until the new one has proved itself: run both on the same real transactions and compare their outputs, test the rare cases your process owners name, require a human sign-off on every module before it goes live, and keep the old system ready to fall back to. In its migration execution guide, Microsoft recommends monitoring the new system for the first 24 to 48 hours after cutover and keeping the source environment available as a fallback during stabilization.

In part 5 you chose a path for each system. This part does not repeat the general cutover method we covered in Legacy System Modernization Without Downtime. It focuses on what is new: what to test when AI wrote or converted the new code.

Why AI-converted code needs different testing

Code produced by conversion tools looks tidy and runs on the first try, which is exactly what makes its mistakes hard to see. The error does not show up in everyday cases; it shows up in the case that happens once a month or once a year. Amazon explains in its mainframe transformation guide that the initial COBOL-to-Java conversion preserves the same behavior, and then a step called Reforge uses large language models to restructure the code in modern Java style. COBOL is an old programming language that still runs many banking and mainframe systems; a mainframe is the large central server that core systems run on in big organizations.

Every step that rewrites code can change something small. So it is not enough for a developer to read the new code and say it looks right. Management has one question: does the new system give the same result as the old one on the same data? The answer comes from comparing outputs, not from reading code.

Compare outputs on the same real transactions

Take a closed period of your business, such as a month whose books are already closed, run its transactions through the new system, and compare what comes out with what the old one produced. What to compare:

• Final figures: invoice totals, balances, and stock at the end of the period.
• Reports: the monthly reports management relies on, line by line.
• What goes to other systems: the files and messages sent to the bank, accounting, or government portals.
• Rejections and errors: a transaction the old system rejects must be rejected by the new one, for the same reason.

Some tools help prepare, not judge. AWS Transform for mainframe, for example, builds a test plan from code attributes, job complexity, and scheduler paths in 3 phases (configuration, scoping, and review), then generates scripts to collect test data from the mainframe in 4 phases. But Amazon notes in the same guide that these scripts must be executed on your own mainframe, with your team's permissions. The tool prepares; your team runs and decides. To check the data itself, Microsoft suggests comparing row counts as a quick check, then checksums as a deeper one: a checksum is a number calculated from the data that changes if a single character changes.

The rare cases: ask the people who know them

One month of real transactions does not contain everything. The cases that break systems are known to process owners, not developers: year-end closing, a partial return on an old invoice, a customer with special pricing, an invoice cancelled after posting, the salary of someone who joined mid-month. Ask each process owner to list the cases they worry about, then turn each one into a test with an expected result written down before the run.

This is where the rules you confirmed in part 4 come back: every confirmed rule becomes at least one test case. A rule with no test is a rule you cannot say survived the conversion. For the types of testing themselves, see our software testing and QA guide.

A human sign-off on every module

The clearest published example of this principle is the banking migration pipeline Thought Machine announced with Amazon on 29 September 2026. It runs in 4 stages: extracting business logic from legacy applications with AWS Transform, consolidating redundant variations into unified specifications, generating the new financial products and their test suites with AI agents, and a validation stage that gives the bank's engineering and risk teams explicit sign-off authority before anything is accepted. Even after sign-off, the output goes to an isolated sandbox for further evaluation, not straight into production.

The lesson for your company needs neither a bank nor Amazon: every module of the system, such as billing, payroll or inventory, gets two signatures before it goes live. One technical, confirming every test was run, and one from the process owner, confirming the results are right in business terms. Microsoft asks for the same after cutover: application owners confirm that all major functions work correctly.

Parallel running and the rollback plan

Parallel running means both systems work side by side for a defined period, with the old one still the official reference. Decide before you start when that period ends and what condition allows it to end, such as results matching over one full business cycle. Then organize cutover like this:

A rollback plan is not an admission of failure; it is insurance. Write down in advance what would make you go back, such as an error in invoices or a core process stopping, who owns that decision, and how users return to the old system. Do not switch the old system off for good until the stabilization period is over. What usually breaks in the first weeks after a switch is covered in The First Thirty Days After Migration.

The Origami view

We treat cutover as a management decision, not a technical event. So we build the comparison between the two systems before we build the new system itself, and we agree with process owners on the rare cases and their expected results early, so the definition of success is written down before anyone sees the results.

We use AI to speed up conversion and to generate tests, but the sign-off on each module stays with named people on your team. To see how we work, take a look at our services.

This week's exercise: a cutover sheet for each module

For each system you chose to convert or rebuild in part 5, fill in this sheet with your process owners before setting any cutover date:

These are illustrative examples; your sheet will differ. What matters is that no cutover date is set until every module has two named signatories and a written rollback trigger.

What is next

One question remains that every manager asks before sending code and data to an AI tool: where does my data go during modernization? Part 7, the final part, answers it and gathers the exercises of the whole series into a 90-day plan.

Sources

• Microsoft: Execute migration, Cloud Adoption Framework — rollback criteria meeting, change freeze, data validation, 24 to 48 hours of monitoring, keeping the source environment as fallback.
• Amazon: Transformation of mainframe applications in AWS Transform — test plans, test data collection scripts and the Reforge step.
• Amazon: Thought Machine and AWS announcement on legacy banking migrations — the four stages and sign-off by engineering and risk teams.
• AWS Transform: official page.