Lista de verificación para el traspaso de software: qué revisar antes de aceptarlo

Antes de aceptar la responsabilidad de un sistema que construyó otra persona, revíselo. Esta es la lista de verificación que usa AL+ en el traspaso de software. Está escrita para que un fundador, un director técnico o un equipo entrante puedan usarla sin nosotros. Recórrala en orden; las primeras secciones le protegen de los fallos que no tienen vuelta atrás.

La lista tiene ocho partes. Cada punto es una pregunta con respuesta de sí o no. Un «no» no es motivo para rechazar el sistema. Es una línea del plan.

1. Accesos y titularidad

El fallo más común en un traspaso es descubrir, semanas después, que una cuenta crítica pertenece a alguien que se ha ido.

• ¿El código fuente está en un repositorio de su empresa, con los derechos de administrador en manos de su empresa?
• ¿Tiene acceso de propietario al alojamiento, al DNS, al registrador del dominio, a las bases de datos, al almacenamiento de objetos y a la CDN?
• ¿El envío de correo, los proveedores de pago, las APIs de terceros, las cuentas de las tiendas de apps y la monitorización están registrados con direcciones de la empresa y no personales?
• ¿Dónde se guardan los secretos, y puede rotar todas las credenciales que tenía el desarrollador anterior sin una interrupción del servicio?
• ¿Qué cuentas son de pago, con qué tarjeta, y cuándo se renueva o caduca cada una?
• ¿Hay licencias (tipografías, bibliotecas, puestos de SaaS, teselas de mapas) que dejarán de estar vigentes cuando se cierren las cuentas del equipo anterior?

Si alguna respuesta es «no lo sabemos», deténgase y averígüelo antes de cambiar nada.

2. La realidad de producción

El repositorio le dice lo que se pretendía. La producción le dice lo que es cierto.

• ¿Qué está desplegado ahora mismo, desde qué commit, y coincide con la rama principal?
• ¿Cómo se despliega? ¿A mano, con un script, con un pipeline? ¿Puede repetirlo?
• ¿Qué se ejecuta de forma programada: tareas cron, colas, funciones programadas, webhooks? ¿Dónde se configuran?
• ¿A qué servicios externos llama el sistema, y cuáles lo llaman a él?
• ¿Qué dicen los registros y los rastreadores de errores sobre lo que lleva tiempo fallando en silencio?
• ¿Qué entornos hay además de producción? ¿Existe un entorno de preproducción parecido?

3. Datos

Los datos son la parte de un sistema que no se puede regenerar.

• ¿Dónde viven los datos: bases de datos, archivos, servicios de terceros, hojas de cálculo?
• ¿Qué tamaño tienen y con qué rapidez crecen?
• ¿Cuándo se hizo la última copia de seguridad, y alguna vez se ha restaurado una en otro lugar para comprobarla?
• ¿Qué datos personales se conservan, con qué base jurídica y dónde está documentado?
• ¿Hay migraciones pendientes, a medio aplicar o aplicadas a mano?
• ¿Puede exportar los datos en un formato que pueda llevar a otro sistema?

Restaure una copia de seguridad en un lugar seguro durante la revisión. Una copia de seguridad que nunca se ha restaurado es una esperanza, no una copia de seguridad.

4. Seguridad de los cambios

Va a necesitar cambiar el sistema. Averigüe lo peligroso que es.

• ¿Puede ejecutar el sistema en un equipo de desarrollo a partir solo del repositorio?
• ¿Hay pruebas? ¿Pasan? ¿Qué cubren?
• ¿Hay un paso de revisión antes de que el código llegue a producción?
• ¿Se puede deshacer una mala versión, y se ha hecho alguna vez?
• ¿Un cambio trivial (una errata en el pie de página) recorre todo el circuito de publicación en menos de un día?

Si la respuesta a la última pregunta es no, arreglar ese circuito es la primera tarea de ingeniería, antes de cualquier función nueva.

5. Dependencias y plataforma

• ¿Cuáles son las versiones del entorno de ejecución, del framework y de la base de datos, y cuándo llega cada una al final de su vida útil?
• ¿Cuántas dependencias hay, qué antigüedad tienen y cuáles ya no se mantienen?
• ¿Alguna tiene vulnerabilidades conocidas?
• ¿Cuándo fue la última actualización y qué dejó de funcionar?
• ¿Hay algo fijado a una versión por un motivo que nadie recuerda?

6. Conceptos básicos de seguridad

Esto no es una prueba de penetración. Es lo mínimo que debe saber antes de hacerse cargo del sistema.

• ¿La autorización se aplica en el servidor o solo en la interfaz?
• ¿Hay secretos en el código o en el historial del repositorio?
• ¿Se validan los datos que introduce el usuario antes de que lleguen a la base de datos o al shell?
• ¿Quién tiene acceso a producción, y ese acceso es individual y revocable?
• ¿Quedan activos endpoints administrativos, modos de depuración o credenciales por defecto?
• ¿El transporte está cifrado en todas partes, también entre servicios?

7. Conocimiento

• ¿Se puede contactar con el desarrollador anterior, y está dispuesto a responder preguntas a cambio de una remuneración?
• ¿Existe alguna descripción escrita de la arquitectura, del despliegue o de las razones de las decisiones importantes?
• ¿Qué partes del sistema no entiende nadie en la actualidad?
• ¿Qué partes evita tocar todo el mundo, y por qué?
• ¿Qué incidentes hubo en el último año y cómo se resolvieron?

Pregunte por decisiones, no por código: por qué esta base de datos, por qué este alojamiento, qué cambiarían, qué les daba miedo. Anote las respuestas.

8. Costo y encaje

• ¿Cuánto cuesta el sistema al mes en alojamiento, licencias y servicios de terceros?
• ¿Cuánto cuesta hoy en tiempo de ingeniería mantenerlo en marcha?
• ¿Qué necesita el negocio de él en los próximos doce meses?
• ¿Alguna parte importante atiende un caso de uso que ya no existe?
• ¿Es un sistema para conservar, para modernizar sin sustituirlo o para sustituir? La respuesta sale de las siete secciones anteriores, no de la primera reunión.

Cómo usar el resultado

Escriba las respuestas en un único documento, con una lista de los «no» ordenada por riesgo. Esa clasificación se convierte en las primeras semanas de trabajo: primero los accesos y la facturación, después las copias de seguridad y los despliegues, luego las partes frágiles y por último las que se desean. Un traspaso hecho en este orden le hace esperar una función nueva más de lo que quería, pero nunca le muestra una caída del servicio.

Si prefiere que nosotros hagamos esta revisión y después nos hagamos cargo del sistema, para eso está nuestro servicio de traspaso de software. Si prefiere hacerla usted mismo, la lista es suya.