Nous migrons vos applications VFP critiques en sécurisant l’intégrité des données et en visant une couverture fonctionnelle complète vers des solutions cloud modernes, des applications web et des bases de données SQL sécurisées, même lorsque les développeurs d’origine sont déjà partis à la retraite.
Avec une première estimation du périmètre, du planning et de l’architecture cible.
Plus de 20 ans d’expérience Visual FoxPro
Maîtrise approfondie de l’architecture VFP, des structures de données (DBC/DBF) et du reporting (FRX).
Transformation itérative
Un remplacement itératif (pattern Strangler) plutôt qu’une bascule "big bang" risquée.
Phases définies et feuille de route
Un plan de projet clair, avec des jalons visibles et une maîtrise budgétaire.
Au lieu de réinventer votre application à partir de zéro, nous transférons ce que votre système actuel a de plus précieux vers une architecture prête pour l’avenir. Vous protégez ainsi votre savoir-faire, réduisez votre dette technique et gagnez en agilité.
Ces difficultés vous semblent-elles familières ?
Nous avons repris une migration en échec (DOS → VFP9/VFX). Grâce à une solide expertise VFP, notamment une optimisation Rushmore ciblée des requêtes, nous avons ramené le temps d’exécution d’un processus critique de facturation de 20 heures à 4 heures. Après la migration complète de l’application et le passage à PostgreSQL, ce temps est descendu à moins de 15 minutes.
Voir le projet en détail →Point de départ : FoxPro DOS (échanges de données via clés USB), back-office VFP 6 et code source partiellement perdu. Grâce à la décompilation et à la rétro-ingénierie, nous avons reconstitué la logique métier et l’avons transformée en une solution web (Angular) et mobile (iOS/Android) moderne pour 5 000 clients finaux.
Voir le projet en détail →Migration d’une application de bureau VFP 6 reposant sur des calculs propriétaires très complexes pour un usage industriel spécialisé. Toute la logique a été validée en 1:1 puis transférée dans une application web moderne afin d’en préserver la précision.
Voir le projet en détail →Synthèse, sur le fond, des retours recueillis dans nos projets de migration.
Les chiffres s’analysent directement dans le système, au lieu d’être reconstitués via des exports et des changements de format.
La migration ne s’arrête pas à la copie : là où subsistait une rupture numérique, une vraie valeur apparaît, et les vieilles habitudes disparaissent.
L’analyse fine du code et des flux met au jour des processus appliqués depuis des années, mais dépassés depuis longtemps.
Un coup d’œil rapide aux données se fait aussi depuis un téléphone : le poste Windows attitré ne manque plus.
On ne migre pas un « système monstre » avec une recette standard. Notre méthode est conçue pour la réalité des environnements historiques : d’abord sécuriser le savoir (archéologie), puis le transformer de manière maîtrisée.
Votre principale inquiétude correspond précisément à notre cœur d’expertise. Nous ne récupérons pas seulement le code. Nous récupérons aussi le "pourquoi" qui s’est perdu au fil du temps.
Vous n’avez plus que des fichiers `EXE`/`FXP` ? Nous utilisons des décompilateurs et des heuristiques pour reconstituer un code source lisible et poser une base fiable pour l’analyse.
Si nécessaire, nous organisons des ateliers sur site, par exemple "une semaine avec la comptabilité", pour capter le savoir implicite ("les astuces d’Erna"). Dès qu’une logique reste floue, nous investiguons de manière proactive.
Le développeur d’origine est à la retraite ? Grâce aux entretiens, à l’analyse des logs et à la rétro-ingénierie, nous documentons le "pourquoi" qui sous-tend une logique métier construite au fil des années.
Nous traquons les macros `Excel` et les bases `Access` développées en marge du système principal et qui écrivent des données critiques, souvent via `ODBC`, directement dans les `DBFs`.
Rien ne nous surprend : 17 versions différentes d’`EXE`, contournements `Y2K`, chemins IP `hardcoded` ou bases `Access`. Nous identifions et migrons aussi ce chaos.
Nous analysons votre base de code en profondeur et produisons des métriques comme la complexité, le LoC et les dépendances afin d’estimer l’effort avec réalisme.
Nous ne "convertissons" pas à l’aveugle. Nous extrayons la logique précieuse et la replaçons dans des structures propres, modernes et testables.
Nous avançons de manière itérative. Vous recevez régulièrement des incréments testables et validez les résultats par rapport au comportement « Golden Master » de l’application historique.
Nous accompagnons la mise en service, formons vos équipes et proposons, si besoin, un support long terme (SLA) pour la nouvelle plateforme.
Des outils comme Servoy, xSharp ou Lianja promettent une conversion rapide. Le problème est simple : vous remplacez une dépendance obsolète par une autre. Ces plateformes reposent souvent sur de petites équipes, génèrent des coûts de licence et laissent planer une forte incertitude à long terme.
Nous faisons délibérément le choix de standards technologiques éprouvés : .NET, Angular, Vue, PostgreSQL & SQL Server.
Une migration est un investissement. Des termes comme « Kubernetes » ou « cloud » paraissent coûteux, mais ce n’est pas une fatalité. Notre principe est simple : nous ne recommandons que ce dont vous avez réellement besoin pour un MVP (Minimum Viable Product) réussi et économiquement pertinent.
Toutes les applications n’ont pas besoin d’une version mobile ni de Kubernetes. Nous trouvons le bon équilibre entre standards modernes, comme Docker on-premise, et votre budget.
Le retour sur investissement vient souvent des gains de performance. Quand un traitement de facturation passe de 20 heures à 15 minutes, comme nous l’avons déjà obtenu, la migration s’amortit rapidement.
Nous vous conseillons avec transparence sur les alternatives open source et vous aidons activement à solliciter des aides, par exemple des programmes de transformation numérique en Allemagne ou des crédits Azure via Microsoft Founders Hub.
Vous décidez du TCO (coût total de possession) : serveurs internes ou Azure, PostgreSQL ou SQL Server. Nous rendons l’impact économique de chaque option parfaitement lisible.
La technologie n’est qu’une moitié du sujet. Le plus grand défi consiste souvent à faire basculer 500 collaborateurs d’un système vieux de 20 ans vers une nouvelle interface sans interrompre l’activité quotidienne, souvent en pleine clôture annuelle ou pendant la haute saison.
Nous planifions la migration autour de vos périodes "no-go", comme la clôture annuelle ou la haute saison. Les étapes critiques de cut-over sont programmées, par exemple le week-end, afin de protéger l’exploitation.
Vos équipes métier n’ont pas de temps pour les tests ? Nous définissons avec vous une équipe dédiée de key users, réservons leur capacité de test dans le projet et les formons de façon itérative sur les nouveaux modules.
Souvent, la direction financière veut "exactement la même chose" tandis que l’IT veut "tout refaire". Nous agissons comme médiateur neutre entre les équipes, traduisons les besoins et construisons un consensus viable pour le métier comme pour la technique.
C’est un sujet critique. Nous migrons les rapports (`FRX/LBX`), souvent produits via des outils comme `XFRX`, `FoxyPreviewer` ou des pilotes PDF tels que `Amyuni`, vers des plateformes de reporting modernes. Nous recommandons et utilisons des plateformes commerciales éprouvées, comme DevExpress ou Telerik, pour lesquelles nous détenons des licences et bénéficions d’un support éditeur complet. Si un client privilégie explicitement une alternative open source, nous pouvons aussi l’implémenter, en explicitant clairement les compromis possibles, par exemple des lacunes de support ou des fonctionnalités manquantes. Les contrôles `ActiveX/OCX` obsolètes, notamment côté interface, sont remplacés par des composants web modernes, et nous profitons de cette étape pour améliorer l’UI/UX et l’accessibilité (a11y).
C’est la situation la plus fréquente. Notre démarche inclut un audit de données approfondi. Nous savons migrer les champs `Memo`, gérer correctement les `codepages` (jeux de caractères comme Windows-1252) et préserver la sémantique de la commande `SET DELETED`. Nous assainissons les structures héritées et les transférons dans un schéma SQL relationnel propre, avec une gestion correcte des `NULL` plutôt que des chaînes vides. Cela résout aussi les anciens problèmes de `codepage` et permet un vrai support `UTF-8`, par exemple pour l’allemand ou le chinois. Nous maîtrisons également les pièges des intégrations `ODBC`, comme les problèmes liés à `varchar(max)`, et les traitons pendant la refonte du modèle de données.
Nous nous appuyons sur le "Strangler (Fig) Pattern", autrement dit un remplacement itératif. C’est une phase sensible. Plutôt que d’opter pour un "dual-write" risqué, où les données sont écrites simultanément à deux endroits, nous privilégions des mécanismes plus sûrs comme des API intermédiaires ou des événements synchrones. Ainsi, tant que l’ancien système tourne encore, la nouvelle application peut renvoyer ses données vers la base historique via une interface contrôlée. Le risque de divergence des données diminue nettement et la transition en production devient beaucoup plus sûre.
Faire tourner VFP sur Terminal Server est un contournement classique pour lui donner une apparence "web". La nouvelle application web rend ce détour inutile. Nous analysons les batchs nocturnes et les migrons vers des processus serveur modernes, comme des fonctions serverless, des jobs conteneurisés de type Kubernetes CronJobs ou des workflows pilotés par API.
Bien au contraire. C’est un avantage. Nous connaissons parfaitement ces architectures. Notre expertise couvre explicitement les migrations d’applications construites sur des frameworks VFP établis comme Visual Extend (VFX) ou des bibliothèques de composants comme Acodey (de ProLib). Nous comprenons leur fonctionnement, y compris leurs parties "magiques", et savons transférer cette logique spécifique dans des structures modernes indépendantes du framework.
Ces commandes modifient en profondeur la manière dont VFP compare les données, par exemple `SET EXACT` pour les comparaisons de chaînes. Nous en maîtrisons la sémantique en détail. Pendant l’audit, nous identifions ces commandes `SET` et en préservons le comportement grâce à des tests « Golden Master », c’est-à-dire des cas automatisés qui valident le comportement historique en 1:1 afin que le nouveau système reste fonctionnellement identique.
Excellente question. C’est l’un des enjeux majeurs d’une migration web. La gestion de conflits de `TABLEUPDATE()` dans VFP, lorsqu’un autre utilisateur a modifié l’enregistrement, doit être modélisée explicitement dans le nouveau système. Sur le web, cela se traite généralement via un contrôle de concurrence : au chargement, l’enregistrement reçoit un jeton invisible (ETag). Lors de l’enregistrement, le serveur vérifie si ce jeton est toujours identique. Si ce n’est plus le cas, parce qu’un autre utilisateur a enregistré avant, l’opération est bloquée et l’utilisateur est informé. Cela crée un processus sûr et transparent pour éviter les conflits de données.
C’est un volet central de l’"archéologie". Nous analysons les appels `DECLARE DLL` cryptiques pour en comprendre le rôle et les traduire vers des équivalents modernes en .NET ou via API. Des bibliothèques comme `wwipstuff` de Rick Strahl (West Wind Internet Protocols), le framework `West Wind Web Connection (WWWC)` ou les nombreuses extensions `VFPX` font partie de notre quotidien. Nous avons par exemple déjà intégré des fonctionnalités .NET dans des systèmes VFP historiques via `wwDotnetBridge` et savons migrer cette logique de façon native.
Oui, tout à fait. Nous connaissons très bien l’écosystème VFP. Les modèles de base issus de `xCase` constituent une source précieuse pour la rétro-ingénierie. Nous sommes familiers des outils de reporting comme `Stonefield Query`, des générateurs de codes-barres comme `FoxBarcode` et des stratégies de traitement des DBF chiffrés avec `Cryptor`. Nous connaissons aussi les contrôles ActiveX courants d’éditeurs comme `DBITech` ou `Codejock`, ainsi que leurs équivalents web modernes.
C’est un sujet très fréquent. L’automatisation Office depuis VFP est lente et impose une installation locale d’Office. Nous migrons cette logique vers des solutions serveur performantes, par exemple des bibliothèques .NET, capables de générer des fichiers Word ou Excel *sans* nécessiter Office sur le serveur ni sur le poste client. Pour l’analyse et le reporting, nous connectons souvent des outils self-service comme PowerBI directement à la nouvelle base de données.
Nous traitons ce sujet avec le plus grand sérieux. La souveraineté des données reste entièrement entre vos mains. Vous choisissez si la nouvelle solution fonctionne on-premise ou dans le cloud, y compris la région souhaitée, par exemple Francfort. Nous vous conseillons dans le respect du RGPD, masquons les données de test et, si nécessaire, accompagnons la mise en place d’exigences de conformité comme les audit logs, le KYC ou l’AML. Et nous sommes couverts : auprès de Hiscox SA, nous disposons d’une assurance responsabilité civile professionnelle (errors & omissions) ainsi que d’une assurance responsabilité civile d’exploitation. La garantie responsabilité professionnelle correspond précisément au type de risque que comporte une migration de données.
C’est une préoccupation légitime. L’écart entre des DBF locales et la latence web est bien réel. Nous traitons la performance via (1) une architecture API propre plutôt qu’un accès direct à la base, (2) une mise en cache intelligente des données de référence et (3) l’optimisation des requêtes et des index. Avec vous, nous définissons des objectifs de performance (KPI) pour les écrans et les processus métier les plus critiques.
Des interfaces modernes et réactives, avec un accent clair sur l’ergonomie, la performance et la productivité.
Une logique métier proprement modélisée, plutôt que des règles dispersées directement dans l’interface.
Une base de données robuste, avec traçabilité complète et supervision de bout en bout.
Tout comme la pierre de Rosette a permis de comprendre les hiéroglyphes, nous déchiffrons les applications VFP historiques. Nous ne traduisons pas seulement du code : nous transposons des décennies de logique métier irremplaçable vers une plateforme prête pour l’avenir.
Notre Lead Architect, Bernhard Reiter, dirige l’équipe d’experts VFP. Il s’appuie sur une équipe cœur de spécialistes crossVault, renforcée si nécessaire par des partenaires de longue date, éprouvés issus de notre réseau d’experts VFP, et reste profondément ancré dans la communauté VFP.
Il a été formé chez ProLib GmbH, l’une des références VFP majeures dans la région DACH, avec un diplôme obtenu en 2005. Dès 2004, il intervenait déjà à l’European VFP DevCon (dFPUG) de Francfort sur le thème "FoxPro sur le Web".
Avec de nombreuses années de pratique en développement d’entreprise sur Visual FoxPro, y compris avec Active FoxPro Pages 3.0 et des bibliothèques de composants comme Acodey, cet ADN VFP devient un véritable atout pour votre migration.
Profitez d’un entretien stratégique de 45 minutes pour nous présenter votre situation FoxPro actuelle. Sans engagement et sans frais.
Demander un rendez-vousExpliquez-nous où vous en êtes. Nous vous donnerons une évaluation honnête, que vous ayez besoin d’une migration complète ou d’un support professionnel pour votre système actuel. Vous recevrez ensuite une proposition concrète.
Pour les questions techniques, un appel est souvent le chemin le plus court. Appelez-nous ou indiquez-nous brièvement quand vous joindre.
Vous n’êtes pas encore prêt pour une migration ? Nous proposons aussi du conseil, de la maintenance et du support professionnels pour votre application Visual FoxPro actuelle afin de sécuriser l’exploitation.