Congelar el desarrollo es el pacto equivocado

Congelar el desarrollo facilita la gestión de una migración a costa de complicar el negocio. El proveedor obtiene un árbol de código estable, mientras los equipos de producto ponen trabajo comercial, cambios normativos, correcciones y mejoras operativas en cola detrás de una fecha arbitraria. El acuerdo parece ordenado en un plan y puede seguir siendo temerario en producción.

He visto paradas anunciadas como una precaución de dos semanas que se alargaron porque falló una conciliación, un proceso batch excedió su ventana o nadie confiaba en la reversión. El coste no se limita a desarrolladores parados. El trabajo sigue llegando y acaba en ramas laterales, hojas de cálculo, operaciones manuales y promesas a clientes. Una migración más segura elimina el cambio decisivo. Traslada comportamiento acotado módulo a módulo, demuestra paridad con tráfico real y deja al sistema antiguo atendiendo todo lo que aún no se ha movido.

Los proveedores piden una congelación porque simplifica su comparación

Un proveedor pide congelar el desarrollo para impedir que el sistema origen cambie mientras construye y prueba el sustituto. Si el código, el esquema, la planificación de tareas y las interfaces permanecen fijos, puede comparar una referencia estática con una versión candidata. Resulta más fácil controlar el alcance, las pruebas envejecen despacio y no se puede atribuir cada defecto tardío a un objetivo móvil.

La petición tiene sentido dentro de una entrega de golpe único. Un equipo copia el sistema, lo interpreta, lo reconstruye, ejecuta pruebas de aceptación y cambia a todos los usuarios en una fecha. Cada cambio productivo posterior a la copia crea otra diferencia que descubrir y reproducir. El equipo de migración trata entonces el desarrollo normal como contaminación.

Lo incómodo es que el modelo crea la condición que supuestamente exige la parada. Cuando el sustituto debe igualar todo el sistema a la vez, un cambio en cualquier punto afecta a la comparación final. Si la unidad migrada es un módulo de extractos o una ruta de precios, un cambio en una exportación de nóminas ajena no debería alterar su corte. Las paradas amplias suelen revelar que el proveedor no tiene una frontera fiable entre lo que se mueve y lo que permanece.

Hay controles breves legítimos. Un cambio de base de datos puede requerir unos minutos sin escrituras. Una ventana de lanzamiento puede detener despliegues una tarde. Una transición de esquema puede prohibir un cambio destructivo hasta que ambas versiones lo entiendan. Son controles operativos dirigidos, con responsable, condición de inicio y salida probada. Llamar igual a una prohibición de varias semanas oculta una transferencia de riesgo mucho mayor.

Pida al proveedor que nombre el artefacto exacto que debe quedar estable. ¿Es la forma de una tabla, un contrato de interfaz, unas salidas batch o cada línea del repositorio? Pregunte qué comparación falla si cambia. Una respuesta precisa descubre una dependencia manejable. «El proyecto necesita estabilidad» descubre un método que no absorbe el movimiento normal del negocio.

El negocio paga por trabajo que solo espera

El coste visible es el trabajo acumulado durante la parada. El mayor coste es coordinar su conservación, rebase, nueva prueba y publicación después de migrar. Fuera del repositorio nada dejó de cambiar. Entran normas fiscales, los socios cambian archivos, los clientes encuentran defectos, seguridad fija plazos y operaciones descubre excepciones.

Finanzas debe valorar resultados retrasados y trabajo de recuperación, no salarios durante el periodo. Un registro útil tiene cuatro columnas: cambio bloqueado, fecha de entrega normal, consecuencia del retraso y esfuerzo de conciliación posterior. Exprese consecuencias como facturación perdida, casos manuales diarios, exposición contractual o una promesa comercial en riesgo. Evite precisión inventada. Un intervalo con responsable es más honesto que un total ficticio.

