Logistics & field service
Rescuing a "black box"
Starting point: FoxPro DOS (data transfer via USB sticks), VFP 6 back office, and source code that was partly lost. Using decompilation & reverse engineering, we reconstructed the business logic and transformed it into a modern web (Angular) and mobile (iOS/Android) solution for 5,000 end customers.
Questions that come up in exactly this kind of project
The following points are regularly decisive for this type of legacy system - and the reason a migration rarely fails because of the programming language.
What about `DECLARE DLL` calls, `VFPX` or `wwipstuff`?
That is a core part of the 'archaeology'. We analyze cryptic `DECLARE DLL` calls to understand their purpose and translate them into modern .NET or API-based equivalents. Libraries such as Rick Strahl's `wwipstuff` (West Wind Internet Protocols), the `West Wind Web Connection (WWWC)` framework or the many `VFPX` extensions are familiar territory for us. We have, for example, already integrated .NET functionality into legacy VFP systems through `wwDotnetBridge` and know how to migrate that logic natively.
What about nightly batch jobs and terminal-server operation?
Running VFP on terminal servers is a typical workaround to make it feel "web-like". The new web application makes that workaround obsolete. We analyze nightly batch jobs and migrate them into modern server-side processes such as serverless functions, container jobs like Kubernetes CronJobs, or API-driven workflows.
How does "parallel operation" work technically?
We use the "strangler (fig) pattern", meaning iterative replacement. This is a sensitive phase. Instead of risky "dual-write" approaches, where data is written to two places at once, we prefer safer mechanisms such as interim APIs or synchronous events. That allows the new application, while the old one is still running, to report data back to the legacy database through a controlled interface. The result is a much lower risk of data divergence and a safer live transition.
What happens to our FRX reports and ActiveX/OCX controls?
This is a critical topic. We migrate reports (`FRX/LBX`), often rendered through export tools such as `XFRX`, `FoxyPreviewer` or PDF drivers like `Amyuni`, onto modern reporting platforms. We recommend and use established commercial platforms such as DevExpress or Telerik, for which we hold licenses, because they come with full vendor support. If a client explicitly prefers open-source alternatives, we can implement them as well while clearly outlining possible trade-offs such as support gaps or missing features. Outdated `ActiveX/OCX` controls, for example in the UI layer, are replaced with modern web components, and we use that step to improve UI/UX and accessibility (a11y).
Does this sound like your system?
Then let us spend 45 minutes on it. No obligation, no cost, and an honest assessment at the end - including when that assessment is: keep running it safely for now.
Request a strategy call