El barco de Teseo: migrar una web sin que deje de ser la misma

Una web lleva cinco años en producción. El tema está anticuado, el editor visual pesa como un armario y nadie se atreve a actualizar nada. Alguien dice la frase que abre todos estos proyectos: hay que rehacerla.

La pregunta que nadie formula en esa reunión es la importante: cuando terminemos, ¿será la misma web?

El barco que los atenienses no dejaban morir

Plutarco cuenta en su Vida de Teseo que los atenienses conservaron, hasta los tiempos de Demetrio de Falero, el barco con el que el héroe volvió de Creta. Cuando una tabla se pudría, la quitaban y ponían una nueva. Con el tiempo no quedó ni una pieza original, y los filósofos de la época lo usaban como ejemplo de discusión: unos decían que seguía siendo el mismo barco; otros, que ya era otro.

Siglos más tarde, en 1655, Thomas Hobbes le dio la vuelta de tuerca que lo vuelve incómodo. Supón que alguien recoge las tablas viejas según las van quitando y, con ellas, monta un segundo barco. Ahora hay dos. Uno en el puerto, con todas las piezas nuevas, que nunca dejó de navegar. Otro en un almacén, hecho entero con la madera original. ¿Cuál es el barco de Teseo?

Cualquiera que haya vivido una migración conoce los dos barcos.

La identidad de una web no está en su código

Para el visitante, para Google y para el propio negocio, una web es un contrato con el exterior:

• Las direcciones que Google tiene indexadas y que alguien guardó en favoritos.
• Los enlaces que otras webs le apuntan desde hace años.
• El formulario que llega al buzón de siempre y el correo que no se puede caer.
• Lo que el cliente habitual espera encontrar donde siempre estuvo.

Eso es el barco. El código son las tablas. Puedes cambiar todas las tablas, incluido el lenguaje en el que están escritas, y la web sigue siendo la misma si el contrato se mantiene. Y al revés: puedes conservar hasta la última línea de código y romper la identidad en una tarde, cambiando las rutas sin redirigirlas.

El primer barco: cambiar tablas sin dejar de navegar

El barco de Plutarco nunca salió del agua. Esa es la clave del método, y en software tiene nombre: Martin Fowler lo llamó la higuera estranguladora, por las higueras que crecen enredadas en un árbol hasta ocupar su lugar.

En una web se traduce así. El sistema nuevo envuelve al viejo y empieza a responder primero por una parte: la cabecera y el pie, o la portada. El resto de páginas sigue saliendo del sistema antiguo, dentro del envoltorio nuevo. Después se migra una página, y otra. Cada paso se despliega por separado, cada paso se puede deshacer, y en ningún momento hay un día D en el que todo cambia a la vez.

Tiene un precio, y conviene decirlo: durante meses conviven dos sistemas. Hay páginas que son mitad nuevas y mitad viejas, y la web no está nunca “terminada”. Es incómodo de mirar. Pero el barco navega todo el tiempo, y si una tabla nueva sale mala, se nota en esa tabla y no en el barco entero.

El segundo barco: la reescritura en el almacén

La alternativa es la de Hobbes: construir la web nueva aparte, completa, y el día del lanzamiento cambiar una por otra.

En la reunión suena más limpio. Sin herencias, sin convivencia, empezando de cero. El problema aparece el día del cambio, porque ese día hay dos barcos y hay que decidir cuál es el de verdad. Y casi nunca se decide: se descubre. Se descubre que las rutas nuevas tienen otro nombre y nadie preparó las redirecciones. Que el formulario apuntaba a un buzón que ya no existe. Que una página que nadie recordaba traía la mitad de las visitas desde Google. Que la web vieja seguía haciendo algo que nadie sabía que hacía.

El código nuevo suele estar mejor que el viejo. Lo que falla es el supuesto de partida: tratar la identidad como si estuviera en las tablas. Por eso se queda en el almacén, junto con la madera vieja.

Cuándo el almacén sí tiene sentido

No es una regla absoluta. A veces el barco no admite reparación: el casco está podrido, el sistema viejo no se deja envolver, o el contrato con el exterior es tan pequeño que se puede copiar entero en un folio. Una web de cinco páginas sin tráfico orgánico se reescribe sin drama.

Lo que decide es el tamaño del contrato, mucho más que el del código. Cuantas más direcciones indexadas, enlaces externos, integraciones y costumbres de usuario acumula una web, más caro es el día D y más sentido tiene cambiar tablas en el agua.

En el río y la piedra el argumento era que una aplicación tiene que decidir qué fluye y qué permanece. Una migración es esa misma decisión a escala de toda la web: el código fluye, el contrato se queda quieto.

Antes de tocar la primera tabla

Tres cosas, por orden:

• Inventariar el contrato. Todas las URLs que existen y las que reciben visitas, los formularios y adónde llegan, los subdominios y el correo. Lo que no está en esa lista es lo que se rompe el día del cambio.
• Decidir qué no va a cambiar. Las direcciones, sobre todo. Si alguna tiene que cambiar, cada una lleva su redirección permanente desde el primer día, no “cuando haya tiempo”.
• Dejar escrito cómo se vuelve atrás. Una copia completa antes de empezar y el procedimiento para restaurarla. Un plan de vuelta atrás que no está escrito no existe.

Plutarco no resolvió la paradoja, y probablemente no tenga solución. Pero los atenienses tampoco la necesitaron: cuidaron el barco tabla a tabla durante siglos y nadie dejó de reconocerlo. En una web pasa lo mismo. Que siga siendo la misma depende de una sola cosa: que nadie de fuera note el día en que dejó de ser la vieja.