Los proyectos exportados como código fuente necesitan una prueba de portabilidad

Exportar el código fuente demuestra que recibiste archivos. No demuestra que el proyecto pueda compilarse, iniciarse, autenticar usuarios, leer datos de producción o implementarse si desaparece el creador original de aplicaciones con IA. Trata la portabilidad como una prueba de aceptación, no como una casilla en un contrato de compraventa.

He heredado suficientes aplicaciones generadas como para desconfiar de un repositorio limpio a primera vista. Los fallos costosos suelen ocultarse fuera del código más evidente de la aplicación: una solicitud en tiempo de ejecución a un servicio del proveedor, un callback de autenticación registrado en el tenant de otra persona, una política de base de datos que nunca entró en el control de versiones o un ajuste de implementación que solo existe en un panel gestionado. Un proyecto es portátil cuando tu equipo puede reproducir su comportamiento funcional a partir de la exportación y de servicios externos documentados, en cuentas que controláis.

Los proyectos exportados como código fuente aún pueden depender del creador

Un proyecto exportado como código fuente solo se ejecuta de forma independiente si todas las dependencias necesarias en compilación y en tiempo de ejecución están disponibles, documentadas, son transferibles y tienen licencia para usarse fuera del creador. Esta definición es más exigente que «el repositorio compila». Abarca el recorrido desde una máquina vacía hasta una versión de producción funcional, incluida la identidad, los datos, las tareas programadas, los secretos, las reglas de red y la recuperación.

A menudo se mezclan tres afirmaciones distintas. El acceso al código fuente significa que puedes inspeccionar archivos. La independencia de compilación significa que puedes generar artefactos sin llamar al creador. La independencia en tiempo de ejecución significa que esos artefactos siguen atendiendo solicitudes reales sin el creador. Un proveedor puede cumplir la primera afirmación y fallar en las otras dos.

La distinción tiene una consecuencia contractual directa. Si el contrato promete «exportación de código fuente», quizá recibas un directorio React, un manifiesto de paquetes y un README, pero sigas necesitando un SDK propietario o una pasarela alojada. Pide un resultado operativo: un ingeniero autorizado debe poder compilar y ejecutar la versión aceptada en un entorno limpio con cuentas propiedad del cliente.

Define los límites antes de probar. Los servicios gestionados no implican automáticamente un fallo de portabilidad. La mayoría de aplicaciones serias dependen de una nube, un procesador de pagos, un proveedor de correo o un servicio de identidad. La cuestión es si elegiste esas dependencias sabiendo lo que hacías y si puedes trasladarlas o sustituirlas con tu propio contrato. Un servicio oculto del proveedor que no puedes contratar por separado es distinto de una base de datos PostgreSQL documentada en tu cuenta de nube.

Crea un registro de dependencias con cuatro campos para cada componente externo: propietario, finalidad, vía de sustitución y comportamiento ante fallos. «Propietario» significa el titular legal de la cuenta, no quien conoce la contraseña. La «vía de sustitución» puede ser un procedimiento de migración, una interfaz que puedes volver a implementar o una decisión explícita de conservar el servicio. El «comportamiento ante fallos» registra qué ven los usuarios cuando no está disponible. Si el vendedor no puede completar esos campos, la exportación no se ha explicado lo bastante bien como para valorar su riesgo.

La primera prueba más útil es sencilla: desconecta el acceso a la cuenta del creador e intenta usar la aplicación. Revoca sus tokens en una copia de staging, bloquea sus dominios conocidos en el límite de red y observa qué falla. No empieces leyendo todos los archivos. La evidencia en tiempo de ejecución encuentra dependencias que la revisión de código no detecta, incluida la configuración inyectada y las llamadas realizadas por paquetes compilados.

Rastrea la aplicación mientras se ejecutan flujos reales