La cola también tiene costes no lineales. Dos cambios sobre la misma función antigua pueden fusionarse bien por separado y chocar cuando el sustituto reorganiza ese comportamiento. Un parche de esquema para la base heredada quizá no tenga lugar directo en el modelo nuevo. Las pruebas anteriores pueden dejar de valer cuando aterrizan juntas diez entregas retenidas. El negocio no recupera sin más el ritmo anterior al día siguiente del corte.

También aparece trabajo oculto antes de parar. Los equipos apresuran cambios dudosos para entrar en la última entrega. La revisión empeora porque todos quieren cruzar la barrera. Operaciones crea procedimientos manuales para lo que quedó fuera. Producto divide funciones alrededor de la restricción y genera estados intermedios que nadie elegiría. Son costes de migración aunque el contrato del proveedor los excluya.

En los comités hago una pregunta seca: si aparece un defecto productivo, ¿quién puede cambiar el sistema antiguo y quién reproduce la corrección en el sustituto? «Ya decidiremos» no sirve. Hace falta un camino escrito para urgencias con autoridad, plazo, pruebas de regresión y traslado equivalente al código nuevo. Sin él, la parada es una apuesta por el buen comportamiento de producción.

Congelar traslada el riesgo en vez de reducirlo

Una parada amplia reduce la deriva para migración, pero eleva el riesgo operativo, comercial y de lanzamiento del resto. El riesgo se ha movido, no ha desaparecido. Por eso un panel verde puede convivir con una pila creciente de cambios aplazados inseguros.

El primer riesgo trasladado es la exposición productiva. Un defecto o vulnerabilidad que recibiría una entrega ordinaria necesita ahora una excepción. Las excepciones se vuelven políticas porque parecen amenazar la fecha. Se empieza a comparar la imagen de perturbar el programa con el efecto real de dejar el fallo.

El segundo es la concentración. Al levantar la parada, la organización publica la migración y una cola comprimida casi juntas. Aunque cada cambio pase sus pruebas, hay poca evidencia productiva de su interacción. Quien responde a incidentes afronta arquitectura, despliegue y cambios de producto nuevos a la vez. Es el peor momento para volver ambigua la causa.

El tercero es la pérdida de conocimiento. Quien terminó un cambio antes puede estar en otro trabajo cuando salga. La analista que entendía una excepción puede olvidar el borde. Una rama conserva código, pero no todas las conversaciones que lo hicieron correcto.

Mida la duración como exposición. Cuente desde la última entrega normal hasta que vuelvan las entregas normales, no solo las fechas rotuladas como congelación. Incluya extensiones de estabilización y vaciado de la cola. Observe además:

• correcciones productivas esperando excepción;
• cambios fuera de la rama principal;
• procedimientos manuales creados por la restricción;
• interfaces ascendentes cambiadas durante la parada;
• entregas acumuladas para después del corte.

Si estos valores suben mientras migración sigue verde, el gobierno mide la comodidad del proveedor, no el riesgo empresarial.

Las fronteras de módulo permiten cambios independientes

El corte por módulos elimina una parada global al dar a cada porción su contrato, prueba de paridad, regla de enrutamiento y reversión. «Módulo» no tiene que ser un paquete limpio del código antiguo. Es una capacidad de negocio acotada cuyas entradas, salidas, propiedad de datos y efectos pueden observarse.

Las primeras porciones adecuadas tienen una entrada estrecha y consecuencias conciliables. Generar documentos, una vista de cuenta de lectura, calcular impuestos o una exportación batch pueden valer. La pantalla sencilla apoyada en catorce tablas compartidas no suele valer. Elija por frontera de comportamiento, no por carpetas heredadas.

Escriba el contrato antes de reescribir. Registre entradas, salidas, errores, tiempos, propiedad y efectos externos. Incluya el comportamiento feo del que otros dependen. Una fecha vacía convertida en 1900-01-01 parece un error, pero cambiarla durante la migración puede romper una comparación posterior. Modernícela después mediante una decisión explícita.

Un inventario mínimo puede ser:

slice: invoice-pdf
entry: POST /internal/invoices/{id}/render
reads: invoice, customer, tax_snapshot
writes: rendered_document
side_effects: object_store.put, audit.append
parity: status, content_hash, audit_code
route_key: tenant_id
rollback: route tenant to legacy renderer
owner: billing-platform

Este artefacto evita declarar equivalencia porque la salida principal parece correcta mientras una fila de auditoría o un código de reintento difiere. También ofrece una acción concreta de reversión. Si una porción no nombra clave de ruta o propietario de estado, no está lista.

El mapa debe exponer llamadas que cruzan la frontera. Siga una solicitud normal y un fallo desde la entrada hasta el último efecto. Si el renderizador pide al legado impuestos, preferencias, número de documento y auditoría, «renderizador» solo describe la función visible. Conserve esas llamadas como dependencias explícitas o amplíe la porción. Fingir que son detalles prepara sorpresas.

Ordene por dirección de dependencias. Un módulo muy llamado puede crear pronto un contrato estable, pero solo con un impacto aceptable. Una capacidad periférica permite ensayar captura, comparación y vuelta con más seguridad. No hay orden universal. El mapa debe justificar qué viene después y qué dependencia elimina.

Distinga copia de datos y propiedad. Copiar clientes a Postgres no hace autoritativo al candidato. Nombre qué ruta crea, modifica y borra cada registro en cada estado. Se tolera duplicación temporal, pero no dos escritores que prometen cosas distintas sobre la misma factura. Esta tabla de estado ayuda más que un diagrama porque indica dónde corregir.

Las bases compartidas complican la frontera sin invalidarla. Coloque escrituras tras un propietario, replique mediante outbox o flujo de cambios, o empiece leyendo mientras el antiguo escribe. Evite dobles escrituras sin control. Dos componentes que confirman el mismo hecho acabarán en desacuerdo y la conciliación se volverá la fuente real.

La paridad se mide en comportamiento, no en código

Paridad conductual significa que el módulo nuevo produce un resultado equivalente aceptado para la misma entrada y contexto de efectos. La similitud línea a línea demuestra poco si cambian arquitectura, lenguaje, base y errores. Una reescritura limpia puede ser distinta y conservar el contrato que perciben usuarios y sistemas.

Construya un banco que reproduzca tráfico registrado en ambas implementaciones sin repetir efectos reales. Oculte o tokenice datos sensibles y aplique las reglas de retención y acceso de producción. Para campos no deterministas, compare valores normalizados. Las marcas temporales pueden aceptar una ventana, los identificadores una correspondencia y las colecciones desordenadas una ordenación.

El banco debe mostrar diferencias investigables, no una sola tasa:

{"slice":"invoice-pdf","case_id":"r_01842","legacy":{"status":200,"audit_code":"PDF_OK","content_hash":"8c31..."},"candidate":{"status":200,"audit_code":"PDF_OK","content_hash":"b711..."},"result":"mismatch","fields":["content_hash"]}

La diferencia puede ser metadato inocuo o una línea ausente. El banco no decide semántica, pero hace repetible el desacuerdo. Un responsable lo clasifica, añade una regla solo si se acepta y conserva la evidencia. Exclusiones como «ignorar formato» esconden totales rotos en documentos parecidos.

Ejecute tráfico en sombra antes de enrutar usuarios. La ruta antigua sigue autoritativa y produce efectos. El candidato recibe una copia segura y escribe propuestas en un destino aislado. Compare carga normal, cierres, reintentos, entradas inválidas y casos raros históricos. Las pruebas sintéticas importan, pero rara vez contienen combinaciones de veinte años.

La descripción Asset Capture de Martin Fowler señala algo omitido: migrar hacia atrás reduce riesgo si un activo adopta una condición que el sistema nuevo aún no trata. Coincido y definiría la unidad de reversión antes de la primera ruta real. Si el tráfico solo va hacia delante, se ha construido un big bang pequeño.

Corte una cohorte y mantenga viva la ruta antigua

