# Modernización de Plataformas > Modernizar sistemas que funcionan pero que cuestan demasiado cambiar. Corte incremental, sin reescritura de golpe, entregado por un AI Pod. Fuente: https://www.koombea.com/es/capabilities/platform-modernization/ --- 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. | | Rehospedar | Replatformar | Extracción incremental | |---|---|---|---| | Qué pasa | El mismo sistema, infraestructura nueva | El mismo sistema, con servicios administrados por debajo | Sacar una pieza delimitada a la vez detrás de una interfaz que no cambia | | Qué arregla | El costo de hospedaje y el riesgo de hardware. Nada del código | La carga operativa, los parches, y algunos límites de escalamiento | El costo del cambio en sí, que es la razón por la que llegaste aquí | | Qué arriesga | Pagar tarifas de nube por una arquitectura que no las puede aprovechar | Real pero acotado. Normalmente es el primer movimiento correcto | Exige disciplina para no volverse un híbrido permanente | | Forma de la entrega | Un proyecto corto con un final claro | Una fase, medible contra una factura de hospedaje | Continua, con un sistema funcionando en cada paso | | Cuándo la recomendamos | Una salida de centro de datos con fecha límite y sin apetito de cambio | El sistema es sólido y el dolor es el costo operativo | Cada 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.