Los callbacks en tiempo de ejecución salen a la luz al observar DNS, conexiones salientes, solicitudes del navegador y trabajos en segundo plano durante flujos representativos. Que cargue una página de inicio demuestra muy poco. Prueba el inicio de sesión, la recuperación de contraseña, la carga de archivos, la búsqueda, los cambios de facturación, la entrega de correo, las tareas programadas, las acciones administrativas y cualquier función con IA que el producto venda de verdad.

Ejecuta la aplicación en una red de staging nueva donde se registre el tráfico saliente. Concédele solo los destinos incluidos en el registro de dependencias. Empieza con una política de denegación para el tráfico no listado si tu entorno lo permite. Cada solicitud bloqueada plantea una pregunta: ¿es necesaria, telemetría opcional, una comprobación de actualizaciones o una llamada al plano de control no documentada?

Las herramientas de desarrollo del navegador importan porque algunas dependencias nunca pasan por tu servidor. Inspecciona el panel Network después de borrar el almacenamiento y usar una sesión nueva. Revisa los hosts de solicitud, las solicitudes preflight fallidas, las conexiones WebSocket, los scripts cargados y las redirecciones. Un frontend puede llamar directamente a una API del creador aunque el repositorio del servidor parezca autosuficiente. Los service workers también pueden conservar comportamientos antiguos, así que elimínalos antes de repetir la prueba.

En un árbol de código tipo Unix, esta búsqueda ofrece un primer inventario útil:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

Espera resultados con el formato path/to/file:line:matching text. Revisa los archivos de bloqueo generados por separado del código de la aplicación, porque un dominio en los metadatos de un paquete no demuestra una llamada en tiempo de ejecución. A la inversa, una búsqueda limpia tampoco demuestra independencia: las variables de entorno pueden construir hosts, los alias DNS pueden ocultarlos y las dependencias binarias pueden hacer sus propias solicitudes.

Busca por separado términos del proveedor, importaciones de SDK y prefijos de variables de entorno. Después, revisa los archivos de bloqueo para comprobar si los paquetes se resuelven desde un registro público o desde un registro privado del proveedor. El éxito por caché puede engañarte. Elimina las cachés de paquetes del lenguaje en el entorno de prueba aislado y vuelve a compilar solo con las credenciales documentadas del registro.

Rastrea el comportamiento en segundo plano durante el tiempo suficiente para cruzar un límite del planificador. Un proceso web puede parecer sano mientras fallan los consumidores de cola, se detienen los informes programados y se acumulan reintentos de webhooks. Activa los trabajos manualmente cuando esperar su horario habitual ralentizaría la prueba. Registra el destino, método de solicitud, tipo de autenticación, clase de respuesta, regla de reintento y consecuencia visible para el usuario de cada integración saliente.

No aceptes «ese callback es solo telemetría» sin probar su fallo. Bloquéalo y repite el flujo. La telemetría opcional debería agotar el tiempo de espera rápidamente o fallar sin cambiar la operación del usuario. He visto llamadas de registro dentro de una transacción de solicitud que convierten una caída inocua de analítica en un guardado fallido. La etiqueta no determina el riesgo, lo determina la ruta de código.

Los SDK propietarios necesitan una vía de eliminación o licencia

Un SDK propietario es aceptable solo si puedes obtenerlo, compilar con él, ejecutarlo legalmente y sustituirlo en un plazo que el negocio pueda tolerar. Tener el código fuente de su envoltorio en la exportación no te concede derechos sobre el SDK, el protocolo, el endpoint alojado ni el modelo que hay detrás.

Haz un inventario de dependencias tanto desde los manifiestos como desde las importaciones de código. Para JavaScript, revisa package.json y su archivo de bloqueo. Para Go, revisa go.mod y las sumas de verificación. Para Flutter, revisa pubspec.yaml y su archivo de bloqueo. Anota los paquetes obtenidos de repositorios Git, registros privados, rutas locales o archivos. Son lugares habituales donde se ocultan componentes propiedad del creador.

