When teams scope a FoxPro migration, they count the forms and size up the data. Then they wave a hand at the reports, as if those are a formatting detail to sort out at the end. Reports are where migrations quietly go over budget, because a report is not a layout. It is business logic in disguise, and the numbers on it have to tie out to the penny.
Here is why the reports deserve real respect, and how to move them without losing anyone's trust in the totals.
A report is not a picture, it is a program
A FoxPro .frx report looks like a layout, but underneath it is doing work: filtering and grouping data, running calculated fields and expressions, computing running totals and subtotals, and applying conditional formatting. Years of business rules accumulate in these expressions, often nowhere else. The report is frequently the only place a particular calculation is written down. Rebuild the layout and miss one expression, and the page looks right while the number is wrong, which is the most dangerous kind of error.
Why reports are underestimated
- There are more of them than anyone remembers. Mature FoxPro apps routinely carry dozens or hundreds of reports, many rarely run but critical when they are.
- The logic is buried in expressions. Grouping, totals, and print-when conditions hold real rules that must be carried over exactly.
- "Close" is not good enough. A form that is slightly off is a nuisance. A financial report that is slightly off is a crisis of trust.
- Output formats multiply the work. The same report may need to become an on-screen view, a pixel-faithful PDF, and a data export.
The rule we hold to: a migrated report is not done when it looks like the original. It is done when it produces the same numbers as the original, proven against real data.
How to move reports so the totals hold
The safe path treats reports as first-class, not an afterthought:
- Inventory every report first, so none are discovered late. The count almost always surprises people, which is exactly why our cost-and-timeline guide lists reporting as a top driver.
- Extract the logic, not just the layout. Capture the filters, groups, totals, and expressions as real rules, so nothing lives only in a design file.
- Rebuild on a modern reporting engine that produces clean on-screen views, PDFs, and exports from one definition.
- Validate in parallel. Run the old report and the new one against the same data and compare, to the penny, before anyone relies on the new one.
Parallel-run validation is the whole game
This is the step that separates a trustworthy migration from a hopeful one. For a period of time the legacy system and the new one run side by side on identical data, and the reports are compared line by line and total by total. When they match consistently, the business gains real confidence, not a promise. That evidence is worth far more than any assurance, and it is how a reporting migration earns sign-off.
Bottom line: reports carry business logic that often exists nowhere else, so they cannot be treated as decoration. Inventory them, extract the real logic, rebuild on a modern engine, and prove the numbers match with a parallel run. That is how you migrate FoxPro reports without losing a single number.
Worried your reports are hiding logic no one has looked at in years? A free assessment inventories them and flags the risky ones, with no obligation.