¿Cómo lidiar con las situaciones de “fin de vida del software”?


14

Cuando un proveedor declara que ya no tiene la intención de proporcionar soporte o servicios a un software (y declara la intención de salir del negocio, sin ofrecer rutas de actualización), ¿qué tipo de recurso está disponible para el cliente?

Considere esto desde el punto de vista del cliente . Es probable que el personal de TI del cliente solo considere las opciones técnicas, pero es probable que también haya opciones no técnicas que el cliente pueda seguir. Además, ¿qué tipo de pasos razonables puede tomar el cliente con anticipación para minimizar la interrupción, como en los términos del contrato?

Cosas que puedo pensar:

  • Necesita comprar hardware de repuesto y configurar un entorno de repuesto en el que el software pueda continuar funcionando.
  • Varios métodos de exportación de datos que no requieren la participación del proveedor. (Esto puede incluir técnicas triviales, como examinar los datos almacenados en el backend de una base de datos de productos básicos, a las técnicas más complicadas, como el raspado de pantalla, la impresión en imagen seguida de un nuevo escaneo, etc.)
  • Sistemas paralelos donde el personal duplicará los datos antiguos en un nuevo sistema de forma manual o semiautomática
  • Medios legales, en caso de que el vendedor tenga problemas financieros (como en el caso de la custodia del código fuente )

¿Alguna otra idea?

  • Suponiendo que no hay una "elusión" involucrada (sin DRM, sin DMCA), ¿es legal / aceptable la recuperación de datos o la ingeniería inversa?

Nota editada:

Es una combinación de varias historias anecdóticas, pero reales. No estoy directamente involucrado en ninguno de esos. Es simplemente mi deseo aprender cómo se maneja la situación del "fin de la vida útil del software" en general. No es mi intención hacer que la historia original parezca demasiado "difícil" para ser resuelta.


¿Cuál es la línea de tiempo aquí? ¿Eres cliente o creas un producto sobre dicho proveedor?

3
¿Puede intentar comprar el código fuente del proveedor y luego mantenerse? Esta es una situación bastante difícil.
hasta

2
Hace que uno se pregunte por qué los datos no se han almacenado en algún tipo de formato abierto para empezar ... si se almacena como texto sin formato en db, puede copiarlo. Si está almacenado en xml / texto plano, puede copiarlo. Si es binario / encriptado, entonces necesita descifrarlo. Todo es factible.
Trabajo

3
@ Job: de acuerdo. La importancia del formato de almacenamiento abierto / simple (y el concepto de "bloqueo de proveedores") se ha reconocido durante más de una década. Las decisiones tomadas hace varias décadas no tendrían este beneficio de la retrospectiva. En aquel entonces, los clientes ricos acudían con los líderes del mercado independientemente del costo, y los clientes menos ricos tenían que aceptar el statu quo o correr el riesgo.
rwong

Este tipo de historias sirven como buenos ejemplos de por qué es bueno tener planes de salida de datos. Eso puede estar utilizando formatos abiertos como sugiere @rwong, pero eso también debería significar tener cláusulas de exportación en los contratos.
smithco

Respuestas:


2

La ingeniería inversa es perfectamente aceptable en sus propios datos. Asumiendo que tiene los archivos de la base de datos para empezar. Si es un servicio alojado, es mejor que solo pague la tarifa y haga que exporten los datos. OMI, es extremadamente grosero y poco profesional de su parte exigir una tarifa por eso, pero a algunas personas no les importan esas cosas.

Como sabe que esta aplicación es algo que necesita, quizás si es factible, ¿es hora de un sistema desarrollado internamente? De esta manera no volverás a terminar en esta situación.


2

Una estrategia que no está en su lista es traer un equipo de pasantes y darles el verano para resolverlo. Dado que probablemente sería un proyecto único, no importará si el código es bonito, si lleva muchas horas o si solo requiere una gran cantidad de entrada de datos manual.


2
Pasantes: el equivalente local de la subcontratación
Earlz

Internsourcing!
Paul Nathan

0

Si el producto es algo para lo que no necesita cambios, no prevea que se requieran cambios y se ejecute en su propio hardware, siempre existe la opción de aceptar el riesgo de seguir usándolo.

No es lujoso, y puede ser una molestia, pero dependiendo del producto y el proveedor que pueda encontrar si piensa en ello, la situación no es diferente de cuando era técnicamente compatible con el proveedor.

Una nota: si el sistema es algo expuesto al público, entonces este es un mal enfoque porque no tiene forma de aplicar actualizaciones de seguridad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.