Para cada paquete dudoso, responde cuatro preguntas concretas:

1. ¿Puede un agente de compilación nuevo, propiedad del cliente, descargar la versión exacta?
2. ¿La licencia permite su uso en producción después de terminar el contrato con el creador?
3. ¿El paquete llama a un servicio que el cliente puede contratar directamente?
4. ¿La interfaz es lo bastante pequeña para sustituirla y está probada esa interfaz?

Haz una compilación en frío con credenciales creadas en una organización propiedad del cliente. No copies al equipo de prueba todo el directorio de configuración de un desarrollador. Eso importa paquetes en caché, ajustes implícitos de registros y tokens personales, lo que invalida el ejercicio. Un procedimiento de compilación correcto empieza con la versión documentada de la cadena de herramientas y declara cada credencial adicional por separado.

Genera una lista de materiales de software si la cadena de herramientas lo admite, pero no confundas ese documento con un dictamen de portabilidad. Un SBOM enumera componentes; rara vez indica quién controla una cuenta remota o si un paquete se comunica con su origen. Úsalo para conciliar lo que declara el repositorio con lo que contiene el artefacto compilado.

Cuando un cliente propietario esté detrás de un adaptador estrecho, escribe ahora una prueba de contrato contra ese adaptador. Envíale una solicitud conocida, verifica la respuesta normalizada y ejecuta la misma prueba con el endpoint de red bloqueado. El fallo debe ser explícito y acotado. Si las llamadas propietarias aparecen por componentes de vista, manejadores de rutas y modelos de datos, calcula una refactorización antes de firmar. El problema crece con el número de puntos de llamada y el acoplamiento semántico, no con el número de líneas del SDK.

Los equipos suelen recomendar sustituir todas las dependencias propietarias antes de comprar. Suena prudente, pero puede desperdiciar semanas en servicios que el comprador pretende conservar. La mejor regla es eliminar las dependencias que no están disponibles o no se pueden contratar, aislar las que aceptes y añadir el coste de migración a las demás. La portabilidad consiste en controlar las opciones, no en tener una aplicación sin servicios externos.

La autenticación abarca más que el árbol de código fuente

La autenticación se traslada sin problemas solo cuando el cliente controla el tenant de identidad, los registros de redirección, las claves de firma, los identificadores de usuario, las plantillas de correo y el proceso de recuperación. El código de la aplicación suele capturar solo una parte de ese sistema.

Empieza dibujando la ruta de inicio de sesión con sus saltos reales. Un navegador llega a la aplicación, la aplicación redirige a un proveedor de identidad, el proveedor vuelve a un callback registrado y el backend intercambia o valida credenciales. Registra el propietario y la ubicación de configuración en cada salto. Si solo puedes acceder a alguna consola mediante la organización del creador, exige una transferencia o sustitución antes de la aceptación.

La autenticación gestionada genera un problema de datos especialmente incómodo. La tabla de usuarios de la aplicación puede guardar un sujeto específico del proveedor en lugar de una dirección de correo o un ID interno duradero. Exportar filas no sirve si un nuevo tenant de identidad emite sujetos distintos. Prueba la asociación de cuentas, el tratamiento de duplicados, los usuarios con contraseña, los usuarios con inicio de sesión social, la inscripción multifactor, las cuentas bloqueadas y los usuarios con direcciones de correo modificadas.

OpenID Connect define la reclamación sub como un identificador localmente único que nunca se reasigna dentro del ámbito del emisor. El emisor importa. Tratar sub por sí solo como globalmente portable puede asociar el registro incorrecto de la aplicación tras cambiar de tenant. Guarda y compara el emisor junto con el sujeto, y diseña una asignación explícita para la migración.

