Ihre Visual-FoxPro-Software. Endlich zukunftssicher.

Ein kritischer Punkt. Reports (`FRX/LBX`), die oft über Export-Tools wie `XFRX`, `FoxyPreviewer` oder PDF-Export-Treiber wie `Amyuni` ausgegeben werden, migrieren wir in moderne Plattformen. Wir empfehlen und nutzen etablierte kommerzielle Reporting-Plattformen (z.B. DevExpress, Telerik), für die wir Lizenzen besitzen, da diese voll unterstützt werden. Auf expliziten Kundenwunsch implementieren wir auch Open-Source-Alternativen, klären Sie aber transparent über mögliche Nachteile (z.B. Supportlücken, fehlende Funktionen) auf. Veraltete `ActiveX/OCX`-Controls (z.B. für UI) ersetzen wir durch moderne Web-Komponenten, wobei wir auch die UI/UX modernisieren und auf Barrierefreiheit (a11y) achten.

Das ist der Normalfall. Unser Prozess beinhaltet ein tiefes Daten-Audit. Wir beherrschen die Migration von `Memo`-Feldern, die korrekte Handhabung von `Codepages` (Zeichensätze, z.B. Windows-1252) und die Semantik des `SET DELETED`-Befehls. Wir räumen "gewachsene" Strukturen auf und überführen sie in ein sauberes, relationales SQL-Schema (inkl. `NULL`-Handling statt leerer Strings). Das löst auch die alten `Codepage`-Probleme und ermöglicht echte `UTF-8`-Unterstützung (z.B. für Deutsch/Chinesisch). Wir kennen auch die Tücken von `ODBC`-Anbindungen (z.B. `varchar(max)`-Probleme) und lösen diese beim Refactoring des Datenmodells auf.

Wir nutzen das "Strangler (Fig) Pattern" (iterative Ablösung). Das ist ein sensibler Schritt. Statt eines riskanten "Dual-Write" (Daten an zwei Orte gleichzeitig schreiben) nutzen wir sicherere Methoden, z.B. Interims-APIs oder synchrone Events. So kann die neue Anwendung (solange die alte noch läuft) ihre Daten über eine gesicherte Schnittstelle auch an die alte Datenbank melden. Das minimiert das Risiko von Daten-Divergenz und sichert den laufenden Betrieb.

Der Betrieb auf Terminalservern ist ein typisches Symptom, um VFP "Web-ähnlich" zu machen. Dies wird durch die neue Web-Anwendung obsolet. Nächtliche Batchjobs (Prozeduren) analysieren wir und überführen sie in moderne "Serverless Functions", Container-Jobs (z.B. Kubernetes CronJobs) oder API-gesteuerte Prozesse.

Im Gegenteil, das ist ein Vorteil. Wir kennen diese Architekturen. Unsere Expertise umfasst explizit die Migration von Anwendungen, die auf gängigen VFP-Frameworks wie Visual Extend (VFX) oder bekannten Komponenten-Pools wie Acodey (von ProLib) basieren. Wir verstehen deren Architektur, kennen die "magischen" Teile und können die spezifische Logik sicher in moderne, framework-unabhängige Strukturen überführen.

Diese Befehle ändern fundamental, wie VFP Daten vergleicht (z.B. `SET EXACT` bei String-Vergleichen). Wir kennen diese Semantik. Beim Audit identifizieren wir diese `SET`-Befehle und sichern die korrekte Logik durch `Golden-Master`-Tests (automatisierte Testfälle, die das Altsystem-Verhalten 1:1 prüfen), um sicherzustellen, dass Vergleiche im neuen System fachlich identisch funktionieren.

Eine exzellente Frage, das ist ein Kernproblem bei Web-Migrationen. VFP's `TABLEUPDATE()`-Konfliktlösung (Datensatz wurde von einem anderen geändert) muss modern abgebildet werden. Im Web löst man dies über 'Concurrency-Handling' (Gleichzeitigkeits-Prüfung): Der Datensatz erhält beim Laden einen unsichtbaren 'Token' (genannt ETag). Beim Speichern prüft der Server, ob der Token noch derselbe ist. Wenn nicht (ein anderer war schneller), wird das Speichern blockiert und der Nutzer informiert (z.B. "Daten wurden in der Zwischenzeit geändert. Bitte laden Sie neu.") - ein sicherer Prozess, der Datenkonflikte verhindert.

Das ist ein Kernteil der 'Archäologie'. Wir analysieren kryptische `DECLARE DLL`-Aufrufe, um deren Funktion zu verstehen und in moderne .NET- oder API-Calls zu übersetzen. Bibliotheken wie Rick Strahls `wwipstuff` (West Wind Internet Protocols), das `West Wind Web Connection (WWWC)` Framework oder die vielen `VFPX`-Erweiterungen sind uns bestens bekannt. Wir haben z.B. mit der `wwDotnetBridge` bereits erfolgreich .NET-Funktionalität in VFP-Altsysteme integriert und wissen, wie wir diese Logik nativ migrieren.

Absolut. Das VFP-Ökosystem ist uns vertraut. Datenbank-Modelle aus `xCase` sind eine wertvolle Quelle für das Re-Engineering. Wir kennen Reporting-Tools wie `Stonefield Query`, Barcode-Generatoren wie `FoxBarcode` und haben Strategien für `Cryptor`-verschlüsselte DBFs. Ebenso kennen wir die gängigen ActiveX-Controls von Anbietern wie `DBITech` oder `Codejock` und deren moderne Web-Alternativen.

Ein häufiger Punkt. Die VFP-Office-Automatisierung ist langsam und erfordert ein installiertes Office. Wir migrieren diese Logik in performante Server-Side-Lösungen (z.B. .NET-Bibliotheken), die Word- oder Excel-Dateien generieren, *ohne* dass Office auf dem Server (oder Client) installiert sein muss. Für Auswertungen binden wir oft Self-Service-Tools wie PowerBI an die neue Datenbank an.

Wir nehmen das ernst. Die Datenhoheit bleibt zu 100% bei Ihnen - Sie entscheiden, ob die neue Lösung On-Premise oder in einer Cloud (mit Wunsch-Standort, z.B. Frankfurt) gehostet wird. Wir beraten Sie DSGVO-konform, maskieren Testdaten und unterstützen (falls gewünscht) auch bei der Implementierung von Compliance-Anforderungen wie Audit-Logs, KYC oder AML. Selbstverständlich verfügen wir über eine IT-Projekthaftpflichtversicherung, die auch Risiken bei der Datenmigration abdeckt.

Das ist ein valider Punkt. Der Performance-Unterschied von lokalen DBFs zu Web-Latenz ist real. Wir sichern die Performance durch (1) saubere API-Architektur statt direkter DB-Zugriffe, (2) intelligentes Caching von Stammdaten und (3) Optimierung der Datenbankabfragen (Index-Design). Wir definieren *gemeinsam* mit Ihnen Performance-Ziele (KPIs) für Ihre kritischsten Masken und Prozesse.