Migramos a un cliente de hosting sen downtime: así o montamos nun fin de semana
Un cliente cunha tenda de mobles artesanais escribiunos en agosto porque o hosting que tiña desde había catro anos (contratado antes de traballar con nós) subiulle o prezo un 40% dun mes a outro, sen avisar, só unha factura distinta no correo. Decidiu marchar. O problema é que esa tenda recibe pedidos todos os días, tamén os sábados, e parar a web nin dúas horas significaba perder vendas de verdade, non unha métrica rara nun dashboard.
Migrar unha web a outro hosting sen downtime significa, na práctica, ter os dous servidores funcionando en paralelo durante o cambio e baixar o TTL dos rexistros DNS días antes, para que a propagación sexa cousa de minutos e non das 24-48 horas habituais. Esa é a resposta curta. A longa ten máis matices dos que parece a primeira vista.
O primeiro que fixemos, unha semana antes de mover nada, foi baixar o TTL de todos os rexistros a 300 segundos. Por defecto moitos provedores déixano en 3600 ou mesmo en 86400, e se cambias o DNS con ese valor posto, hai resolvers polo mundo que van seguir apuntando ao servidor vello durante case un día enteiro, por moito que xa teñas migrado. Con TTL baixo, en cinco minutos a maioría das visitas xa caían no servidor novo.
O que falla se só cambias o DNS e xa
O erro típico é preparar o servidor novo, cambiar o rexistro A, e confiar en que todo flúe só. Non flúe só. Durante a xanela de propagación, que con TTL baixo seguía sendo dun par de horas e non instantánea, tivemos tráfico caendo nos dous servidores á vez. Se o servidor vello segue recibindo pedidos mentres o novo xa ten a súa propia base de datos, acabas con vendas duplicadas ou perdidas no medio. Resolvémolo poñendo o servidor vello en modo só lectura 48 horas antes do cambio, cun aviso discreto no checkout, e sincronizando a base de datos unha última vez xusto antes de apagalo de todo.
O correo é o que casi ninguén lembra
E logo está o correo, que foi o que de verdade nos xogou unha mala pasada. Cambiamos o rexistro A pensando só na web, e esquecemos que os MX seguían apuntando ao hosting vello (cousa lóxica, porque o correo non vivía alí), pero o propio panel do hosting antigo redirixía internamente o tráfico SMTP dun xeito raro que nunca documentaramos. Durante corenta minutos os formularios de contacto non chegaron a ningún sitio. Ninguén se queixou, por sorte, pero foi o tipo de fallo silencioso que só detectas se estás mirando os logs esa mesma tarde, algo que xa facemos por sistema despois de que o día no que un hosting caeu sen avisar nos ensinase a non confiar en que “se ninguén se queixa, vai ben”.
Ao final migramos ese cliente a un dos VPS propios que xestionamos nós, con monitorización activa desde o primeiro minuto, non aos tres meses cando xa nos fiamos. Custou un sábado enteiro e dous cafés de máis, pero o luns o cliente nin sabía que cambiara de provedor.
O que me segue incomodando, meses despois, é que todo este proceso depende dunha checklist mental que temos na cabeza do equipo e en ningún sitio escrito co detalle suficiente. Cada migración lembramos algo distinto á última hora —o correo esta vez, os webhooks dun plugin de pagos a anterior—. Cantas cousas invisibles dependen aínda de que alguén se lembre xusto a tempo?