Tu prueba necesita al menos cuatro cuentas: un usuario normal, un administrador, un usuario deshabilitado y un usuario con un segundo factor de autenticación. Traslada o recrea la configuración de identidad en un tenant propiedad del cliente, restaura una copia de la base de datos de staging y verifica tanto el inicio de sesión correcto como el acceso denegado. Prueba también el cierre de sesión, la renovación de tokens, el restablecimiento de contraseña, la aceptación de invitaciones y la caducidad de la sesión. Los equipos recuerdan la ruta feliz de inicio de sesión y descubren la recuperación rota solo después del cambio.

Busca en el repositorio URI de redirección, ID de cliente, nombres de emisor, dominios de cookies, valores de audiencia y referencias a claves de firma. Mantén los secretos fuera del repositorio, pero documenta sus nombres, propietarios, pasos de creación, pasos de rotación y formatos requeridos. Un archivo de entorno de ejemplo debe identificar el contrato sin contener valores activos:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

No aceptes un tenant compartido del creador como solución permanente solo porque la migración pueda hacerse «más adelante». Las migraciones de identidad afectan a todos los usuarios activos y a cada supuesto de autorización. Transfiere el control antes de firmar o convierte la sustitución en una condición del acuerdo con precio y pruebas.

La portabilidad de la base de datos incluye comportamiento y operaciones

Un volcado de base de datos es insuficiente cuando los esquemas, extensiones, políticas de nivel de fila, triggers, almacenamiento de objetos, colas, copias de seguridad y reglas de conexión viven fuera de él. La portabilidad de la base de datos significa que puedes restaurar los datos y reproducir el comportamiento que los protege y modifica.

Empieza con una instancia PostgreSQL vacía, propiedad del cliente, en la versión principal documentada. Aplica en orden las migraciones del repositorio. Si el proyecto no tiene migraciones y exige importar un volcado de esquema creado por el proveedor, regístralo como un defecto. Un volcado puede capturar el estado actual, pero no explica cómo la siguiente versión cambia ese estado de forma segura.

Compara el esquema restaurado con producción o staging. Comprueba tablas, columnas, tipos, restricciones, índices, secuencias, vistas, funciones, triggers, extensiones habilitadas, roles, permisos y políticas de seguridad a nivel de fila. Muchas herramientas de migración omiten roles y ajustes de nivel de proveedor. Una aplicación puede superar pruebas básicas de lectura mientras los trabajos administrativos fallan porque el rol restaurado no tiene permiso sobre una secuencia o función.

Después, verifica la ruta de datos con un recorrido controlado:

1. Crea un registro mediante el flujo público de la aplicación.
2. Léelo mediante un segundo usuario autorizado cuando se espere que se comparta.
3. Confirma que un usuario no autorizado no puede leerlo ni modificarlo.
4. Actualízalo y elimínalo mediante la aplicación.
5. Restaura la base de datos en otra instancia limpia y repite las lecturas.

Esta secuencia prueba conjuntamente el código de la aplicación, la política de autorización, los valores generados y la recuperabilidad. Los recuentos de filas con SQL directo no pueden cubrir esos comportamientos.

Considera el almacenamiento de objetos como parte del límite de la base de datos cuando las filas apuntan a archivos cargados. Exporta los buckets, metadatos de objetos, reglas de acceso, reglas de ciclo de vida y ajustes de generación de URL. Una base de datos restaurada llena de claves de objetos no sirve de nada si los archivos subyacentes siguen en un bucket propiedad del creador. La misma advertencia se aplica a los índices de búsqueda y almacenes vectoriales: decide si los migrarás o los reconstruirás y demuestra el procedimiento de reconstrucción.

No midas el éxito ni el fracaso con un único volcado pequeño. Usa una copia con tamaño de staging que contenga texto largo, valores nulos, caracteres no ASCII, objetos grandes, marcas de tiempo en torno a cambios de horario de verano y relaciones representativas. No necesitas benchmarks inventados. Necesitas pruebas de que la transferencia termina dentro de la interrupción permitida y de que la aplicación se comporta correctamente después.

