Come affrontare le situazioni di "fine del software"?

Quando un fornitore dichiara di non voler più fornire supporto o servizi a un software (e ha dichiarato l'intenzione di uscire dal business senza offrire percorsi di aggiornamento), che tipo di ricorso è disponibile per il cliente?

Si prega di considerare questo dal punto di vista del cliente . Il personale IT del cliente probabilmente prenderà in considerazione solo le opzioni tecniche, ma ci sono probabilmente opzioni non tecniche che il cliente può perseguire anche. Inoltre, che tipo di misure ragionevoli può essere intrapresa dal cliente in anticipo per ridurre al minimo l'interruzione, ad esempio in termini di contratto?

Cose che mi vengono in mente:

È necessario acquistare hardware di riserva e impostare un ambiente di riserva in cui il software può continuare a funzionare.
Vari metodi di esportazione dei dati che non richiedono il coinvolgimento del fornitore. (Ciò può includere tecniche banali come l'esame dei dati archiviati in un back-end del database delle merci, alle tecniche più coinvolte come lo scraping dello schermo, la stampa su immagine seguita da una nuova scansione, ecc.)
Sistemi paralleli in cui il personale duplicherà i vecchi dati in un nuovo sistema manualmente o semi-automaticamente
Mezzi legali, nel caso in cui il fornitore abbia problemi finanziari (come nel caso dell'impegno del codice sorgente )

Altre idee?

Supponendo che non vi sia alcuna "elusione" (nessun DRM, nessun DMCA), il recupero dei dati o il reverse engineering è legale / accettabile?

Nota modificata:

È una combinazione di diverse storie aneddotiche, ma reali. Non sono direttamente coinvolto in nessuno di questi. È semplicemente il mio desiderio di sapere come viene gestita la situazione di "fine vita del software" in generale. Non è mia intenzione far sembrare la storia originale troppo "difficile" per essere risolta.

— rwong
fonte

Quali sono le linee del tempo qui? Sei un cliente o costruisci un prodotto al di sopra di detto venditore?

Puoi provare ad acquistare il codice sorgente dal fornitore e supportarti? Questa è una situazione piuttosto difficile in cui trovarsi.

— btilly

Ci si chiede perché i dati non siano stati archiviati in una sorta di formato aperto per cominciare ... se sono memorizzati come testo normale in db, è possibile copiarli. Se è memorizzato in xml / testo normale, è possibile copiarlo. Se è binario / crittografato, è necessario decifrarlo. È tutto fattibile.

— Lavoro

@Job: d'accordo. L'importanza del formato di archiviazione aperto / semplice (e il concetto di "blocco dei fornitori") è stata riconosciuta per più di un decennio. Le decisioni prese diversi decenni fa non avrebbero avuto il senno di poi. All'epoca, i clienti benestanti andavano con i leader di mercato a prescindere dal costo e i clienti meno abbienti dovevano accettare lo status quo o correre il rischio.

— dal

Questo tipo di storie è un buon esempio del perché è bene avere piani di uscita dei dati. Questo può usare formati aperti come suggerisce @rwong, ma ciò dovrebbe anche significare avere clausole di esportazione nei contratti.

— smithco,

Risposte:

Il reverse engineering è perfettamente accettabile per i tuoi dati. Supponendo di avere i file di database per cominciare. Se si tratta di un servizio ospitato, potresti essere meglio solo pagando la tassa e facendoli esportare i dati. imo, è estremamente scortese e poco professionale da parte loro richiedere una tassa per questo, ma alcune persone non si preoccupano di tali cose.

Dato che sai che questa applicazione è qualcosa di cui hai bisogno, forse se fattibile, è tempo di un sistema sviluppato internamente? In questo modo non finirai di nuovo in questa situazione.

— GrandmasterB
fonte

Una strategia che non è nella tua lista è quella di coinvolgere un team di stagisti e dare loro l'estate per capirlo. Dal momento che sarebbe probabilmente un progetto unico, non importa se il codice è carino, se richiede molte ore o se richiede solo un sacco di immissione manuale dei dati.

— SMITHCO
fonte

Stagisti: l'equivalente locale dell'outsourcing

— Earlz,

Internsourcing!

— Paul Nathan,

Se il prodotto è qualcosa per cui non è necessario apportare modifiche, non prevedere la necessità di modifiche ed esecuzione sul proprio hardware, è sempre possibile accettare il rischio di continuare a utilizzarlo.

Non è lussuoso, e può essere una seccatura, ma a seconda del prodotto e del fornitore che potresti trovare se ci pensi che la situazione non è diversa da quando era il fornitore tecnicamente supportato.

Una nota: se il sistema è esposto al pubblico, si tratta di un approccio errato perché non è possibile applicare gli aggiornamenti di sicurezza.

— Conto
fonte