- David Knoup
Is FoxPro migration without source code possible? Yes. Aviation services firm BP Aero did. Ticomix reverse-engineered BP Aero’s FoxPro app to recover its business rules, then rebuilt it as a .NET web app in C# with SQL Server on Microsoft Azure. BP Aero’s own time study showed teardown data entry time was cut by 50%.
If you run a Visual FoxPro application, it probably holds rules nobody has written down anywhere else, including how a job moves from one step to the next, which fields must be filled before a record can close, and what happens when two numbers don’t match.
That was BP Aero’s situation. With customers including Pratt & Whitney, GE Aviation, and CFM, it ran its engine teardown work on a decade-old custom Visual FoxPro app. The app still ran, but nobody could change it.
Here’s how Ticomix moved BP Aero to a modern system, and why the most important step came before anyone wrote new code.
BP Aero project at a glance
| Item | Details |
|---|---|
| Client | BP Aero, an ITP Aero company (aviation services, engine teardown) |
| Starting Point | Decade-old custom Visual FoxPro app, no source code, developer unreachable for three years |
| Approach | Reverse-engineered the app first, then rebuilt it in two phases (the FoxPro conversion, then new features) before a single go-live |
| Scope | 26 core forms, five reports, and a 13,000-line spreadsheet replaced |
| Result | Teardown data entry time cut by 50% (BP Aero's head-to-head time study) |
What happens when nobody can change your FoxPro app?
BP Aero’s original developer had been unreachable for three years. The source code was gone, and the team couldn’t make even basic updates. New part numbers, engine models, and customers couldn’t be added, so people worked around the system instead of through it. The app also shut down unexpectedly and struggled to keep up as teardown volume grew.
That left the business in a tough spot. The app still ran daily work, but no one could fix it, extend it, or fully explain what it did. The rules that shaped teardown work were locked inside a program nobody could open.
This is more common than most owners think. FoxPro apps often outlive the people who built them. Over time, the app becomes the only complete record of how part of the business really runs.
How do you migrate FoxPro without the source code?
The tempting move is to start fresh by looking at the screens, guessing at the logic, and building something new. However, that’s how rules get lost. A field that looks optional turns out to drive a report, or a calculation that seems simple has an exception nobody remembers adding.
That’s why Ticomix reverse-engineered BP Aero’s app first. Before rebuilding anything, we recovered how the existing system worked and what rules it enforced.
Reverse-engineering a FoxPro app means studying the running application, its screens, data, and outputs, to work out the rules it follows. When the source code is gone, it’s the only way to know what the system really does.
This step is what made the move safe. You can only trust a new system if it does what the old one did, and you can’t check that without knowing what the old one did.
What replaced BP Aero’s FoxPro app?
With the rules recovered, Ticomix rebuilt the system as a .NET web app on Microsoft Azure, written in C# with a SQL Server database. Technicians use it on tablets, phones, and rugged scanners across the facility.
The rebuild covered 26 core forms and five reports. It also replaced a 13,000-line spreadsheet, so that work now lives in the same system as everything else.
The new system also closed gaps the old one couldn’t:
- Reference data is fully editable, so BP Aero’s team can add part numbers, engine models, and customers without a developer.
- Partner organizations get secure, read-only access to parts data in real time, which ended the routine of emailing Excel files back and forth.
- Part photos appear during scans to help confirm the right part.
- Barcode scanning runs on current rugged Android devices.
Most important, BP Aero now has full control of its application, no longer depending on one developer.
Learn more about our Visual FoxPro migration services.
When does a phased migration make sense?
A phased migration, where one module moves at a time while the rest of the old system keeps running, is often the right call for a large system. Each part can be checked against real work before the next one moves, so no single switchover carries all the risk.
It isn’t the right fit for every project. For a smaller system, the extra coordination of running old and new side by side may not pay off, and moving everything at once is often simpler.
BP Aero’s project worked that way. Ticomix did the work in two phases, first the FoxPro conversion and then the new features, and BP Aero went live once both were finished.
Either way, a migration isn’t a quick swap. What makes it safe isn’t the number of phases. It’s knowing exactly what the old system did and testing the new one against it before anyone relies on it.
What changed for BP Aero after the migration?
After the move, BP Aero ran its own head-to-head time study, showing teardown data entry time was cut by 50%.
Parts now move through teardown and out the door more quickly. Every technician uses the system on mobile devices, so they can work anywhere in the facility. Internal teams and partners see parts data in real time.
It’s a real gain, but speed isn’t the main lesson here. The time savings were possible because the move was done safely. Without the rules recovered first, a new system could have been fast and wrong. Faster data entry only matters if the data going in follows the rules the business depends on.
Read the full BP Aero case study for screenshots and more detail.
Is your FoxPro system at the same risk?
If you’re still running Visual FoxPro, a few questions are worth asking now:
- Who understands how the app really works, and is any of it written down?
- Do you still have the source code, and does it match what's running today?
- If the app needed a change next month, who would make it?
If those answers make you uneasy, you’re not alone. BP Aero started with no developer and no source code, and that still didn’t stop a safe move.
The key is the order of the work. Recover the rules first, then rebuild and test the new system against the old one’s documented behavior before it goes live, which is the idea behind Ticomix’s REV methodology.
FAQs About FoxPro Migration Without Source Code
Can you migrate a Visual FoxPro app without the source code?
Yes. When the source code is gone, the existing app can be reverse-engineered to recover its business rules before anything is rebuilt. Ticomix did this for BP Aero, whose developer had been unreachable for three years, then rebuilt the app on .NET, C#, and SQL Server.
Why recover the business rules before rewriting a FoxPro app?
A FoxPro app is often the only complete record of how part of a business runs, and rules nobody wrote down live in its code. Recovering them first means the new system does what the old one did. Problems surface before the rebuild, not halfway through it.
What do FoxPro apps usually move to?
Ticomix typically rebuilds Visual FoxPro apps as browser-based .NET applications written in C# with a SQL Server database. BP Aero's new system runs on Microsoft Azure and works on tablets, phones, and rugged scanners. Read our FoxPro to .NET migration guide for more detail.
Do you have to replace the whole FoxPro system at once?
Not always. Large systems are often moved in phases, one module at a time, so each part can be checked against real work before the next one moves. Smaller systems are often simpler to switch over in one step. BP Aero went live all at once, after both the FoxPro conversion and the new features were finished.
About the Author
David Knoup
David Knoup is President and a Principal at Ticomix, a U.S.-based custom software and legacy application modernization company founded in 2001. Ticomix has completed 737 projects in 25 years, including Visual FoxPro, VB6, Delphi, and Microsoft Access migrations. Connect with David on LinkedIn.
Technical review by Don Knoup, Software Development Manager at Ticomix.