Las afirmaciones sobre copias de seguridad requieren una restauración. Identifica quién programa las copias, dónde viven las copias, quién puede descifrarlas, cómo funciona la retención y cómo detectas una copia fallida. Restaura una en una cuenta aislada siguiendo instrucciones escritas. Si solo el creador puede pulsar el botón de restaurar, tienes una función de servicio, no un plan de recuperación independiente.

Una canalización de CI ausente es conocimiento de producto ausente

Un repositorio exportado sin integración continua reproducible obliga al comprador a redescubrir versiones de herramientas, orden de compilación, pruebas, empaquetado de artefactos, momento de las migraciones de base de datos y controles de publicación. Ese conocimiento forma parte de lo entregable aunque la canalización interna del vendedor no pueda transferirse literalmente.

Busca definiciones de canalizaciones, archivos de compilación de contenedores, archivos de versiones de herramientas, comandos de prueba, reglas de lint, comandos de migración y definiciones de infraestructura. Después compáralos con un registro de implementación real. La documentación suele describir una compilación web sencilla mientras la plataforma gestionada genera silenciosamente configuración, inyecta un componente de servidor, compila un paquete móvil o ejecuta migraciones de base de datos.

Reconstruye la canalización mínima en una cuenta de CI propiedad del cliente. Debe obtener una revisión fijada, instalar una cadena de herramientas declarada, recuperar dependencias, ejecutar pruebas, generar artefactos inmutables y registrar la identidad del artefacto. La implementación puede seguir siendo manual durante la prueba, pero el artefacto que llega a staging debe ser el que produjo la canalización.

Un registro de aceptación compacto puede tener esta forma:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

Los valores variarán, pero cada línea necesita salida de máquina o un registro interno vinculado, no el recuerdo de una persona. Conserva el registro junto con las pruebas de aceptación.

No exijas la maquinaria secreta de implementación del vendedor si no la necesitas. Exige instrucciones y configuración suficientes para reproducir el resultado. Una canalización portátil puede dirigirse a otro producto de CI siempre que ejecute las mismas etapas requeridas y no debilite los controles de publicación.

Las aplicaciones móviles añaden recursos de firma, identificadores de paquete, cuentas de tiendas y credenciales de notificaciones push. Es fácil pasarlos por alto porque una compilación de código puede ejecutarse en un emulador sin ellos. Verifica que el cliente sea propietario de las cuentas de distribución y documenta la rotación de certificados. Para aplicaciones de servidor y web, incluye la verificación de dominio, la emisión de certificados TLS, los cambios de DNS y la invalidación de caché en el ejercicio de publicación.

La prueba de canalización termina con un cambio, no con la recompilación del commit suministrado. Haz una edición visible e inocua, añade una migración de base de datos que pueda revertirse, compílala, impleméntala en staging, verifícala y ejecuta la reversión. Esto detecta artefactos generados que se incorporaron una vez, pero que no pueden regenerarse.

Fija los paquetes del sistema operativo usados por la compilación, además de la cadena de herramientas del lenguaje. Los módulos nativos pueden compilar contra bibliotecas que existen por casualidad en la imagen del creador. Entonces un nuevo ejecutor falla antes de iniciar las pruebas de la aplicación o, peor aún, produce un artefacto con otro comportamiento. Captura nombres y versiones de paquetes en una definición de contenedor o una descripción de compilación equivalente legible por máquina.

Mantén los secretos fuera de los registros de CI mientras demuestras que la canalización puede obtenerlos de un almacén controlado por el cliente. La prueba debe crear una credencial de staging de corta duración, inyectarla mediante el mecanismo documentado y rotarla sin editar el código fuente. Si un técnico de soporte debe pegar un secreto en un panel del proveedor, registra esa dependencia en vez de ocultarla en notas de configuración.

Las suposiciones de hosting afloran durante una implementación en entorno limpio

