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.
Respuestas:
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.
fuente
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.
fuente
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.
fuente