Warum VFP-Systeme 2026 noch laufen

Wer heute “Visual FoxPro” sagt, bekommt oft ein müdes Lächeln zurück. Zu Recht, könnte man meinen — Microsoft hat die Plattform 2007 offiziell eingestellt, der letzte Build (VFP 9 SP2) stammt von 2007. Und doch: In Lagerverwaltungen, Handwerksbetrieben und mittelständischen Fertigungsunternehmen läuft heute, 2026, noch Code, der in den späten 90ern geschrieben wurde.

Es ist kein technisches Versagen

Der Grund dafür ist selten Ignoranz. VFP-Anwendungen waren für ihre Zeit ungewöhnlich robust: Die DBF/CDX-Datenstruktur ist simpel genug, um auch nach zwei Jahrzehnten ohne aktive Pflege noch lesbar zu sein, und die Sprache selbst war pragmatisch auf Business-Logik zugeschnitten, nicht auf akademische Eleganz.

Das eigentliche Problem ist selten der Code — es sind die Abhängigkeiten drumherum. Ein VFP-Programm, das seit 2003 läuft, hat oft eine sehr spezifische Windows-Version, einen sehr spezifischen Drucker-Treiber und einen sehr speziellen Netzwerk-Freigabe-Pfad im Kopf. Die Anwendung selbst überlebt fast alles. Ihre Umgebung tut das nicht.

Migration ist ein Risiko, Stillstand auch

Genau deshalb ist “wir migrieren das jetzt komplett neu” oft die riskantere Option, nicht die sicherere. Ein Rescue-Audit zuerst — verstehen, was der Code wirklich tut, welche Reports wirklich gebraucht werden, welche Schnittstellen wirklich noch bedient werden müssen — spart am Ende Monate.

Schrittweise Modernisierung, zum Beispiel Richtung Servoy, funktioniert deutlich zuverlässiger als ein Big Bang: neue Oberfläche, alte Datenbasis, Übergangszeit inklusive. Das System muss nicht sterben, um zu wachsen.