Una implementación en entorno limpio demuestra la portabilidad cuando un equipo que no conoce el creador puede poner en marcha el sistema en un entorno propiedad del cliente usando solo la exportación, los servicios declarados y las instrucciones escritas. Hazla antes de la aceptación contractual, con un límite de tiempo y un registro de incidencias.

Elige un entorno que coincida con el modelo operativo previsto. Pasar de una plataforma gestionada a máquinas virtuales sin procesar crea trabajo ajeno al objetivo y puede hacer que un proyecto portátil parezca roto. Iguala los componentes necesarios, como contenedores, PostgreSQL, almacenamiento de objetos, trabajos programados, secretos y balanceo de carga, pero no recrees magia del proveedor sin documentar.

Inspecciona la aplicación para detectar supuestos sobre discos locales con escritura, puertos fijos, sesiones persistentes, cabeceras de proxy de confianza, nombres de región, hosts inyectados y variables de entorno específicas de la plataforma. The Twelve-Factor App recomienda guardar la configuración en el entorno y tratar los servicios de apoyo como recursos conectados. Estas ideas siguen siendo útiles, pero las variables de entorno por sí solas no documentan propiedad, formatos ni creación. Acompaña cada variable de un registro operativo.

Las comprobaciones de estado merecen pruebas directas. Un proceso que devuelve éxito antes de que terminen las migraciones o se conecten las dependencias necesarias puede entrar en un bucle de reinicios tras un orquestador. Separa liveness de readiness cuando el sistema de hosting lo permita. Detén la base de datos, el almacén de objetos y la cola de uno en uno, y observa los códigos de estado, registros, comportamiento de reintentos y recuperación cuando vuelve el servicio.

Confirma cómo gestiona la aplicación varias instancias. Las sesiones en memoria, los directorios locales de carga y los bloqueos de trabajos locales al proceso funcionan en una instancia gestionada y fallan al escalar. Inicia dos instancias, envía las solicitudes del mismo usuario a ambas y ejecuta workers de trabajos simultáneos. Comprueba que las sesiones persistan, los archivos sigan disponibles y una tarea programada no se ejecute dos veces, salvo que esté diseñada para ser idempotente.

Observa el apagado con el mismo cuidado que el arranque. Envía una señal de terminación mientras hay solicitudes y trabajos en segundo plano activos. El proceso debe dejar de aceptar trabajo nuevo, terminar o devolver de forma segura los trabajos reclamados, cerrar conexiones y salir dentro del período de gracia del host. Un creador gestionado puede haber ocultado apagados abruptos con tiempos de espera largos o reintentos que tu nuevo host no comparte.

Los registros y métricas también arrastran supuestos de hosting. Confirma que la aplicación escriba eventos estructurados en un destino documentado, elimine secretos y datos personales cuando sea necesario y exponga suficiente información para diagnosticar un flujo fallido. Un panel propietario solo es opcional si la salida estándar u otro destino controlado por el cliente conserva las pruebas necesarias.

Las afirmaciones sobre región y ubicación de datos necesitan pruebas de configuración. Registra dónde se ejecutan la aplicación, la base de datos, las copias de seguridad, los registros y el almacenamiento de objetos, además de qué servicios externos reciben datos. Un selector de región para el proceso web no mantiene los datos en un país si la autenticación o la analítica los envían a otro lugar. El contrato debe indicar quién aprueba los cambios en esas ubicaciones.

Koder.ai permite exportar código fuente, implementación y hosting, dominios personalizados, instantáneas y reversión. Si evalúas un proyecto Koder.ai exportado para que funcione de forma independiente, aplica el mismo criterio de entorno limpio: prueba los componentes React, Go con PostgreSQL o Flutter exportados en el entorno que pretendes controlar y documenta cualquier servicio que decidas conservar.

Incluye condiciones de aprobación y rechazo en el contrato

El contrato debe definir la portabilidad como comportamiento observado, enumerar el entorno de aceptación, asignar la responsabilidad de subsanación y conservar tiempo suficiente para corregir fallos antes del pago final o la dependencia forzada. Un lenguaje vago sobre propiedad no salvará una aplicación que nadie más puede implementar.

