Hablemos
Capacidad

El sistema funciona. Cambiarlo es el problema.

La modernización rara vez trata de tecnología que dejó de funcionar. Trata de un código donde cada cambio cuesta tres veces lo que debería.

El problema

Los sistemas que necesitan este trabajo normalmente no están rotos. Atienden clientes, sostienen ingresos, y no se pueden apagar. Lo que se rompió es la economía de cambiarlos: una funcionalidad de una semana toma seis, y nadie puede decir por qué con confianza.

No vendemos reescrituras de golpe. Una reescritura reemplaza un sistema que entiendes por uno que no, y te pide dejar de entregar valor durante un año mientras pasa. En vez de eso partimos el sistema en piezas que se pueden mover de forma independiente, y las movemos una por una detrás de una interfaz que no cambia.

Eso significa que tienes un sistema funcionando en cada paso, y que puedes parar cuando la economía ya sea suficientemente buena en vez de cuando el plan diga que terminaste.

  • Corte incremental, así hay un sistema funcionando en cada paso
  • Migraciones de base de datos sin caída de servicio donde el negocio no puede pausar
  • Interfaces heredadas preservadas hasta que el último consumidor se haya movido
  • Una medición de antes y después sobre el costo del cambio, no solo sobre el stack

Qué cubre esto

Extracción incremental

Mover una pieza delimitada a la vez, detrás de una interfaz que no cambia.

Corte sin caída de servicio

Migraciones diseñadas para que el negocio nunca deje de recibir órdenes.

Línea base del costo del cambio

Medir cuánto toma un cambio hoy, para que la mejora sea un hecho.

Red de seguridad contra regresiones

Pruebas escritas contra el comportamiento actual antes de mover nada.

Observabilidad primero

No puedes modernizar con seguridad lo que no puedes ver corriendo.

Salida de dependencias

Eliminar los cuellos de botella de un solo proveedor que te dejaron dependiente.

Tres formas de modernizar, y la que no vendemos.

La mayoría de las discusiones sobre modernización son en realidad discusiones sobre cuál de estas estás haciendo. Nombrarla primero ahorra meses.

DimensionRehospedarReplatformarExtracción incremental
Qué pasaEl mismo sistema, infraestructura nuevaEl mismo sistema, con servicios administrados por debajoSacar una pieza delimitada a la vez detrás de una interfaz que no cambia
Qué arreglaEl costo de hospedaje y el riesgo de hardware. Nada del códigoLa carga operativa, los parches, y algunos límites de escalamientoEl costo del cambio en sí, que es la razón por la que llegaste aquí
Qué arriesgaPagar tarifas de nube por una arquitectura que no las puede aprovecharReal pero acotado. Normalmente es el primer movimiento correctoExige disciplina para no volverse un híbrido permanente
Forma de la entregaUn proyecto corto con un final claroUna fase, medible contra una factura de hospedajeContinua, con un sistema funcionando en cada paso
Cuándo la recomendamosUna salida de centro de datos con fecha límite y sin apetito de cambioEl sistema es sólido y el dolor es el costo operativoCada cambio es caro y nadie puede decir por qué con confianza

No vendemos una reescritura. Reemplaza un sistema que entiendes por uno que no, y te pide dejar de entregar valor mientras pasa.

Antes de mover nada, documentamos lo que hay

La razón más común por la que una modernización se atasca es que nadie que quede en la empresa sabe qué hace el sistema. No la versión del diagrama de arquitectura. La versión donde un proceso nocturno que nadie reclama escribe en una columna de la que dependen tres reportes.

Por eso vendemos el trabajo de documentación como un proyecto pequeño en sí mismo, y con frecuencia es lo primero que hacemos para un cliente nuevo. Hacemos ingeniería inversa desde el código y desde la base de datos: arquitectura del sistema, estructura de módulos y servicios, modelos de datos y las reglas de negocio escondidas en ellos, los flujos de trabajo reales, y cada integración y dependencia que encontremos. La IA hace la lectura y el primer borrador, que es lo que lo hace pagable a la escala de un código de una década.

Después una persona valida todo. Esa parte no es opcional y no la vamos a describir como opcional, porque una descripción generada por IA y sin validar de un sistema del que dependen tus ingresos es un pasivo y no un entregable.

Recibes Markdown bajo control de versiones como fuente de verdad, diagramas para los conceptos que los necesitan, y PDFs para distribuir. Se dimensiona desde un inventario de tu código y no desde una cantidad de páginas, y sirve por sí solo incluso si nunca modernizas una línea.

  • Reconstruido desde el código y el esquema, no desde la memoria colectiva
  • La IA hace la lectura a escala, una persona valida cada afirmación antes de entregar
  • Markdown bajo control de versiones, diagramas y PDFs distribuibles
  • Dimensionado desde un inventario de tu código, después de un descubrimiento pagado corto
  • Sirve para transferencia de conocimiento, planeación de refactor, auditoría o una adquisición

Qué mueve la estimación

La modernización es lo más difícil de cotizar sin ver, y cualquier aliado que la cotice desde una conversación está cotizando un número que piensa revisar. Dimensionamos primero un descubrimiento pagado, y después cotizamos el trabajo por lo que el inventario de verdad encontró.

Lo que mueve el número rara vez es el tamaño del código. Es qué tan enredado está, y en concreto en cuántos lugares se comparte estado que no se debería compartir.

  • La cobertura de pruebas que ya tienes, que es la diferencia entre una red de seguridad y una reescritura
  • Cuántos consumidores dependen de que la interfaz se preserve, y si los puedes enumerar
  • Estado mutable compartido y acoplamiento en la base de datos entre las piezas que quieres separar
  • Si el negocio puede tolerar alguna ventana de caída de servicio
  • Comportamiento sin documentar que resulta ser estructural, que es la razón por la que la documentación va primero

Preguntas que vale la pena hacer

¿Cómo sabemos que funcionó?
Medimos cuánto toma un cambio representativo antes de mover nada, y lo volvemos a medir después. Eso es un hecho y no una sensación, y es la única métrica de modernización que se conecta con la razón por la que empezaste.
¿Pueden hacer esto mientras seguimos entregando funcionalidades?
Sí, y de eso se trata el enfoque incremental. Lo que pedimos es que decidas cómo se reparte la capacidad entre modernización y funcionalidades, de forma explícita, en el Priority Sync. Las dos salen de la misma capacidad visible, así que el intercambio queda sobre la mesa en vez de escondido.
Nuestro sistema corre sobre algo que ya no está de moda. ¿Es un problema?
No. Viejo no es lo mismo que malo, y un sistema estable con un stack aburrido a menudo es lo más barato que tienes. Modernizamos las partes donde la economía está genuinamente rota y dejamos el resto en paz.
¿Y la base de datos?
Normalmente la parte más difícil y la última en moverse. Diseñamos las migraciones para correr sin caída de servicio donde el negocio no puede pausar, lo que significa escritura doble y un corte verificado en vez de una ventana de mantenimiento y buena suerte.
¿Dónde va a correr después?
Se decide contigo y se registra. Con frecuencia aterrizamos las primeras fases en algo simple y barato de operar, y después nos movemos a AWS cuando la escala o un requisito de cumplimiento justifica la superficie adicional. No escogemos la opción más compleja para vernos serios.

Vincular clientes dejó de tomar meses

Payix llegó a nosotros después de que la calidad de su aliado anterior bajó, con una plataforma tan rígida que crear un ambiente nuevo para un cliente tomaba meses. El tiempo de arranque bajó drásticamente.

Tráenos el backlog.

En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.