Votre logiciel métier.
Libre d’évoluer.

Il n’existe pas de tarif unique : le coût dépend des fonctions à conserver, du volume de code et de données, des interfaces externes, de la documentation disponible et des contraintes de continuité. Le budget doit aussi intégrer les tests métier, le déploiement et l’accompagnement des utilisateurs. Nous commençons par qualifier ces éléments ; un audit ou un pilote peut être proposé pour lever les inconnues avant un chiffrage détaillé. Pour préparer votre demande, indiquez les versions utilisées, les utilisateurs concernés et les objectifs du changement. Découvrir notre accompagnement migration.

Conserver WinDev peut être pertinent si votre application répond aux usages, reste maintenable et s’intègre correctement à votre environnement. Un changement mérite d’être étudié lorsque vos besoins d’accès web, d’intégration ou d’exploitation évoluent, ou lorsque certaines dépendances deviennent trop contraignantes. Nous comparons maintien, modernisation ciblée et migration en tenant compte du coût global et des risques. C# et JavaScript sont des exemples de technologies possibles, pas des destinations imposées. Faire le point avec un audit ou étudier une modernisation.

Une migration par modules peut permettre de conserver l’application actuelle pendant la construction de la nouvelle. Sa faisabilité dépend de la façon dont les fonctions et les données sont liées : il faut définir les responsabilités de chaque système, les échanges et les règles de synchronisation. Nous validons la démarche sur un périmètre pilote, préparons les sauvegardes, la recette et les conditions de retour arrière. Une fenêtre d’interruption peut rester nécessaire pour la bascule finale ; son besoin et sa durée se déterminent après essais. Comprendre les étapes d’une migration.

La première étape consiste à rassembler les sources, la version de WinDev, les composants tiers, la documentation et les éléments nécessaires à la compilation et au déploiement. Nous vérifions ensuite les droits permettant l’intervention et cherchons à reconstruire une version de référence dans un environnement de test. Les échanges avec les utilisateurs aident à retrouver les règles métier non documentées. Sans les sources ou certains composants, les possibilités de correction peuvent être limitées : nous explicitons ces limites avant de proposer un plan de reprise. Ne transmettez aucun mot de passe dans le formulaire de contact. Étudier une reprise et une maintenance.

Nous commençons par inventorier les données, leurs relations et les traitements qui leur donnent un sens. Les règles métier sont documentées avec vos équipes, puis traduites en scénarios de recette. La reprise est répétée sur un environnement de test avec des contrôles de volumes, de cohérence, de totaux et de résultats métier ; copier les tables ne suffit pas. Les écarts doivent être analysés avant validation. Le plan de bascule prévoit les sauvegardes, le traitement des modifications récentes et les conditions d’un retour arrière. Découvrir la démarche de migration des données HFSQL vers PostgreSQL.