Adjunta una matriz de aceptación en vez de confiar en un párrafo titulado «código fuente». Cada fila debe nombrar una capacidad, procedimiento de prueba, resultado esperado, pruebas, responsable y gravedad. Incluye compilación en frío, llamadas de red en tiempo de ejecución, transferencia de identidad, restauración de base de datos, almacenamiento de archivos, trabajo en segundo plano, CI, implementación limpia, monitorización, restauración de copias de seguridad, un cambio pequeño y reversión.

Usa criterios de aprobación que un tercero pueda observar. «Sin dependencia propietaria crítica» invita a la discusión. «La aplicación de staging completa los flujos A a F mientras se revocan todas las credenciales propiedad del creador y se bloquean los dominios del creador» se puede probar. Define las dependencias permitidas por nombre y propietario de la cuenta para que el equipo no confunda un servicio gestionado aprobado con un fallo.

Exige la entrega del código fuente y los materiales operativos en una revisión fijada: archivos de bloqueo, migraciones, definiciones de compilación, configuración de infraestructura cuando esté disponible, catálogo de variables de entorno, registro de dependencias, exportación de datos, plan de migración de identidad, manuales operativos, avisos de licencia y recursos de firma o distribución que pertenezcan al cliente. Registra las exclusiones de forma explícita. El silencio no debe significar aceptación.

Establece la gravedad según el efecto empresarial. La ausencia de un evento opcional de analítica no equivale a una caída del inicio de sesión. Un esquema útil distingue bloqueos que impiden la compilación o los flujos principales, defectos graves que eliminan una capacidad importante o una vía de recuperación, y defectos menores con una solución alternativa documentada. Vincula las fechas de aceptación y subsanación a esos niveles sin inventar un calendario universal.

Define también los datos de prueba y el operador de prueba. A veces los vendedores demuestran la portabilidad con una base de datos vacía y una cuenta de administrador que evita la autorización habitual. Exige usuarios, roles, archivos y trabajos en segundo plano representativos, y que el personal del cliente ejecute el procedimiento documentado. Mantén los secretos sintéticos, pero conserva relaciones y casos límite realistas.

Los costes forman parte del paquete de pruebas. Registra los servicios facturados por separado que se necesiten para ejecutar la versión exportada y cualquier nivel mínimo, cargo por salida de datos o suscripción a registro privado que identifique el vendedor. La prueba no necesita prever cada factura futura. Debe evitar que una exportación supuestamente independiente revele un contrato de proveedor inevitable solo después de firmar.

Incluye deberes de cooperación para los servicios que no puedan transferirse al instante. El vendedor quizá deba rotar claves, aprobar una exportación de identidad, trasladar un dominio o proporcionar una instantánea final de datos. Nombra la acción y la persona responsable. «Asistencia razonable» es difícil de exigir cuando producción está caída.

Conserva el derecho de repetir las pruebas después de la subsanación y después de la exportación final. Los proyectos generados cambian deprisa, y una corrección demostrada con la revisión del mes pasado no dice nada de dependencias añadidas ayer. Fija el commit probado y los hashes de artefactos en el registro de aceptación.

No dejes que una cláusula de depósito en garantía sustituya este trabajo. El depósito puede entregar archivos tras un evento desencadenante, pero unos archivos sin instrucciones actuales de compilación, propiedad de credenciales y vías de recuperación probadas pueden llegar demasiado tarde para servir de ayuda. La independencia operativa debe existir mientras ambas partes aún pueden colaborar.

Firma cuando un segundo equipo pueda compilar, ejecutar, modificar, implementar y recuperar la versión aceptada sin ayuda privilegiada del creador original. Cualquier cosa menos que eso es posesión del código fuente con un proyecto de migración sin resolver añadido, y el precio del contrato debería reflejar ese trabajo.