Migration ·
Moving a Legacy Windows Module to the Web in Four Weeks
In four weeks, we moved one module of a legacy Windows application to the web. The new code implements 717 business rules, and the full test suite contains 6,500 tests. To understand the module and the code it uses, agents analyzed 1.02 million lines of existing code.
We checked the new application by running the same actions in the old one and comparing the results. We agreed on the changes we wanted in advance. Everything else had to work as it did before.
Let agents use the Windows app
The old application ran in a VM. Through MCPs, we gave agents tools to click buttons, enter data and take screenshots.
They could use the application themselves to find out how it behaved. We compared different ways to control Windows and wrote reusable instructions for the agents. These instructions helped them choose the faster methods.
Run the same test in both versions
This is the idea behind golden master testing: use the old application’s results to check the new one.
For each test, both versions must start with the same data. We run the same sequence of actions, then compare screenshots and check the data saved in the database. If even one field differs, the test fails.
When the old app rejects a transaction, the new app must reject it too. Neither should change the database. Showing the same error message is only part of the check.
Write code together and take turns testing
Up to 10 coding agents worked at once. Each used a separate Git worktree, giving it its own working copy of the code. This kept their file edits apart.
They all shared one Windows VM and one Oracle database. If one agent changed a screen or the test data while another was using it, it could spoil the test.
The agents built their own system for taking turns. An agent could reserve the VM or database while it worked. Other agents had to wait before using it. That let them write code at the same time and take turns using the shared tools.
A custom scheduler also worked through a list of tasks, allowing agents to keep working overnight and on weekends.
When the agents had questions, they provided screenshots and context. We decided how to proceed. Answering those questions took more of our time than any other part of the project.