La aplicación funciona. Por eso nadie ha mirado esto nunca.
Quien la construyó ya no está. Un freelance que dejó de contestar, un empleado que se fue, una empresa que cerró. Como no se ha roto nada, no hay urgencia; como no hay urgencia, no se hace. Y un día se muere un disco, caduca un certificado o el negocio necesita un cambio que no puede esperar, y una situación tranquila se convierte en una cara en una tarde.
Esto va para una empresa de cinco a cincuenta personas con una aplicación de la que depende la operación: un ERP, una intranet, una web a medida, un programa de escritorio contra una base de datos central. No es una auditoría técnica y no hace falta un informático. Es un inventario y se hace en cuatro tardes.
Hazlo mientras no esté roto nada. Todo lo que viene es barato este mes y caro la semana que falle algo.
La regla: tienes lo que puedes demostrar
Cuando se pregunta por esto, las respuestas suelen ser del tipo «el código lo tendrá la empresa que lo hizo» o «creo que las copias se hacen por la noche». Eso son creencias. En un inventario, una creencia cuenta como un no.
Hay una sola regla y sostiene el mes entero. Apunta una respuesta solo cuando la hayas visto tú. No lo que te han dicho. No lo que dice un documento de 2019. Lo que has abierto, descargado, o has visto ocurrir delante.
Parece quisquilloso durante un día. A partir del segundo empieza a encontrar cosas.
Semana uno: el código fuente
El código es lo único de esta lista que no se puede reconstruir. Todo lo demás se rehace con tiempo y dinero. Se empieza por aquí.
Buscas una prueba concreta: una copia del código en una máquina de la empresa, puesta ahí por ti. No un enlace. No la palabra de nadie. Una carpeta que puedas abrir.
Dónde aparece, más o menos por orden de frecuencia:
- Una cuenta de alojamiento de código: GitHub, GitLab, Bitbucket, Azure DevOps. Busca el correo al que llega la factura antes que el nombre de la cuenta; quien paga es la puerta de entrada.
- El propio servidor de producción. Muchas aplicaciones pequeñas se desplegaron copiando ficheros, y la copia que está funcionando es la única que hay.
- Facturas y correos antiguos. Las entregas se mandaron como adjunto y llevan años en un buzón.
- Un portátil en un armario. Vale la hora que cuesta mirarlo.
Si aparece, cópialo hoy a un sitio tuyo y comprueba que la copia abre. Si la empresa no tiene cuenta de alojamiento de código, este es el momento de abrirla a nombre de la empresa y meterlo ahí. Es una gestión pequeña ahora y un proyecto más adelante.
Si el código no existe de verdad, deja de buscar a la semana y dilo en voz alta, porque cambia lo que tienes. Ya no es una aplicación: es un aparato. Se puede ejecutar, configurar, copiar, mover a otro servidor y consultar su base de datos. No se puede cambiar por dentro. Cualquier cosa que el negocio quiera hacer distinta a partir de ahora es una reconstrucción con su propio presupuesto, y saberlo hoy es mucho mejor que descubrirlo en marzo, con prisa.
Semana dos: sigue el dinero
La forma más rápida de inventariar de qué servicios depende una aplicación no es técnica. Es el extracto de la tarjeta de empresa y el listado de proveedores, doce meses, línea por línea.
Cada cargo recurrente es una cuenta. Cada cuenta tiene un dueño, un usuario y un correo de recuperación. Apunta los tres.
De ahí salen dos cosas que no aparecen por ningún otro camino.
Cargos que nadie sabe explicar. Un alojamiento, una herramienta de monitorización, un servicio de envío de correo, la renovación de un dominio en un registrador del que nadie ha oído hablar. Eso son piezas de tu sistema.
Servicios que no cuestan nada. Son los peligrosos, precisamente porque no salen en ningún extracto: un plan gratuito, una clave de API, un buzón, una cuenta de DNS, una tarea programada en el ordenador de alguien. Estos se encuentran mirando qué manda y qué recibe la aplicación —facturas por correo, SMS, cobros con tarjeta, ficheros que van a un cliente— y preguntando por dónde pasa cada cosa.
Y luego está el que va por delante de todos: el dominio. Averigua a nombre de quién está registrado y qué dirección de correo lo controla. Quien controla el dominio controla el correo, y quien controla el correo recupera la contraseña de casi todo lo demás. Un dominio a nombre de alguien que ya no trabaja contigo es lo único de esta lista por lo que merece la pena interrumpir otro trabajo.
Un aviso, porque es la manera clásica de convertir este mes en una incidencia. No empieces cambiando contraseñas. Las credenciales de un sistema en marcha las usan cosas que nadie recuerda, y una rotación hecha antes de terminar el inventario tira tu propia aplicación un martes por la tarde. Primero el inventario. Después se cambian a propósito, de una en una, en un hueco y con alguien mirando.
Semana tres: una copia restaurada que hayas visto
Si preguntas si hay copias de seguridad, la respuesta casi siempre es que sí. Casi siempre es verdad y casi nunca basta.
La prueba es estrecha y no se negocia: una copia restaurada en un sitio que no sea producción, abierta, con un registro que reconozcas, en una fecha que puedas decir. Hasta que eso ha pasado, lo que la empresa tiene es una tarea programada, no una copia.
Ya que estás, tres preguntas que deciden si la restauración sirve de algo:
- ¿Hasta cuándo llega hacia atrás? Una copia que guarda los dos últimos días te salva de que se rompa un disco. No te salva de un problema que se descubre tres semanas después, que es lo que pasa más a menudo.
- ¿Incluye los ficheros? La base de datos se copia porque es lo evidente. Los documentos subidos, los albaranes escaneados, los PDF firmados y las fotos suelen vivir en el disco del servidor y muchas veces no están en la copia.
- ¿Hay una copia fuera de esa máquina y fuera de esa cuenta? Una copia guardada en el mismo sitio que el sistema al que protege cubre bastantes menos desastres de los que la gente supone.
Aprovecha y apunta las fechas de caducidad en la misma página: el dominio, los certificados, cualquier licencia que haya que renovar. Llévalas al calendario de la empresa con el nombre de una persona al lado. Es la única parada de este artículo que viene con la fecha impresa, y aun así se sigue escapando todos los años.
Semana cuatro: lo que está en la cabeza de alguien
A esta parte se la suele llamar documentación, y por eso no se hace nunca. Nadie escribe cuarenta páginas y nadie las lee.
Tres cosas merecen estar escritas, y las tres son cortas.
Cómo se despliega. Qué tiene que pasar para que un cambio llegue al sistema que la empresa usa. Si la respuesta honesta es que una persona concreta hacía algo en su portátil, escribe esa frase. Es una respuesta verdadera y útil, y le dice al siguiente proveedor a qué se enfrenta.
Qué falla de forma rutinaria y qué hace alguien cuando falla. Toda aplicación con años tiene dos o tres: el servicio que hay que reiniciar, el informe que revienta a fin de mes, la integración que se cae después de un puente. Ese conocimiento vive en quien lo reinicia y se va con él.
Quién más la ha tocado alguna vez. Un segundo nombre y un teléfono, aunque sea lejano. Quien cubrió unas vacaciones, la empresa que hizo la integración, el informático de la gestoría que montó el servidor. El día malo, uno de esos teléfonos vale más que cualquier manual.
Y la parte que no es técnica en absoluto: ponle a la aplicación un responsable dentro de la empresa, con nombre y apellido. No hace falta que programe. Hace falta que sepa dónde está, quién la toca y a quién se llama. Sin esa persona, cualquier proveedor nuevo empieza haciendo arqueología, y la arqueología se factura por horas.
Lo que sale de aquí: una página
Al final del mes el resultado no es un informe. Es una página, y dice:
- dónde está el código y dónde está la segunda copia;
- de qué cuentas depende el sistema, a nombre de quién está cada una y qué correo la controla;
- cuándo se restauró una copia por última vez y quién lo hizo;
- qué tiene que pasar para desplegar un cambio;
- a quién se llama, por orden.
Guárdala donde la empresa guarda los seguros y las escrituras, no dentro del sistema que describe. Imprímela. Una página de continuidad que solo vive dentro de la aplicación a la que protege tiene un defecto evidente.
Se revisa cuando cambia algo: proveedor nuevo, cambio de servidor, alguien que se va. Veinte minutos, no un proyecto.
Lo que no hay que hacer este mes
No reescribas nada. Una reescritura decidida con el inventario a medias es una decisión tomada por incomodidad. La mayoría de estas aplicaciones no hay que sustituirlas: hay que hacerlas conocibles.
No cambies credenciales antes de terminar. Ya está dicho arriba, y es el error que más veces se comete.
No le escribas a quien se fue pidiéndole «todo». Es tan vago que es fácil de ignorar. Mándale una lista numerada de tres cosas concretas —una copia reciente de la base de datos, acceso de lectura al código, la lista de servicios y a nombre de quién está cada uno—, con una fecha y ofreciéndole pagar la hora que le cueste. Casi todo el mundo contesta a eso. Y mándalo mientras la relación siga siendo neutra: la misma petición en medio de un conflicto deja de ser una gestión y pasa a ser una negociación.
Por qué ahora
Nada de esto mejora la aplicación. La hace sobrevivible, que es un objetivo distinto y más barato.
Una aplicación que nadie sabe explicar no es un problema técnico. Es un activo que la empresa no puede demostrar que tiene. Y esa diferencia se nota el día que quieres cambiar de proveedor, vender la empresa, pasar una auditoría o simplemente conseguir un cambio en una semana en vez de en un trimestre.
Si haces el inventario y te atascas —el código no aparece, las copias no se han restaurado nunca, nadie sabe decir cómo se despliega—, cuéntanos qué has encontrado en nordicbyte.co.uk/get-started. Qué aplicación es, a qué tienes acceso y a qué no. En 48 horas te decimos qué se puede recuperar, en qué orden y qué haríamos primero.
Y si haces las cuatro tardes y sale todo bien, mejor. Saberlo cuesta cuatro tardes. Descubrirlo el día malo cuesta bastante más.