Your Visual FoxPro software. Finally future-ready.

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).

That is the normal case. Our process includes a deep data audit. We know how to migrate `Memo` fields, correctly handle `codepages` (character sets such as Windows-1252) and preserve the semantics of the `SET DELETED` command. We clean up organically grown structures and move them into a clean relational SQL schema, including proper `NULL` handling instead of empty strings. That also resolves historical `codepage` issues and enables real `UTF-8` support, for example for German and Chinese. We are equally familiar with `ODBC` pitfalls such as `varchar(max)` issues and address them during data model refactoring.

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.

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.

Quite the opposite. That is an advantage. We know these architectures well. Our expertise explicitly covers migrations of applications built on established VFP frameworks such as Visual Extend (VFX) or component libraries like Acodey (from ProLib). We understand how those frameworks work, including the "magic" parts, and can transfer their specific logic into modern, framework-independent structures.

These commands fundamentally change how VFP compares data, for example `SET EXACT` for string comparisons. We understand that semantics in detail. During the audit, we identify those `SET` commands and preserve the behavior through `golden master` tests, meaning automated test cases that validate the legacy behavior 1:1 so the new system remains functionally identical.

Excellent question. This is one of the core challenges in web migrations. VFP's `TABLEUPDATE()` conflict handling, where a record has been modified by someone else, must be modeled explicitly in the new system. On the web, this is typically handled through concurrency control: when a record is loaded, it receives an invisible token (an ETag). On save, the server checks whether that token still matches. If it does not, because somebody else saved first, the operation is blocked and the user is informed. That creates a safe and transparent process for preventing data conflicts.

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.

Absolutely. We know the VFP ecosystem inside out. Database models from `xCase` are a valuable source for reverse engineering. We are familiar with reporting tools such as `Stonefield Query`, barcode generators such as `FoxBarcode`, and strategies for `Cryptor`-encrypted DBFs. We also know the common ActiveX controls from vendors such as `DBITech` or `Codejock`, as well as their modern web-based alternatives.

This is a common topic. VFP-based Office automation is slow and requires Office to be installed. We migrate that logic into performant server-side solutions, for example .NET libraries, that generate Word or Excel files *without* requiring Office on the server or client. For analytics and reporting, we often connect self-service tools such as PowerBI directly to the new database.

We take this seriously. Data sovereignty remains fully in your hands. You decide whether the new solution runs on-premises or in the cloud, including your preferred region such as Frankfurt. We advise in a GDPR-compliant manner, mask test data and, if requested, support the implementation of compliance requirements such as audit logs, KYC or AML. Naturally, we also carry IT project liability insurance that covers data migration risks.

That is a valid concern. The gap between local DBFs and web latency is real. We address performance through (1) a clean API architecture instead of direct database access, (2) intelligent caching of master data and (3) optimized queries and index design. Together with you, we define performance targets (KPIs) for your most critical screens and business processes.