Solo una persona sabe manejarlo
El sistema funciona, pero todo el conocimiento está en la cabeza de alguien — y esa persona está por irse, jubilarse o ya se fue.
Construimos, modernizamos y damos soporte a aplicaciones críticas — desde la nueva plataforma en la nube hasta el sistema en VB6 que aún cierra la facturación cada mes.
Casi nadie llama pidiendo “ingeniería de software”. Llaman por uno de estos cuatro problemas.
El sistema funciona, pero todo el conocimiento está en la cabeza de alguien — y esa persona está por irse, jubilarse o ya se fue.
Un cambio pequeño toma semanas, exige probar todo a mano y aun así nadie duerme tranquilo el día de la puesta en producción.
La versión ya no recibe correcciones de seguridad, la auditoría empezó a señalarlo y la renovación del contrato pasó a ser tema de dirección.
El backlog crece más rápido que el equipo, y contratar y capacitar a alguien no lo resuelve en el plazo que el negocio necesita.
Cubren el ciclo completo de un sistema corporativo: nacer, evolucionar, envejecer y renacer sin dejar de funcionar.
01
Plataformas corporativas, aplicaciones web y productos digitales construidos para escalar — y para ser mantenidos por otro equipo después, si es el caso.
02
Del encapsulamiento por API a la reescritura completa, eligiendo el camino por el riesgo que la operación acepta correr — no por lo que es más divertido de programar.
03
Corrección, adaptación a cambios de negocio y evolución planificada, con el sistema bajo responsabilidad de quien conoce el código y el proceso.
04
Revisión de arquitectura, cobertura de pruebas y prácticas de TDD y DDD en código que nunca tuvo ninguna de las dos cosas.
El mercado habla de “modernización de sistemas legados” sin decir nunca de qué sistemas habla. Nosotros lo decimos: VB6, Oracle Forms, Delphi, .NET Framework antiguo, PHP sin framework, bases sin documentación y reglas de negocio que solo existen dentro del código.
Damos soporte a esos entornos mientras son modernizados. Nadie necesita apagar lo que corre la facturación para empezar a salir de ahí — y ninguna modernización comienza antes de que la operación esté cubierta.
Todos listan los cinco. Casi nadie dice cuándo cada uno es la elección correcta — y cuándo es un error caro. La decisión viene de la evaluación técnica, no de preferencia arquitectónica.
Rehost
Tiene sentido cuando el problema es el servidor, no el software: hardware al final de su vida, datacenter que se desactiva, costo de infraestructura alto.
Es un error cuando la molestia real es el código. Cambiar de lugar no arregla lo que duele.
Replatform
Tiene sentido para cambiar base de datos, sistema operativo o versión de runtime, ganando soporte y seguridad sin reescribir la regla de negocio.
Es un error cuando la arquitectura no sostiene el volumen que viene — posterga el problema uno o dos años.
Refactor
Tiene sentido cuando la regla de negocio es buena y el código es malo. Mejora estructura y pruebas preservando el comportamiento que la operación conoce.
Es un error sin cobertura de pruebas antes de empezar: refactorizar a ciegas es reescribir sin admitirlo.
Rebuild
Tiene sentido cuando el proceso de negocio cambió tanto que el sistema actual estorba más de lo que ayuda, o cuando la tecnología no tiene salida viable.
Es un error la mayoría de las veces en que se elige — suele ser una decisión emocional, y es el camino más largo y más caro.
Replace
Tiene sentido cuando lo que hace el sistema no es un diferencial competitivo y existe un producto de mercado que lo resuelve.
Es un error cuando la regla específica de su operación es justamente lo que sostiene el margen. Ahí la personalización del producto cuesta más que mantener el suyo.
En la práctica, casi todo proyecto combina más de un camino — encapsula una parte por API, refactoriza otra y sustituye la tercera. Lea también cuándo vale reescribir un sistema legado.
La mayoría de nuestros clientes usa Sistemas Senior, y buena parte de la ingeniería corporativa ocurre a su alrededor: personalizaciones, sistemas satélite, integraciones y automatizaciones que el ERP por sí solo no cubre.
El cuidado que hace la diferencia es construir eso sin inviabilizar la actualización de versión. Una personalización mal anclada convierte cada upgrade del ERP en un proyecto nuevo — y la cuenta llega algunos años después, siempre en el peor momento.
Cuando el tema pasa a ser indicadores en vez de procesos, el camino natural es nuestra consultoría de Business Intelligence: misma fuente de datos, mismo equipo.
La previsibilidad y la trazabilidad no vienen de la herramienta, vienen del rito. El nuestro combina agilidad en la ejecución con gobernanza en la rendición de cuentas.
Design Thinking y levantamiento de procesos al inicio, para que el software resuelva el problema correcto — y no solo lo que se pidió.
Ciclos con alcance cerrado y demostración al final de cada uno. El cliente corrige el rumbo cada dos semanas, no en la aceptación final.
Pruebas automatizadas y modelado orientado al dominio en la regla crítica, que es donde el error cuesta caro y el mantenimiento se paga.
Cronograma, riesgos y rendición de cuentas según los principios del PMI, con trazabilidad de punta a punta — lo que los sectores regulados exigen en auditoría.
Nuestro equipo reúne profesionales con certificaciones en metodologías ágiles y en gestión de proyectos, y los equipos son conducidos por consultores sénior — la misma seniority que sostiene la previsibilidad que exigen los entornos de misión crítica.
Transitamos con fluidez entre entornos antiguos y stacks modernos. No es una lista de currículum: es lo que permite sostener un sistema en VB6 y, al lado, construir la plataforma que lo va a sustituir.
Trabajamos con Microsoft Azure y AWS en los proyectos de migración y modernización, eligiendo la nube por lo que el cliente ya tiene y por lo que la operación exige — no por preferencia nuestra.
Proyecto entregado no es sistema resuelto. El soporte cubre lo que viene después, en tres niveles, con catálogo de servicios acordado y rito de gobernanza con informe periódico.
Incidentes, errores y comportamiento inesperado. Atención por ticket, con prioridad acordada en contrato.
Cambio de afuera hacia adentro: nueva regla fiscal, versión de ERP, integración que cambió de contrato, exigencia de auditoría.
Mejoras planificadas en backlog, priorizadas junto con el cliente dentro de las horas mensuales contratadas.
La elección depende de quién conduce el producto. Si la visión es suya y falta gente, asignamos. Si la entrega es nuestra de punta a punta, cerramos alcance.
SQUAD ASIGNADO
Escuadrones y profesionales sénior integrados a su operación, con rápida adaptación a su proceso y a su stack. La gestión del producto sigue siendo suya.
PROYECTO CERRADO
Para construcción o modernización con objetivo claro. Sale de una evaluación técnica con alcance, arquitectura y cronograma acordados.
SOPORTE MENSUAL
Correctivo, adaptativo y evolutivo con horas mensuales y gobernanza periódica, para sistemas que necesitan dueño después de la entrega.
Más de dos décadas de liderazgo en proyectos de misión crítica, en sectores que responden a auditoría: salud, sector público, financiero, agronegocio, industria, logística, retail e infraestructura.
Clientes nacionales y multinacionales
Horas de desarrollo de software e ingeniería de sistemas
Horas de consultoría e inteligencia de procesos
En la mayoría de los casos, de a poco. La reescritura desde cero es el camino más largo y más caro, y suele elegirse por cansancio con el sistema actual, no por análisis. Modernizar por partes — encapsulando lo que funciona por API y sustituyendo módulo a módulo — mantiene la operación en pie y permite detenerse a mitad de camino si cambia la prioridad. La evaluación técnica existe para responder eso con datos, no con opinión.
Sí, y así trabajamos. El sistema actual sigue con soporte mientras el nuevo se construye al lado, con ambos conviviendo hasta el cambio de cada parte. Ninguna modernización empieza antes de que el soporte de lo que está en producción esté cubierto.
Es el escenario más común que recibimos. El primer trabajo es reconstruir el entendimiento: leer el código, mapear las reglas que solo existen dentro de él, conversar con quien opera y documentar lo que se encuentre. Esa documentación queda con usted, incluso si el proyecto se detiene ahí.
Se puede, y muchas empresas serias aún dependen de eso. El riesgo no es que el sistema deje de funcionar de un día para otro — es la combinación de falta de correcciones de seguridad, escasez de profesionales y dependencia de una sola persona. Damos soporte a esos entornos con equipo propio y, en paralelo, diseñamos la salida al ritmo que la operación aguanta.
Depende del tamaño del sistema, de la calidad de lo que existe y del camino elegido entre los cinco — y la diferencia entre ellos es grande. Por eso empezamos con una evaluación técnica: convierte la pregunta en alcance, y el alcance en presupuesto.
En tres niveles: correctivo para incidentes, adaptativo para cambios externos (regla fiscal, versión de ERP, integración alterada) y evolutivo para mejoras planificadas. El catálogo de servicios y las prioridades se acuerdan en contrato, con informe periódico de gobernanza.
Sí. Buena parte de nuestra ingeniería ocurre alrededor del ERP — personalizaciones, sistemas satélite e integraciones — con atención especial a no inviabilizar la actualización de versión. Tenemos un largo historial en Sistemas Senior y actuamos también en otros entornos.
Con usted. El código fuente, la documentación y los artefactos del proyecto son del cliente, entregados en un repositorio bajo su control. Ninguna parte de la entrega depende de una herramienta propietaria nuestra para seguir funcionando.
PRIMER PASO
Analizamos el sistema que le está incomodando — arquitectura, dependencias, riesgos y el estado real del código — y entregamos un informe escrito con los caminos posibles, el esfuerzo de cada uno y nuestra recomendación. Usted decide qué hacer con él, con nosotros o sin nosotros.
Hablar con un consultor