Modernización de aplicaciones empresariales: cuándo hacerla, cómo y cuánto cuesta
Su sistema no se cae. Ese es justamente el problema: mientras siga funcionando, nadie aprueba el proyecto. Las siete señales que convierten un sistema viejo en un riesgo de negocio, y el marco completo para decidir qué hacer con él.
Lectura de 11 minutos
En esta guía
Respuesta corta
Modernizar una aplicación empresarial no es reescribirla de golpe. Es elegir entre cuatro rutas —rehospedar, encapsular con APIs, refactorizar por módulos o reconstruir— y avanzar por fases, con el sistema actual corriendo en paralelo hasta que cada módulo nuevo demuestra que funciona. Un proyecto bien planteado no detiene la operación un solo día. Lo que sí se detiene, cuando no se hace nada, es la capacidad de la empresa para cambiar.
Lo que cuesta sostener lo que ya funciona
Hay una pregunta que casi nunca aparece en un reporte de TI: ¿cuánto cuesta al año mantener vivo el sistema que la empresa lleva usando desde hace una década?
No hablamos de la licencia, que suele estar amortizada o ni siquiera existir. Hablamos de las horas del equipo resolviendo lo mismo cada mes. De los tres procesos que se sostienen en hojas de cálculo porque el sistema no los cubre. De la integración que lleva dos años pospuesta porque nadie quiere tocar ese código. Y del hecho incómodo de que, probablemente, solo una persona entiende cómo funciona realmente.
Eso es deuda técnica, y su característica más engañosa es que no se paga de golpe: se paga todos los meses, en partidas que nadie suma porque están repartidas entre nómina, tiempo extra y proyectos que no avanzan.
La cuenta que nadie hace
Sume tres números del último año: horas del equipo dedicadas a mantener o parchar el sistema, horas de operación dedicadas a capturar dos veces lo que el sistema no comunica, y proyectos que se cancelaron porque "el sistema no lo permite". Ese total es el costo real de no modernizar, y casi siempre supera lo que costaría hacerlo.
La razón por la que el proyecto no arranca es siempre la misma, y es perfectamente razonable: modernizar suena a detener la operación. Nadie quiere ser quien paró la planta. Pero esa percepción viene de una forma de hacer las cosas que ya no es la única disponible.
Siete señales de que ya es un riesgo
Un sistema viejo no es necesariamente un problema. Un sistema viejo que cumple estas condiciones sí lo es:
- Una sola persona lo entiende. Si esa persona renuncia, se enferma o se jubila, la empresa se queda sin capacidad de modificar su propia operación. Es el riesgo más grande y el que menos aparece en los reportes.
- El fabricante ya no lo soporta. Sin parches de seguridad, cada mes que pasa la superficie de riesgo crece. En sistemas con datos de clientes o información fiscal, esto deja de ser un tema técnico.
- No se puede integrar con nada. Cuando la única forma de mover un dato entre dos sistemas es que alguien lo capture a mano, el sistema dejó de ser una herramienta y se volvió un cuello de botella.
- Cada cambio tarda meses. Si una modificación menor requiere un proyecto, la empresa perdió la capacidad de responder al mercado a la velocidad a la que el mercado se mueve.
- Corre sobre infraestructura que ya no se fabrica. Servidores físicos sin reemplazo, sistemas operativos fuera de ciclo, bases de datos en versiones sin soporte.
- La operación lo evita. Cuando la gente arma sus propias hojas de cálculo en paralelo, no es indisciplina: es la señal de que el sistema ya no resuelve lo que la operación necesita.
- Cumplir con un requisito nuevo es un proyecto. Un cambio fiscal, una certificación o un requisito de un cliente grande no deberían poner en crisis a todo el departamento.
Con dos de estas señales conviene planear. Con cuatro o más, el sistema ya es un riesgo de continuidad del negocio y el proyecto deja de ser una decisión de TI para volverse una decisión de dirección.
El día que el sistema falla ya es tarde para planear la modernización. El momento correcto es mientras todavía funciona.
Brenda Infinite® · INCEPTIOLas cuatro rutas, en resumen
La conversación suele plantearse como un sí o no a reescribir todo. En la práctica hay cuatro caminos con costos, tiempos y riesgos muy distintos, y la mayoría de los proyectos combina más de uno.
| Ruta | En qué consiste | Cuándo es la respuesta correcta |
|---|---|---|
| Rehospedar | Mover el sistema tal cual a infraestructura moderna o a la nube, sin tocar el código | El software funciona bien; el problema es el hardware o el centro de datos |
| Encapsular | Dejar el sistema intacto y exponerlo mediante APIs para que otros sistemas puedan usarlo | La lógica sirve, pero el sistema está aislado y no se comunica con nada |
| Refactorizar | Reescribir por partes, módulo por módulo, conservando la lógica de negocio validada | El sistema es correcto en el fondo pero imposible de mantener |
| Reconstruir | Construir un sistema nuevo y migrar datos y procesos por etapas | La lógica ya no refleja cómo opera la empresa hoy |
Cada ruta tiene criterios de elección, riesgos y señales de alerta propias. El desglose completo está en la guía migrar, reescribir o encapsular.
Un proveedor que responde a todo con "hay que rehacerlo" debería explicar por qué encapsular no alcanza. Uno que responde a todo con "solo hay que moverlo a la nube" probablemente está resolviendo el síntoma: un sistema imposible de mantener sigue siéndolo en la nube, y ahora con renta mensual.
Cómo elegir la ruta correcta
El criterio no es la edad del sistema ni el lenguaje en que está escrito. Son tres preguntas sobre el negocio, no sobre la tecnología.
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿La lógica del sistema todavía refleja cómo opera la empresa? | Rehospedar, encapsular o refactorizar | Reconstruir: conservar lógica obsoleta sale más caro |
| ¿El problema principal es que no se comunica con otros sistemas? | Encapsular con APIs, que es lo más rápido y barato | Depende de las otras dos |
| ¿Se puede modificar sin miedo a romper algo? | Rehospedar alcanza | Refactorizar por módulos |
La pregunta de los treinta segundos
Si mañana tuviera que agregar un campo al sistema y ponerlo en producción, ¿cuánto tardaría y quién tendría que hacerlo? Si la respuesta es "semanas" o "solo fulano puede", el problema no es el sistema: es que la empresa perdió el control sobre su propia operación.
Cómo se hace sin detener la operación
Este es el punto que decide si el proyecto se aprueba o se pospone un año más. La respuesta es sencilla de explicar: nunca hay un momento en que el sistema viejo se apague y el nuevo arranque. Los dos conviven mientras dura la transición.
- Fase 1 · Levantamiento y mapa. Se documenta qué hace realmente el sistema, no lo que dice el manual. Se identifican los procesos que dependen de él y quién los ejecuta. Dura entre dos y cuatro semanas y ya entrega valor por sí sola.
- Fase 2 · Encapsulado. Se expone el sistema actual mediante APIs para que lo nuevo pueda leer y escribir sin tocar el código heredado. A partir de aquí se puede construir alrededor sin riesgo.
- Fase 3 · Primer módulo. Se elige el proceso que más duele y menos riesgo tiene, y se construye su reemplazo. Corre en paralelo con el sistema viejo durante algunas semanas, comparando resultados.
- Fase 4 · Corte controlado. Cuando el módulo nuevo demuestra que da los mismos resultados, se traslada la operación. Si algo falla, se regresa al viejo el mismo día, porque sigue ahí.
- Fase 5 · Repetición. Se repite módulo por módulo, en orden de dolor. El sistema viejo se va vaciando hasta que queda sin uso y se apaga sin ceremonia.
Lo que hace posible este enfoque es que cada fase se entrega funcionando y se puede detener ahí. Si a la mitad del proyecto cambian las prioridades o el presupuesto, lo construido hasta ese punto ya está en producción y sirve. Eso es lo contrario de un proyecto de dos años que solo tiene valor el día que termina.
Cómo se construye el presupuesto
La pregunta "¿cuánto cuesta modernizar mi sistema?" no tiene respuesta antes del levantamiento, y cualquiera que dé una cifra sin haberlo hecho está adivinando. Lo que sí se puede explicar de antemano es qué variables mueven el número: la cantidad de procesos que abarca el sistema, la calidad de la documentación existente, el volumen y la limpieza de los datos, el número de integraciones que deben seguir funcionando y la ruta elegida.
Un proyecto por fases se cotiza fase por fase. El levantamiento se cotiza cerrado, porque su alcance es conocido; a partir de su resultado se cotiza el resto con números reales en lugar de estimaciones. El desglose de modelos de costo y el cálculo de retorno están en la guía de cuánto cuesta modernizar un sistema legacy.
Cuándo no conviene modernizar todavía
Hay tres situaciones en las que lo responsable es esperar, aunque un proveedor esté dispuesto a cobrar el proyecto:
- El proceso está por rediseñarse. Si la operación va a cambiar en los próximos meses, modernizar ahora congela en tecnología nueva una forma de trabajar que está por desaparecer. Primero se define el proceso, después se automatiza.
- No hay quien reciba el sistema. Un sistema moderno necesita alguien que lo administre. Si no hay equipo interno ni contrato de soporte, en dos años el problema será idéntico con otra tecnología.
- Lo que duele no es el sistema. A veces el dolor viene de datos sucios, de un proceso mal definido o de falta de capacitación, y el sistema es solo donde se manifiesta. Cambiar la herramienta no arregla ninguna de esas tres cosas.
Descartar el proyecto por alguna de estas razones también es un resultado válido de un diagnóstico. Es preferible a arrancar y descubrirlo a la mitad.
Cómo empezar esta semana
No hace falta una consultoría de tres meses para tener claridad. Con un par de horas de trabajo interno se avanza más de lo que parece:
- Cuente las señales. De las siete de arriba, marque las que aplican hoy. Ese número ordena la urgencia mejor que cualquier opinión.
- Ponga nombre al riesgo de continuidad. ¿Quién es la persona de la que depende el sistema? Escribirlo cambia la conversación con dirección.
- Liste los procesos que viven en hojas de cálculo. Son los que el sistema no cubre, y casi siempre son el mejor primer módulo a construir.
- Sume el costo anual de sostenerlo. Horas de mantenimiento, doble captura y proyectos detenidos. Es el número que justifica el presupuesto.
- Elija un solo proceso para empezar. El que más duele y menos riesgo tiene. Un proyecto que arranca con un módulo se aprueba; uno que arranca con toda la operación se pospone.
Lo que salga de ese ejercicio no es un plan de proyecto, pero convierte cualquier conversación con un proveedor en algo mucho más productivo. Y si al terminar descubre que el sistema todavía no es un riesgo, esa también es información valiosa: significa que el presupuesto rinde más en otro lado este año.
Preguntas frecuentes
Es el proceso de actualizar un sistema empresarial existente para que vuelva a ser mantenible, integrable y seguro, sin perder la lógica de negocio que ya funciona. No siempre implica reescribirlo: existen cuatro rutas —rehospedar, encapsular con APIs, refactorizar por módulos o reconstruir— y la elección depende de si la lógica del sistema todavía refleja cómo opera la empresa.
Con siete señales: que una sola persona lo entienda, que el fabricante ya no lo soporte, que no se pueda integrar con otros sistemas, que cada cambio tarde meses, que corra sobre infraestructura sin reemplazo, que la operación lo evite armando hojas de cálculo paralelas, y que cumplir un requisito nuevo se convierta en un proyecto. Con dos señales conviene planear; con cuatro o más ya es un riesgo de continuidad del negocio.
Sí, y es el enfoque estándar cuando el proyecto se plantea por fases. Nunca hay un momento en que el sistema viejo se apague y el nuevo arranque: los dos conviven. Cada módulo nuevo corre en paralelo con el anterior durante algunas semanas comparando resultados, y solo cuando demuestra que entrega lo mismo se traslada la operación.
Migrar a la nube sin cambiar el software se llama rehospedar y es una de las cuatro rutas de modernización, no un sinónimo. Resuelve el hardware obsoleto y la continuidad física, pero no cambia nada del código: un sistema imposible de mantener sigue siéndolo en la nube, ahora con renta mensual.
Depende del alcance, pero la primera fase —levantamiento y mapa del sistema— toma entre dos y cuatro semanas y ya entrega valor por sí sola. A partir de ahí cada módulo se entrega funcionando y el proyecto se puede detener en cualquier fase sin perder lo construido.
Se migran por etapas, no de golpe, y se depuran antes de migrar y no durante. Los datos sucios son una de las cinco variables que más encarecen un proyecto: años de registros duplicados o inconsistentes se convierten en semanas de trabajo si se descubren a la mitad de la migración.
En tres situaciones: cuando el proceso está por rediseñarse, cuando no hay equipo ni contrato de soporte que reciba el sistema nuevo, y cuando lo que duele no es el sistema sino datos sucios, un proceso mal definido o falta de capacitación.
Sí. Todo desarrollo es propiedad del cliente y se entrega con el código fuente. No hay dependencia obligatoria del proveedor para mantenerlo ni cobro por liberarlo.
¿Cuántas de las siete señales aplican a su sistema?
En el diagnóstico revisamos su sistema actual, identificamos la ruta que corresponde y entregamos el plan por fases con el primer módulo definido. Si la conclusión es que todavía no conviene modernizar, esa también es una respuesta válida y se la damos igual.
Modernización de aplicaciones empresariales: cuándo hacerla, cómo y cuánto cuesta
Su sistema no se cae. Ese es justamente el problema: mientras siga funcionando, nadie aprueba el proyecto. Las siete señales que convierten un sistema viejo en un riesgo de negocio, y el marco completo para decidir qué hacer con él.
Lectura de 11 minutos
En esta guía
Respuesta corta
Modernizar una aplicación empresarial no es reescribirla de golpe. Es elegir entre cuatro rutas —rehospedar, encapsular con APIs, refactorizar por módulos o reconstruir— y avanzar por fases, con el sistema actual corriendo en paralelo hasta que cada módulo nuevo demuestra que funciona. Un proyecto bien planteado no detiene la operación un solo día. Lo que sí se detiene, cuando no se hace nada, es la capacidad de la empresa para cambiar.
Lo que cuesta sostener lo que ya funciona
Hay una pregunta que casi nunca aparece en un reporte de TI: ¿cuánto cuesta al año mantener vivo el sistema que la empresa lleva usando desde hace una década?
No hablamos de la licencia, que suele estar amortizada o ni siquiera existir. Hablamos de las horas del equipo resolviendo lo mismo cada mes. De los tres procesos que se sostienen en hojas de cálculo porque el sistema no los cubre. De la integración que lleva dos años pospuesta porque nadie quiere tocar ese código. Y del hecho incómodo de que, probablemente, solo una persona entiende cómo funciona realmente.
Eso es deuda técnica, y su característica más engañosa es que no se paga de golpe: se paga todos los meses, en partidas que nadie suma porque están repartidas entre nómina, tiempo extra y proyectos que no avanzan.
La cuenta que nadie hace
Sume tres números del último año: horas del equipo dedicadas a mantener o parchar el sistema, horas de operación dedicadas a capturar dos veces lo que el sistema no comunica, y proyectos que se cancelaron porque "el sistema no lo permite". Ese total es el costo real de no modernizar, y casi siempre supera lo que costaría hacerlo.
La razón por la que el proyecto no arranca es siempre la misma, y es perfectamente razonable: modernizar suena a detener la operación. Nadie quiere ser quien paró la planta. Pero esa percepción viene de una forma de hacer las cosas que ya no es la única disponible.
Siete señales de que ya es un riesgo
Un sistema viejo no es necesariamente un problema. Un sistema viejo que cumple estas condiciones sí lo es:
- Una sola persona lo entiende. Si esa persona renuncia, se enferma o se jubila, la empresa se queda sin capacidad de modificar su propia operación. Es el riesgo más grande y el que menos aparece en los reportes.
- El fabricante ya no lo soporta. Sin parches de seguridad, cada mes que pasa la superficie de riesgo crece. En sistemas con datos de clientes o información fiscal, esto deja de ser un tema técnico.
- No se puede integrar con nada. Cuando la única forma de mover un dato entre dos sistemas es que alguien lo capture a mano, el sistema dejó de ser una herramienta y se volvió un cuello de botella.
- Cada cambio tarda meses. Si una modificación menor requiere un proyecto, la empresa perdió la capacidad de responder al mercado a la velocidad a la que el mercado se mueve.
- Corre sobre infraestructura que ya no se fabrica. Servidores físicos sin reemplazo, sistemas operativos fuera de ciclo, bases de datos en versiones sin soporte.
- La operación lo evita. Cuando la gente arma sus propias hojas de cálculo en paralelo, no es indisciplina: es la señal de que el sistema ya no resuelve lo que la operación necesita.
- Cumplir con un requisito nuevo es un proyecto. Un cambio fiscal, una certificación o un requisito de un cliente grande no deberían poner en crisis a todo el departamento.
Con dos de estas señales conviene planear. Con cuatro o más, el sistema ya es un riesgo de continuidad del negocio y el proyecto deja de ser una decisión de TI para volverse una decisión de dirección.
El día que el sistema falla ya es tarde para planear la modernización. El momento correcto es mientras todavía funciona.
Brenda Infinite® · INCEPTIOLas cuatro rutas, en resumen
La conversación suele plantearse como un sí o no a reescribir todo. En la práctica hay cuatro caminos con costos, tiempos y riesgos muy distintos, y la mayoría de los proyectos combina más de uno.
| Ruta | En qué consiste | Cuándo es la respuesta correcta |
|---|---|---|
| Rehospedar | Mover el sistema tal cual a infraestructura moderna o a la nube, sin tocar el código | El software funciona bien; el problema es el hardware o el centro de datos |
| Encapsular | Dejar el sistema intacto y exponerlo mediante APIs para que otros sistemas puedan usarlo | La lógica sirve, pero el sistema está aislado y no se comunica con nada |
| Refactorizar | Reescribir por partes, módulo por módulo, conservando la lógica de negocio validada | El sistema es correcto en el fondo pero imposible de mantener |
| Reconstruir | Construir un sistema nuevo y migrar datos y procesos por etapas | La lógica ya no refleja cómo opera la empresa hoy |
Cada ruta tiene criterios de elección, riesgos y señales de alerta propias. El desglose completo está en la guía migrar, reescribir o encapsular.
Un proveedor que responde a todo con "hay que rehacerlo" debería explicar por qué encapsular no alcanza. Uno que responde a todo con "solo hay que moverlo a la nube" probablemente está resolviendo el síntoma: un sistema imposible de mantener sigue siéndolo en la nube, y ahora con renta mensual.
Cómo elegir la ruta correcta
El criterio no es la edad del sistema ni el lenguaje en que está escrito. Son tres preguntas sobre el negocio, no sobre la tecnología.
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿La lógica del sistema todavía refleja cómo opera la empresa? | Rehospedar, encapsular o refactorizar | Reconstruir: conservar lógica obsoleta sale más caro |
| ¿El problema principal es que no se comunica con otros sistemas? | Encapsular con APIs, que es lo más rápido y barato | Depende de las otras dos |
| ¿Se puede modificar sin miedo a romper algo? | Rehospedar alcanza | Refactorizar por módulos |
La pregunta de los treinta segundos
Si mañana tuviera que agregar un campo al sistema y ponerlo en producción, ¿cuánto tardaría y quién tendría que hacerlo? Si la respuesta es "semanas" o "solo fulano puede", el problema no es el sistema: es que la empresa perdió el control sobre su propia operación.
Cómo se hace sin detener la operación
Este es el punto que decide si el proyecto se aprueba o se pospone un año más. La respuesta es sencilla de explicar: nunca hay un momento en que el sistema viejo se apague y el nuevo arranque. Los dos conviven mientras dura la transición.
- Fase 1 · Levantamiento y mapa. Se documenta qué hace realmente el sistema, no lo que dice el manual. Se identifican los procesos que dependen de él y quién los ejecuta. Dura entre dos y cuatro semanas y ya entrega valor por sí sola.
- Fase 2 · Encapsulado. Se expone el sistema actual mediante APIs para que lo nuevo pueda leer y escribir sin tocar el código heredado. A partir de aquí se puede construir alrededor sin riesgo.
- Fase 3 · Primer módulo. Se elige el proceso que más duele y menos riesgo tiene, y se construye su reemplazo. Corre en paralelo con el sistema viejo durante algunas semanas, comparando resultados.
- Fase 4 · Corte controlado. Cuando el módulo nuevo demuestra que da los mismos resultados, se traslada la operación. Si algo falla, se regresa al viejo el mismo día, porque sigue ahí.
- Fase 5 · Repetición. Se repite módulo por módulo, en orden de dolor. El sistema viejo se va vaciando hasta que queda sin uso y se apaga sin ceremonia.
Lo que hace posible este enfoque es que cada fase se entrega funcionando y se puede detener ahí. Si a la mitad del proyecto cambian las prioridades o el presupuesto, lo construido hasta ese punto ya está en producción y sirve. Eso es lo contrario de un proyecto de dos años que solo tiene valor el día que termina.
Cómo se construye el presupuesto
La pregunta "¿cuánto cuesta modernizar mi sistema?" no tiene respuesta antes del levantamiento, y cualquiera que dé una cifra sin haberlo hecho está adivinando. Lo que sí se puede explicar de antemano es qué variables mueven el número: la cantidad de procesos que abarca el sistema, la calidad de la documentación existente, el volumen y la limpieza de los datos, el número de integraciones que deben seguir funcionando y la ruta elegida.
Un proyecto por fases se cotiza fase por fase. El levantamiento se cotiza cerrado, porque su alcance es conocido; a partir de su resultado se cotiza el resto con números reales en lugar de estimaciones. El desglose de modelos de costo y el cálculo de retorno están en la guía de cuánto cuesta modernizar un sistema legacy.
Cuándo no conviene modernizar todavía
Hay tres situaciones en las que lo responsable es esperar, aunque un proveedor esté dispuesto a cobrar el proyecto:
- El proceso está por rediseñarse. Si la operación va a cambiar en los próximos meses, modernizar ahora congela en tecnología nueva una forma de trabajar que está por desaparecer. Primero se define el proceso, después se automatiza.
- No hay quien reciba el sistema. Un sistema moderno necesita alguien que lo administre. Si no hay equipo interno ni contrato de soporte, en dos años el problema será idéntico con otra tecnología.
- Lo que duele no es el sistema. A veces el dolor viene de datos sucios, de un proceso mal definido o de falta de capacitación, y el sistema es solo donde se manifiesta. Cambiar la herramienta no arregla ninguna de esas tres cosas.
Descartar el proyecto por alguna de estas razones también es un resultado válido de un diagnóstico. Es preferible a arrancar y descubrirlo a la mitad.
Cómo empezar esta semana
No hace falta una consultoría de tres meses para tener claridad. Con un par de horas de trabajo interno se avanza más de lo que parece:
- Cuente las señales. De las siete de arriba, marque las que aplican hoy. Ese número ordena la urgencia mejor que cualquier opinión.
- Ponga nombre al riesgo de continuidad. ¿Quién es la persona de la que depende el sistema? Escribirlo cambia la conversación con dirección.
- Liste los procesos que viven en hojas de cálculo. Son los que el sistema no cubre, y casi siempre son el mejor primer módulo a construir.
- Sume el costo anual de sostenerlo. Horas de mantenimiento, doble captura y proyectos detenidos. Es el número que justifica el presupuesto.
- Elija un solo proceso para empezar. El que más duele y menos riesgo tiene. Un proyecto que arranca con un módulo se aprueba; uno que arranca con toda la operación se pospone.
Lo que salga de ese ejercicio no es un plan de proyecto, pero convierte cualquier conversación con un proveedor en algo mucho más productivo. Y si al terminar descubre que el sistema todavía no es un riesgo, esa también es información valiosa: significa que el presupuesto rinde más en otro lado este año.
Preguntas frecuentes
Es el proceso de actualizar un sistema empresarial existente para que vuelva a ser mantenible, integrable y seguro, sin perder la lógica de negocio que ya funciona. No siempre implica reescribirlo: existen cuatro rutas —rehospedar, encapsular con APIs, refactorizar por módulos o reconstruir— y la elección depende de si la lógica del sistema todavía refleja cómo opera la empresa.
Con siete señales: que una sola persona lo entienda, que el fabricante ya no lo soporte, que no se pueda integrar con otros sistemas, que cada cambio tarde meses, que corra sobre infraestructura sin reemplazo, que la operación lo evite armando hojas de cálculo paralelas, y que cumplir un requisito nuevo se convierta en un proyecto. Con dos señales conviene planear; con cuatro o más ya es un riesgo de continuidad del negocio.
Sí, y es el enfoque estándar cuando el proyecto se plantea por fases. Nunca hay un momento en que el sistema viejo se apague y el nuevo arranque: los dos conviven. Cada módulo nuevo corre en paralelo con el anterior durante algunas semanas comparando resultados, y solo cuando demuestra que entrega lo mismo se traslada la operación.
Migrar a la nube sin cambiar el software se llama rehospedar y es una de las cuatro rutas de modernización, no un sinónimo. Resuelve el hardware obsoleto y la continuidad física, pero no cambia nada del código: un sistema imposible de mantener sigue siéndolo en la nube, ahora con renta mensual.
Depende del alcance, pero la primera fase —levantamiento y mapa del sistema— toma entre dos y cuatro semanas y ya entrega valor por sí sola. A partir de ahí cada módulo se entrega funcionando y el proyecto se puede detener en cualquier fase sin perder lo construido.
Se migran por etapas, no de golpe, y se depuran antes de migrar y no durante. Los datos sucios son una de las cinco variables que más encarecen un proyecto: años de registros duplicados o inconsistentes se convierten en semanas de trabajo si se descubren a la mitad de la migración.
En tres situaciones: cuando el proceso está por rediseñarse, cuando no hay equipo ni contrato de soporte que reciba el sistema nuevo, y cuando lo que duele no es el sistema sino datos sucios, un proceso mal definido o falta de capacitación.
Sí. Todo desarrollo es propiedad del cliente y se entrega con el código fuente. No hay dependencia obligatoria del proveedor para mantenerlo ni cobro por liberarlo.
¿Cuántas de las siete señales aplican a su sistema?
En el diagnóstico revisamos su sistema actual, identificamos la ruta que corresponde y entregamos el plan por fases con el primer módulo definido. Si la conclusión es que todavía no conviene modernizar, esa también es una respuesta válida y se la damos igual.