Visual FoxPro Migration & Support
so the business is not one person deep.
Visual FoxPro has been out of support since January 2015 and there was never a version after 9. The applications did not stop working, which is exactly why so many are still running the business.
You get the same screens on supported software, the data in a real database, and the reports reconciled against the originals. We do this for businesses in Australia, New Zealand, the UK and the US, at a fixed price.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
It still works, which is why nobody has replaced it
Visual FoxPro applications tend to be quietly excellent. They were written by somebody who understood the business, they are fast, and they have run for twenty years without much attention. Nothing forces a decision until the person who wrote it leaves, or a new Windows build breaks something, or an auditor asks where the data lives.
We are usually called after a business has been told by two or three firms that nobody works on FoxPro any more. We do. The work is not glamorous and it is not mysterious either.
What the work actually is
The screens your staff know, on supported software
We read the .prg files, the forms and the report definitions, work out what the application actually does, and rebuild it on a current stack. The data moves out of .dbf files into a real database.
What you have now
- .dbf tables and .cdx indexes
- Forms and reports (.scx, .frx)
- Business logic in .prg files
- Reports nobody can reproduce
A supported application, with the same behaviour
We read the .prg files, the forms and the report definitions, work out what the application actually does, and rebuild it on a current stack. The data moves out of .dbf files into a real database.
Get a fixed-price scopeWhat you end up with
- A web or desktop application your staff recognise, without the retraining
- Data in SQL Server or PostgreSQL, backed up and queryable by normal tools
- The reports rebuilt and reconciled row by row against the originals
Only the Visual FoxPro work you actually need
Most engagements are some combination of these, and most start with the first.
Read and document the existing system
Forms, reports, .prg logic and the table structure written down properly, often for the first time since it was built.
Move the data off .dbf
Tables and indexes migrated into SQL Server or PostgreSQL, with row counts and totals reconciled against the original.
Rebuild the application
A web application your team can use from anywhere, or a desktop replacement if that suits the work better.
Reproduce the reports
The .frx reports rebuilt so the numbers match. This is usually the part other firms underestimate.
Keep it running in the meantime
If a full rebuild is not this year, we can support the existing application and stop it becoming an emergency.
Where you are now
It works, and nobody will touch it
- Out of support since January 2015, with no security patches
- One person understands it, and they may have already left
- Data sits in .dbf files that nothing modern reads properly
- It runs on a Windows version you are not supposed to still have
After
Supported, documented and yours
- A supported application on a stack any developer can pick up
- Data in a real database, backed up and reportable
- Documentation, so the next person is not starting from nothing
- Access from a browser rather than one machine under a desk
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeWhat people ask us about Visual FoxPro
Does anyone still work on Visual FoxPro?
Fewer every year, which is the honest reason this page exists. We read FoxPro, including the .prg logic and the .frx report definitions. We are not going to pretend it is a common skill in 2026, but it is not a lost one either.
Do we have to rebuild everything at once?
No, and usually you should not. A common path is to move the data to SQL Server first while the FoxPro front end keeps running against it, then replace the screens in stages. The business keeps working throughout.
What happens to our reports?
They get rebuilt and then reconciled against the originals until the numbers match. We treat that as part of the migration, not an extra. Reporting is the most common reason a migration gets rejected by the people who have to use it.
Can you just keep it running instead?
Yes. If a rebuild is not this year, supporting the existing application is a legitimate choice and we will say so. It buys time, it does not remove the problem.
Who owns the result?
You do. Source code, documentation and credentials are handed over in your name at the end. We are not interested in being the only firm that can maintain your system, which is how you got here.
Sending your details…
You can stay on this page while we send it.
Tell us what your Visual FoxPro system does
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
