Cómo preparar la puesta en producción de un software

Poner un software en producción no consiste solo en copiar una versión al entorno real. Es decidir si la versión, los datos, los accesos, las dependencias, las personas y la salida ante fallo están preparados para que usuarios reales trabajen con ella.

Un buen go-live no promete que no habrá incidentes. Hace visible qué se lanza, quién decide, cómo se comprueba, cuándo se detiene y qué debe ocurrir antes de transferir el sistema a su operación habitual.

Empieza con una versión aceptada y sus pendientes

Antes de preparar el lanzamiento identifica:

versión o artefacto exacto;
alcance y criterios de aceptación vigentes;
pruebas completadas y evidencia;
defectos y pendientes conocidos;
excepciones aceptadas, con owner;
configuración y dependencias que cambian en producción.

La guía para probar y aceptar software antes de la entrega cubre la decisión funcional. C11 comienza después: una versión aceptada todavía puede no estar lista para uso real si faltan accesos, datos, soporte, monitorización o una salida viable.

Convierte el go/no-go en una decisión trazable

El checkpoint debe responder:

Dimensión	Pregunta de control
Versión	¿Sabemos exactamente qué se va a desplegar?
Aceptación	¿Los criterios críticos pasan y los pendientes tienen decisión?
Datos	¿La carga, migración o estado inicial se ha probado y validado?
Integraciones	¿Terceros, jobs y eventos necesarios están disponibles?
Accesos	¿Usuarios, soporte y operación tienen permisos adecuados?
Recuperación	¿Existe rollback, rollforward o modo degradado viable?
Observación	¿Podremos detectar fallo técnico y resultado incorrecto?
Soporte	¿Usuarios saben dónde acudir y quién responde?

Microsoft reúne estas dimensiones en su checklist de go-live para Dynamics 365 (Microsoft Learn, actualizada 01/02/2024; observada el 29/08/2026). Es una referencia de producto: se usa como inventario de preguntas, no como método universal ni recomendación tecnológica.

El resultado no tiene que ser siempre go. Puede ser go, go condicionado, no-go o not-evaluated si falta una dependencia. La persona autorizada debe registrar la decisión, los pendientes y el siguiente checkpoint.

Prepara producción sin copiar secretos ni supuestos

Comprueba el entorno y la configuración que realmente recibirá tráfico o usuarios:

dominios, certificados y servicios externos;
variables de entorno y configuración;
cuentas de servicio y permisos mínimos;
backups y restauración comprobable cuando aplique;
límites, cuotas y dependencias de proveedor;
logs, métricas, alertas y acceso de soporte;
versión de base de datos, jobs y tareas programadas.

La preparación de datos, accesos e integraciones debe empezar antes del proyecto. En el go-live se verifica que la versión de producción existe, que sus owners siguen disponibles y que lo pendiente no se ha convertido silenciosamente en supuesto.

No pegues credenciales en el plan de lanzamiento. El documento debe indicar quién las concede, rota o revoca y mediante qué mecanismo autorizado.

Trata datos e integraciones como parte del lanzamiento

Si hay carga o migración de datos, define:

fuente y corte temporal;
transformación y validación;
registros esperados y excepciones;
reconciliación entre origen y destino;
escrituras que pueden ocurrir durante el cambio;
evidencia y responsable de aceptación.

Prueba también integraciones, procesos en segundo plano y tareas programadas. Una pantalla puede responder correctamente mientras una sincronización, notificación o job queda detenido.

Cuando el lanzamiento sustituye un sistema operativo, la guía para reemplazar software antiguo desarrolla convivencia, cutover, datos autoritativos y retirada. No dupliques aquí ese plan de legado.

Escribe la secuencia con owner y checkpoint

Un plan de puesta en producción necesita más que una lista ordenada:

Paso	Registro mínimo
Acción	qué se cambia o ejecuta
Owner	quién lo realiza y confirma
Precondición	qué debe ser cierto antes
Evidencia	qué salida demuestra que terminó
Parada	qué resultado impide continuar
Recuperación	rollback, rollforward o alternativa
Comunicación	quién debe conocer el estado

Incluye una pausa explícita antes de abrir acceso o tráfico. Si existe rollout gradual, define qué grupo entra primero y qué señal permite ampliar. No todas las aplicaciones necesitan canary, blue-green o feature flags; la estrategia depende de arquitectura, riesgo y capacidad.

Microsoft recomienda revisar antes del despliegue roles, accesos, criterios de éxito y rollback, y validar después flujos críticos, integraciones, métricas y experiencia de usuario (Microsoft Learn, observada el 29/08/2026). Su contexto es cloud-native en Azure; los mecanismos concretos no se trasladan por defecto.

Define rollback, rollforward y parada antes de necesitarlos

“Tenemos backup” no explica cómo volver. El plan debe distinguir:

revertir código o configuración;
restaurar datos;
preservar escrituras ocurridas después del cambio;
desactivar una función sin retirar toda la versión;
corregir hacia delante cuando volver cause más riesgo;
operar temporalmente en un modo degradado conocido.

Registra el punto a partir del cual el rollback deja de ser seguro y quién puede decidirlo. Ninguna salida garantiza continuidad: incluso volver atrás puede necesitar reconciliación, comunicación y una ventana controlada.

Comprueba producción con señales técnicas y de negocio

Tras desplegar, ejecuta smoke tests simples sobre los flujos y dependencias esenciales. GOV.UK recomienda comprobar el artefacto en producción y planificar cancelación o rollback cuando la prueba falla (GOV.UK, actualizada 23/10/2024; observada el 29/08/2026). Su modelo de despliegue público no obliga a adoptar los mismos entornos o pipeline.

Separa al menos:

salud técnica: errores, latencia, disponibilidad, colas y recursos;
resultado de negocio: el usuario puede completar el flujo y la salida llega al destino correcto;
operación: alertas, tickets y decisiones reciben respuesta.

No declares éxito solo porque la aplicación abre. Comprueba autenticación, permisos, datos, integraciones, trabajos en segundo plano y el recorrido crítico desde la perspectiva del usuario.

Prepara a usuarios y soporte

Antes de abrir el sistema confirma:

qué cambia y cuándo;
quién puede usarlo;
instrucciones y formación necesarias;
canal de ayuda y horario acordado;
responsable funcional y técnico;
cómo se comunica una incidencia o un cambio de estado;
workaround disponible si una función queda limitada.

GOV.UK señala que las personas que apoyan a usuarios deben entender el servicio antes de pasar a live, junto con métricas, seguridad, accesibilidad, disponibilidad y QA (GOV.UK, observada el 29/08/2026). Es un estándar público amplio; cada proyecto debe decidir qué requisitos le aplican.

Cierra la estabilización por criterios, no por una cifra universal

La estabilización es un periodo de observación y respuesta reforzada tras el lanzamiento. No tiene una duración válida para todos los proyectos ni equivale a mantenimiento indefinido.

Puede cerrarse cuando:

los recorridos críticos funcionan con casos reales;
los incidentes bloqueantes están resueltos o tienen decisión;
datos e integraciones se han reconciliado;
señales y alertas llegan a su owner;
usuarios conocen el canal de soporte;
pendientes y limitaciones están documentados;
la responsabilidad cotidiana se ha transferido.

AWS propone revisar readiness antes del lanzamiento con un checklist adaptado a arquitectura, procesos, eventos, release, personas y salida ante fallos (AWS, observada el 29/08/2026). El contexto es AWS; la utilidad transferible es revisar capacidad operativa y riesgo residual, no certificar universalmente el sistema.

Después de esa transferencia empieza la operación sostenida de una automatización: owners, señales, alertas, runbooks, cambios, incidentes y retirada durante el resto de su vida.