Cómo recibir software de otro proveedor y preparar su continuidad

Distingue una recepción prevista de una recuperación incompleta

En una recepción coordinada, el proveedor saliente puede explicar la aplicación, preparar accesos y resolver diferencias. Si hay documentación o componentes faltantes, comienza por un inventario de lo disponible y una evaluación delimitada. Todavía no permite comprometer la continuidad completa o estimar una evolución amplia.

Identifica quién puede autorizar cada acceso y qué condiciones de entrega y uso están acordadas. El equipo entrante debe trabajar sobre material al que la empresa tenga acceso legítimo; no necesita credenciales personales del proveedor ni una copia de datos sensibles para una consulta inicial.

Inventario mínimo para recibir una aplicación

Desliza la tabla si no ves todas las columnas.

Comprueba una ejecución fuera del equipo del proveedor

Acuerda un entorno autorizado de prueba. El objetivo es comprobar que el equipo receptor puede preparar la aplicación con las instrucciones y componentes entregados, sin depender de archivos que solo existen en el computador del proveedor.

Esta prueba no reemplaza una revisión completa de seguridad ni demuestra que una migración de producción esté lista. Permite reconocer qué se puede operar con lo recibido y qué debe resolverse antes de avanzar.

• Identificar la versión y obtener sus dependencias desde las fuentes acordadas.
• Configurar el entorno usando ejemplos sin secretos y accesos por canales autorizados.
• Construir y ejecutar la aplicación siguiendo la documentación.
• Probar los recorridos prioritarios con datos ficticios o anonimizados.
• Comprobar integraciones habilitadas para prueba y dejar identificadas las que siguen pendientes.
• Registrar fallas, diferencias con producción y pasos que requieren documentación adicional.

Transfiere accesos con una secuencia que preserve la operación

Distingue la titularidad de una cuenta, sus administradores y las credenciales que usa la aplicación. La empresa necesita responsables y permisos acordes a su operación. La rotación o revocación de un acceso requiere conocer sus consumidores para evitar una interrupción accidental.

GitHub permite transferir la administración de un repositorio a otro propietario bajo sus requisitos y condiciones. Ese paso no transfiere por sí solo el alojamiento, las bases de datos, los dominios ni las cuentas de proveedores externos; deben revisarse por separado.

OWASP recomienda permisos ajustados a la necesidad y revocar secretos que ya no se requieren. En un traspaso, prepara una secuencia autorizada para revisar accesos del proveedor saliente, probar los nuevos y retirar los anteriores cuando corresponda.

Deja un acta de recepción con evidencias y pendientes

Registra cada componente como comprobado, pendiente o no aplicable. Para lo comprobado, conserva la referencia que permite repetir la validación. Un pendiente necesita un responsable, una consecuencia conocida y una decisión sobre si impide la siguiente etapa.

• Versión recibida y fecha de revisión, separadas de la versión publicada cuando difieran.
• Personas que entregan, reciben y autorizan los accesos.
• Recorridos probados y resultado esperado de cada uno.
• Componentes faltantes, fallas conocidas y limitaciones del entorno de prueba.
• Acciones de continuidad que puede realizar cada parte durante la transición.
• Condiciones que deben cumplirse antes de desplegar cambios o retirar al proveedor anterior.

Decide después si mantener, modernizar o reemplazar

Desliza la tabla si no ves todas las columnas.

Descarga un acta y un inventario de recepción

Usa referencias a evidencias y responsables; conserva el material técnico en los sistemas autorizados de tu empresa. Las plantillas no requieren contraseñas, tokens, datos de clientes ni código confidencial.

Alcance y criterio de esta guía

Este checklist ayuda a conversar entre la empresa y sus proveedores. La recepción, las condiciones de uso, los accesos y las responsabilidades dependen de lo acordado en cada proyecto. No acredita una auditoría ni una transferencia ya realizada por Digital Dev.

Guía institucional de Digital Dev elaborada con asistencia de IA. Las matrices, ejemplos y plantillas son criterios propios para evaluar un proyecto; las referencias técnicas se identifican en esta página.