Sunsetting

Retirar con alcance y obligaciones explícitos

En el Atlas, Sunsetting describe el proceso controlado de terminar disponibilidad, soporte u operación de una capacidad, interface, versión, recurso o sistema conforme a decisiones explícitas de lifecycle. Es el movimiento hacia su retirada. La definición sirve para separar trabajo de cierre de una simple acción de apagar infraestructura.

El alcance puede incluir detener nuevos usos, cesar escrituras, conservar lectura histórica, deshabilitar una API, archivar información o retirar una implementación. No todo caso requiere todas esas acciones ni el mismo orden. Preguntar exactamente qué termina evita que «retirar Payments» signifique cosas incompatibles para desarrollo, soporte y consumidores.

Retirar con seguridad suficiente exige evidencia y aceptación de riesgos según ese alcance. No existe una prueba genérica de ausencia de toda dependencia. Una decisión deliberada puede conservar parte del sistema y retirar otra, sin describir el resultado como fracaso.

Deprecation, removal y deletion

deprecation comunica que una capacidad deja de ser preferida y prepara el alejamiento de sus consumidores. Sunsetting organiza su retirada efectiva. Una secuencia Active → Deprecated → migración de consumidores → Sunset → Retired es una forma de razonar del Atlas, no un lifecycle universal.

Algunas capacidades permanecen deprecated durante mucho tiempo o indefinidamente. Un problema urgente de seguridad, una obligación legal o el cierre de un proveedor puede forzar retirada sin aviso prolongado. Esas posibilidades no hacen deseable ignorar consumidores, pero impiden definir la deprecation como condición necesaria de todo sunset.

Removal es una acción o resultado: quitar una implementación, contrato o recurso en un alcance concreto. Puede formar parte del proceso. Deletion elimina información u otros objetos; no equivale a cerrar operación o soporte. Archivar conserva información bajo otras condiciones de acceso, sin implicar mantener el servicio original.

End of Life, End of Support, End of Service, retirement y sunset tienen significados dependientes de la política de cada proveedor. No se impone una jerarquía universal. Si se termina soporte pero el software sigue funcionando, la continuidad y las correcciones disponibles necesitan entenderse por separado: pueden cambiar riesgo y responsabilidad aunque no cambie todavía el tráfico.

Ejemplo HTTP y límites de la señal

RFC 8594, sección 3, define Sunset como señal de que un recurso HTTP previsiblemente dejará de responder en una fecha. El timestamp es una indicación: no garantiza disponibilidad hasta ese instante ni desaparición exacta después. Tampoco especifica si después habrá errores, redirecciones o imposibilidad de conexión.

RFC 9745, sección 4, permite combinar información de deprecation y de sunset, conservando significados diferentes. HTTP ofrece un mecanismo concreto; no define todo el proceso sociotécnico de retirada ni obliga a otros protocolos a usar ese campo.

Un 404, 410, redirect o error explícito requiere decisión del contrato particular. Ninguna respuesta HTTP es obligatoria para todo sunset; una feature local o una biblioteca ni siquiera tiene ese canal. Un aviso de fecha tampoco sustituye el comportamiento que el proveedor se comprometa a ofrecer.

Qué termina y qué permanece

Puede retirarse un endpoint manteniendo otras operaciones, una versión manteniendo su reemplazo, un runtime preservando datos o una implementación manteniendo su contrato mediante un adapter. En este último caso terminó el código anterior, pero los consumidores todavía dependen de la interface antigua. El alcance de la retirada no debe ocultar esa continuidad.

Un redirect puede facilitar acceso, pero también ocultar consumidores, mantener una dependencia y alterar semántica. No resuelve automáticamente cambios en métodos, autorizaciones, payloads o efectos; fuera de HTTP puede no existir un equivalente útil. Conservar una traducción es una decisión arquitectónica con costo y ownership.

Una transición read/write → read-only → archivo puede preservar consulta histórica. Es una opción situada, no una receta. Si el trabajo que requiere escritura permanece, cambiar permisos no demuestra haberlo reemplazado: puede simplemente trasladar una interrupción a soporte o al usuario.

Evidencia sobre consumidores y dependencias

Preguntar quién sigue usando el alcance, quién puede continuar excepcionalmente y qué sucederá con consumidores que no migren. Una alternativa disponible no demuestra adopción. Puede necesitarse verificar flujos de negocio, compatibilidad, responsables y canales de soporte, además del porcentaje de tráfico desplazado.

legacy-systems incorpora lectores de BI, automatizaciones, scripts y conocimiento distribuido. Los consumidores de cola larga incluyen jobs mensuales, reporting anual, clientes offline, procesos estacionales y recuperación ante desastre. Una observación breve puede no encontrar ninguno y aun así omitir una dependencia decisiva.

Para una API pública puede ser imposible identificar a todos. Política publicada, avisos con antelación, outreach cuando sea posible y una fecha explícita pueden permitir actuar con incertidumbre residual. Sampling, cachés, intermediarios y falta de identidad limitan telemetría; cero requests recientes no certifica ausencia de consumidores.

systems-thinking amplía la frontera hacia finanzas, soporte, partners y personas que ejecutan trabajo manual. Si apagar un servicio obliga a reconstruir datos a mano cada cierre, la retirada técnica puede haber desplazado la carga. Examinar esas consecuencias forma parte de decidir si el cierre cumple su propósito.

Fechas, condiciones y excepciones

Una fecha puede coordinar equipos, pero no crea alternativa, migración ni preparación operacional. constraints incluye contratos, compromisos de soporte, calendario comercial, regulación, retención y cadencia de actualización de clientes. No existe una ventana correcta para cualquier servicio.