El corte más seguro envía una cohorte pequeña e identificable al módulo nuevo mientras el legado sirve al resto. Use claves estables como inquilino, región, rango de cuentas o tipo de transacción. Porcentajes aleatorios son peligrosos si operaciones relacionadas caen en sistemas con estados distintos.

Empiece con una cohorte representativa para aprender y pequeña para recuperar a mano. Los usuarios internos valen solo si ejercen conducta real. Un cliente colaborador con datos raros puede enseñar más que cien cuentas internas. Documente la elección y lo que no cubre.

El cambio de ruta debe ser aburrido y reversible. Guarde configuración en control de versiones, exija aprobación y registre el valor anterior. Por ejemplo:

invoice_rendering:
  default: legacy
  routes:
    - tenants: [t_104, t_219]
      target: candidate
  rollback_on:
    mismatch_rate: 0.005
    candidate_5xx: 3

Los umbrales deben salir de tolerancia y volumen; los números solo muestran una regla ejecutable. Con poco volumen, una factura errónea puede parar. Una lectura masiva puede usar tasa y cantidad. Escríbalo antes para no negociar con un gráfico malo durante un incidente.

Observe resultados de negocio y salud técnica. Latencia, errores y CPU pueden estar normales mientras se registra una cuenta contable equivocada. Concilie efectos contractuales, revise excepciones y pregunte por casos manuales. Mantenga la cohorte hasta atravesar ciclos relevantes como facturación o procesos nocturnos.

Revertir envía trabajo nuevo al legado y quizá devuelva estado tomado por el candidato. Por eso la propiedad figura en el inventario. Defina si se reproducen eventos, se restaura una copia, se compensa o se dejan registros terminados mientras el legado toma nuevos. Un interruptor sin plan de estado es media reversión.

El desarrollo normal continúa con contratos explícitos

El producto puede avanzar durante la migración si ambos equipos gestionan contratos en vez de una copia implícita. Un cambio en un módulo no migrado sigue la entrega normal. Si toca una porción en marcha, actualiza contrato y casos de paridad y llega a ambas implementaciones hasta que la nueva sea autoritativa.

Hace falta una regla de entrada utilizable. Etiquete cada propuesta por porción y superficie contractual. El responsable decide: solo legado, ambas, solo candidato tras el corte o bloqueado porque altera el propio corte. La última opción debe ser rara y estrecha. Toda decisión tiene dueño y caducidad.

No mantenga una rama permanente para toda la reescritura. Integre pruebas contractuales y rutas en el flujo principal, con módulos candidatos desplegables aparte. Las ramas largas retrasan conflictos y crean el mismo precipicio de conciliación. Las banderas ocultan funciones incompletas, pero no sustituyen interfaces versionadas ni compatibilidad.

La base exige cuidado. Prefiera expandir y contraer: añada campo o tabla, enseñe ambas versiones, migre datos, cambie lectores y quite la forma antigua cuando nadie la use. Renombrados destructivos con versiones mezcladas crean presión artificial. La compatibilidad separa entrega continua de una barrera disfrazada de arquitectura.

Las versiones de interfaz necesitan retirada. Mantener consumidores antiguos y nuevos para siempre convierte el puente en infraestructura. Registre el último consumidor, su traslado y la evidencia para retirar. Pruebe ambas versiones mientras haya mezcla y borre compatibilidad solo cuando la telemetría confirme silencio.

La propiedad sigue a la autoridad. El equipo antiguo no debe atender comportamiento ya servido por el candidato, ni migración poseer indefinidamente software ya normal. Actualice catálogo, guardias, paneles, manuales y permisos junto con la ruta. De lo contrario, los incidentes rebotan entre equipos.

Producto también necesita visibilidad. Incluya el mapa en planificación para evitar conflictos y usar módulos trasladados. Es coordinación, no permiso de una oficina. La migración existe para que el negocio cambie, así que sus decisiones deben llegar al ritmo normal.

