Before you start
- ✓The old system running, with realistic test scenarios
- ✓The full list of forms, reports and automated emails from the extraction
- ✓Someone who uses the old system every day
- ✓Somewhere to record every difference and how it was resolved
Make the old system the specification
The old system got the business this far, so its behaviour is the benchmark. Extracting the database lists every form, report and automated email, so nothing depends on memory.
Put the same orders through both
On a recent Access replacement we entered real scenarios for the four main sales order types in both systems and compared every total, matching the main order form field for field: around 35 fields and 15 drop-down lists.
Match what it does, not what it stores
A column in the old database doesn't mean anything uses it. We check the code first. Where they disagree we match what customers actually get, or deliberately fix it and write that down.
Check assumptions against the data
Defaults on old forms drift from reality. Numbering ranges and similar rules get checked against real records first.
Keep reports and emails familiar
Staff trust paperwork they recognise. We rebuilt the hire reports and sales order PDFs to match the Access layouts, kept the order form to one A4 page with a check that fails if it spills over, and compared every automated email, closing six gaps.
Check again before switching
The old system keeps changing while you build, so we extract it again before cutover, as part of running both side by side.
What usually goes wrong
From our own projects, not the manual.
A stored price nobody's code used
The new system added a surcharge from a column in the old database, putting one package £120 higher than the old system charged. None of the old code ever read that column, so customers had never paid it. Match what customers actually get, and keep the charge switchable.
A hidden field and an over-eager check broke two order types
On one order type the surcharge field was hidden, under-pricing larger jackets; on another a safety check switched the whole price calculation off. Putting all four order types through both systems side by side found both.
Package credits came from the wrong place
Starting values for package credits didn't come from the old order form, so one accessory was credited at seven times its price. Take values from the forms staff actually use, then match to the penny.
The form's defaults didn't match the data
Numbering ranges taken from an old form's defaults rejected valid stock, because one branch used a different range in practice. Check assumptions against the data before enforcing them.
The printout spilled onto a second page
A new header, footer and wider margins pushed the main order form over one A4 page, where the old report had always fitted. Tighten the layout and add a check that fails if it grows.
Do it yourself, or get help?
If the old system is small and well understood, a structured side-by-side test day with the people who use it will find most differences. If prices, stock or money depend on rules buried in old forms and code, get help: the differences that matter are the ones nobody knows are there until a customer is charged the wrong amount.
Get a developer on it