La evidencia pertinente puede incluir reemplazo viable donde se necesita, consumidores requeridos migrados, obligaciones de compatibilidad satisfechas, responsables preparados y disposición de datos definida. Son preguntas según el caso, no requisitos idénticos para todo recurso temporal o producto.

Mover una fecha puede ser racional si falta una capacidad crítica, aparece una dependencia o el riesgo supera lo previsto. También afecta confianza, planes de consumidores y costo del proveedor. Las extensiones deberían ser visibles, acotadas y revisables; ni «nunca se mueve» ni «siempre se prorroga» resuelve ese compromiso.

Impedir nuevas adopciones mientras migran las existentes puede reducir el alcance pendiente, cuando el proveedor puede hacerlo. Ante un cliente atrasado, extensión, fallo, proxy de compatibilidad o escalamiento dependen de política y relación. Ninguna opción garantiza costo cero ni continuidad ilimitada.

Datos después del servicio

Sunsetting del runtime no decide el lifecycle de los datos. Pueden permanecer como archivo read-only, exportación o historia accesible en el reemplazo. Retención por razones legales, financieras, de auditoría u operación puede superar la vida del servicio; otras obligaciones pueden exigir borrado. La disposición necesita una decisión propia conforme al contexto.

Definir qué se conserva, dónde, quién tiene autoridad, quién accede y durante cuánto tiempo. Conservar backups sin una forma de consulta o recuperación adecuada puede no satisfacer la necesidad real. Archivar también tiene costo de acceso, seguridad, comprensión de formatos y operación; no es equivalente a olvidar el almacenamiento.

data-migration trata movimiento, transformación, reconciliación y autoridad. Antes de retirar un store, verificar escritores antiguos, lectores residuales, historia requerida y divergencias pendientes según el alcance. Copia completa o tráfico redirigido no demuestra que pueda borrarse el origen.

data-ownership mantiene explícita la autoridad sobre correcciones y operaciones tardías. Tras nuevas escrituras en el destino, rollback de tráfico no es rollback de datos. Si se reactiva el origen sin reconciliar, puede recuperar una implementación y perder consistencia comercial. El cierre debe reconocer cuándo la contingencia necesita reparación o sincronización adicional.

Operación hasta completar la retirada

Mientras exista el alcance activo, alguien necesita atender incidentes, consultas, excepciones, migración y datos. Deprecated no significa «sin dueño»; sunsetting tampoco elimina responsabilidad antes del cierre. operability conserva diagnóstico y controles durante esos estados intermedios.

Requests restantes, versiones de clientes, errores y acceso histórico pueden revelar dependencias inesperadas. Desactivar monitoreo demasiado pronto elimina evidencia justamente cuando disminuye el conocimiento del camino antiguo. Revisar el destino de alertas y procedimientos junto a la capacidad, no como limpieza previa automática.

Retirar compute puede requerir resolver colas, DNS, certificados, credenciales, jobs, deployment y storage asociados. Cada recurso tiene dependencias y momento propio; no es un checklist universal de infraestructura. Un archivo conservado sigue necesitando responsable aunque ya no exista el proceso que lo produjo.

Commerce: cerrar Payments v1 sin perder historia

Este ejemplo propio continúa la deprecation de POST /payments/v1/authorize y la adopción de POST /payments/v2/authorizations. Los servicios conocidos usan v2; un partner ejecuta v1 solo al fin de mes. La decisión de sunset combina evidencia de esa ejecución con contacto y una política comunicada, sin interpretar dos semanas vacías como cierre.

Si el partner incumple la fecha, se evalúa una extensión explícita o el comportamiento previsto por el contrato. Un proxy podría mantener v1 sobre v2: retiraría una implementación, no ese contrato. El alcance y sus costos deben declararse para no anunciar una simplificación ficticia.

Después del corte cesan las nuevas autorizaciones v1. Refunds históricos todavía necesitan identificadores del proveedor y mappings de transacciones. Que las autorizaciones nuevas funcionen no demuestra que toda la capacidad antigua pueda apagarse. La historia puede migrarse o conservarse bajo acceso controlado sin seguir atendiendo v1 completo.

La base legacy mantiene un lector de BI y evidencia de auditoría. Antes de retirarla, Commerce reemplaza o termina deliberadamente esa dependencia, contrasta historia y confirma autoridad de escritura. Después retira compute y accesos innecesarios, manteniendo el archivo y su soporte según lo decidido. Es una trayectoria posible, no una secuencia universal ni una recomendación de retención concreta.

Componer mecanismos sin confundirlos

migration-strategy organiza estados y criterios de salida; Sunsetting atiende obligaciones del retiro. strangler-fig desplaza responsabilidades y necesita resolver qué camino anterior deja de servirlas. parallel-change contrae representaciones obsoletas tras la migración de consumidores; su mecanismo no cubre por sí solo todo el lifecycle de soporte y datos.

branch-by-abstraction puede retirar una implementación manteniendo la abstracción. refactor-vs-rewrite decide una transformación, sin cerrar automáticamente las obligaciones del reemplazado. cloud-migration puede permitir retirar infraestructura on-premises, pero un destino híbrido deliberado puede conservarla.

technical-debt ayuda a evaluar carga futura, sin justificar retirar algo solo por edad. cost-efficiency compara soporte, licencias, pruebas e infraestructura retenida con migración, comunicación, excepciones y archivo. El ahorro esperado no borra costo de cierre ni obligaciones de consumidores.

fitness-functions puede aportar evidencia sobre cese de escrituras o eliminación de dependencias; no autoriza automáticamente el retiro. evolutionary-architecture incluye abandonar decisiones que ya no sirven, evitando acumulación sin propósito. evolution-and-modernization conecta esas preguntas con Deprecation: anunciar la dirección y completar la retirada son trabajos diferentes que requieren evidencia propia.