Comment faire face aux situations de «fin de vie logicielle»?

Lorsqu'un fournisseur déclare qu'il n'a plus l'intention de fournir un support ou des services à un logiciel (et a déclaré son intention de quitter l'entreprise - n'offrant aucun chemin de mise à niveau), quel type de recours est disponible pour le client?

Veuillez considérer cela du point de vue du client . Le personnel informatique du client ne considérera probablement que les options techniques, mais il existe probablement des options non techniques que le client peut également envisager. En outre, quel type de mesures raisonnables le client peut-il prendre à l'avance pour minimiser les perturbations, par exemple en termes de contrat?

Choses auxquelles je peux penser:

• Besoin d'acheter du matériel de rechange et de configurer un environnement de rechange sur lequel le logiciel peut continuer à fonctionner.
• Diverses méthodes d'exportation de données qui ne nécessitent pas la participation du fournisseur. (Cela peut inclure des techniques triviales telles que l'examen des données stockées dans un backend de base de données de produits, aux techniques plus impliquées telles que le grattage d'écran, l'impression sur image suivie d'une nouvelle numérisation, etc.)
• Systèmes parallèles où le personnel dupliquera les anciennes données dans un nouveau système manuellement ou semi-automatiquement
• Moyens légaux, dans le cas où le vendeur a des problèmes financiers (comme dans le cas du dépôt de code source )

D'autres idées?

• En supposant qu'il n'y ait pas de «contournement» en cause (pas de DRM, pas de DMCA), la récupération des données ou l'ingénierie inverse est-elle légale / acceptable?

Note modifiée:

C'est une combinaison de plusieurs histoires anecdotiques, mais réelles. Je ne suis directement impliqué dans aucun de ces projets. Je souhaite simplement savoir comment la situation de "fin de vie logicielle" est gérée en général. Ce n'est pas mon intention de faire sonner l'histoire originale comme trop "difficile" à résoudre.

L'ingénierie inverse est parfaitement acceptable sur vos propres données. En supposant que vous disposez des fichiers de base de données pour commencer. S'il s'agit d'un service hébergé, il est préférable de simplement payer les frais et de les faire exporter les données. imo, c'est extrêmement grossier et peu professionnel d'entre eux d'exiger des frais pour cela, mais certaines personnes ne se soucient pas de ces choses.

Puisque vous savez que cette application est quelque chose dont vous avez besoin, peut-être si c'est faisable, son temps pour un système développé en interne? De cette façon, vous ne vous retrouverez plus dans cette situation.

Une stratégie qui n'est pas sur votre liste est de faire appel à une équipe de stagiaires et de leur donner l'été pour le comprendre. Comme il s'agirait probablement d'un projet ponctuel, peu importe si le code est joli, s'il prend beaucoup d'heures ou s'il prend juste beaucoup de saisie manuelle de données.

Si le produit est quelque chose que vous ne devez pas modifier, ne prévoyez pas de modifications et qu'il s'exécute sur votre propre matériel, il y a toujours la possibilité d'accepter le risque de continuer à l'utiliser.

Ce n'est pas compliqué, et cela peut être pénible, mais selon le produit et le fournisseur, vous pourriez trouver si vous y pensez que la situation n'est pas différente de ce qu'elle était lorsque le fournisseur l'a techniquement soutenu.

Une remarque: si le système est quelque chose exposé au public, c'est une mauvaise approche car vous n'avez aucun moyen d'obtenir les mises à jour de sécurité appliquées.