Las correcciones siguen la regla. Parchee la ruta autoritativa ya. Si la porción está en sombra o parcial, añada el caso al corpus y corrija también al candidato. La interrupción se convierte en evidencia. No retrase una corrección para conservar una referencia limpia; actualícela y deje que la automatización muestre el cambio.

El modelo cuesta. Se mantienen dos implementaciones por un tiempo, los routers necesitan dueño y cada porción conciliación. Compare ese coste visible con ramas ocultas, publicación concentrada y demora empresarial. La migración incremental paga control mientras trabaja. El big bang aplaza la factura al día más arriesgado.

La aprobación depende de evidencia por porción

Los directivos deben aprobar cada corte con evidencia de su contrato, no con un porcentaje global. «Ochenta por ciento migrado» no dice si el resto controla liquidación, autenticación o cierre. El progreso debe describir comportamiento productivo ya servido y riesgo aún antiguo.

El paquete puede ser corto. Identifica porción y cohorte, muestra paridad y excepciones, registra rendimiento, confirma efectos, nombra responsable de reversión y adjunta el ensayo. Seguridad y datos acompañan si hay información sensible.

Mida calidad, no solo volumen. Diez mil casos felices repetidos no compensan una devolución, reintento o cierre ausente. Agrupe resultados por comportamiento y estado y muestre grupos sin tráfico representativo. Así se ve la ausencia sin inventar confianza.

Registre diferencias aceptadas. Cada excepción necesita diferencia, razón, aprobador y caducidad. La migración acumula peligro cuando se normalizan silenciosamente diferencias hasta poner verde el panel. Algunas son mejoras, pero deben rastrearse hasta una decisión.

Separe preparación técnica y momento comercial. Un módulo correcto puede coincidir mal con cierre o pico estacional. Eso no justifica parar desarrollo ajeno. Manténgalo en sombra, recoja evidencia y enrute cuando negocio acepte.

La plataforma de CodeHero lee todo el árbol heredado en paralelo, moderniza la arquitectura y verifica comportamiento con tráfico productivo registrado. Las fronteras, rutas y reversiones siguen siendo decisiones operativas porque la automatización no posee el riesgo del cliente.

Exija demostrar una ruta inversa antes de ampliar. Una diapositiva no basta. Cambie la ruta, procese un caso conocido en el legado, concilie estado y muestre qué implementación lo atendió. Si el ensayo parece demasiado peligroso, el corte no está listo.

Retire el sistema antiguo solo cuando se hayan movido todas las rutas, el estado tenga hogar, los trabajos estén desactivados o sustituidos, los consumidores usen contratos admitidos y la reversión no requiera el runtime antiguo. Hasta entonces manténgalo parcheado, vigilado y recuperable. «Solo lectura» no vuelve inocuo un batch sin dueño.

Rechace la congelación y pida un mapa de corte

Rechazar una parada solo funciona si exige mejor control. Pida un mapa con cada porción, entrada, dueño de datos, método de paridad, clave de ruta, cohorte, dependencias y reversión. Puede cambiar al entender mejor el sistema, pero las celdas vacías deben seguir visibles.

Revise la secuencia. Las primeras porciones deben probar captura, conciliación y retorno sin empezar por el flujo más grave. Una procesión de pantallas fáciles puede aparentar progreso mientras todo el riesgo de escritura espera al final.

Vincule hitos comerciales a porciones productivas y evidencia aceptada. Pagar documentos, código generado o una fase de pruebas premia actividad que quizá nunca reciba tráfico real. Una cohorte productiva prueba encaje y capacidad operativa.

Quedarán pausas breves. Puede detener escrituras al transferir una tabla, despliegues al cambiar el router o una retirada incompatible. Nombre cada pausa y limítela a su superficie. El resto debe seguir publicando.

Un proveedor incapaz de dibujar el mapa quizá pueda reescribir, pero no explicar cómo evitar que el negocio espere. No acepte una barra «congelación» como control. Pregunte qué módulo va primero, qué evidencia lo hace seguro y cómo vuelve producción cuando esa evidencia falla.