Tenemos que renovar nuestro sistema heredado de hace 12 años: ¿por partes o desde cero?

Hace tres años decidimos rehacer desde cero un sistema de logística de un volumen parecido. Nos dijeron 6 meses, tardó 16 meses clavados y el presupuesto casi se triplicó. La primera semana en producción, los cálculos de descuentos fallaban y mandamos facturas mal a cientos de clientes. Rehacer desde cero un sistema que ya está funcionando es jugársela muchísimo.

El camino que debes seguir al planificar una migración gradual es este: 1) Mapear las relaciones de la base de datos antigua e identificar los módulos independientes, 2) Colocar un enrutador delante del sistema para gestionar el tráfico, 3) Migrar primero los servicios no críticos con mucha lectura, 4) Dejar para el último paso los flujos principales como los pedidos y los pagos.

En mi experiencia como consultor, de 5 sistemas corporativos reescritos desde cero, 4 superaron la fecha de entrega prometida por lo menos en 6 meses. En cambio, en los sistemas transformados por fases, las desviaciones de presupuesto se mantuvieron en márgenes normales y ninguno sufrió cortes de pedidos críticos. La propuesta de tu desarrollador se apoya en una base mucho más realista.

La migración gradual también tiene un coste oculto: durante 18 meses, su equipo tendrá que gestionar dos arquitecturas distintas, dos modelos de datos diferentes y la sincronización entre ambos. Si el equipo es pequeño, esta doble carga de mantenimiento puede agotar a sus desarrolladores y volver a encallar el proyecto.

Dé el primer paso ya mismo para poner a prueba el plan de su desarrollador. Antes de firmar un contrato de 110.000 dólares con la agencia, dele 2 meses a su programador para desacoplar el módulo más sencillo. Si logra levantar el nuevo servicio y la sincronización de datos sin problemas, descarte la propuesta de la agencia de inmediato.

La agencia que afirma que va a reescribir desde cero y sin fallos un ERP complejo de 12 años en solo 8 meses, es porque aún no ha visto los descuentos personalizados ni las reglas contables no documentadas que hay dentro del sistema; el día del despliegue verá cómo esos 8 meses se convierten en 20.

el tema de la migracion de datos es de verdad el mayor dolor de cabeza. no puedes pasar los registros dañados o incompletos de la base de datos vieja al sistema nuevo sin limpiarlos antes. en la transicion gradual tienes la oportunidad de validar los datos reales paso a paso de golpe no tienes esa opcion.

Independientemente del método que elija, le recomiendo incluir en las cláusulas del contrato una garantía de integridad de datos y un procedimiento de reversión para cada etapa. Conviene no olvidar que la continuidad operativa siempre es más prioritaria que la arquitectura del software.

Pienso diferente. Si no se definen los criterios de aceptación, cuándo termina el trabajo es discutible.

Lo importante no es la cifra, sino en qué se basa esa cifra. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

Lo escribo para que no cometan el mismo error. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después. Si escribís el resultado aquí, también servirá de ayuda a otros.

Me quedé tranquilo al leer esta respuesta, así que no solo me pasa a mí. Si obtienes tres respuestas distintas sobre un tema la pregunta está mal formulada.

Antes de decidir, mirad qué datos tenéis en la mano... Si tenéis dudas escribid os responderé en la medida de lo posible.

Tengo una pregunta, no quiero desviarme del tema, pero... Si la propiedad del código no está en el contrato, al irte no tienes poder de negociación.

Intentar hacerlo solo es la vía más cara. También me gustaría saber si alguien lo hace de otra manera.

Voy a resumir el tema porque se han dado varias respuestas diferentes. El error cometido por renovación de sistema heredado suele ser reversible pero caro.

Hace mucho que oímos eso, pero a nosotros nunca nos pasó así. Las credenciales de acceso deben crearse a nombre de la empresa no con cuentas personales.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Pienso diferente. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Al tomar decisiones, escribe también el peor escenario, no solo el mejor. Comprobado por experiencia.

¿Y cómo resolvieron esto? Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Eso es todo, disculpa si me he extendido demasiado.

La discusión se ha dispersado, voy a ordenarla. Las decisiones apresuradas son las que hay que corregir seis meses después.

Lo dejo como nota, por si sirve.

Guardado.