Respuesta breve
Una migración son cuatro trabajos distintos bajo un mismo nombre y fallan de forma independiente. Aquí están el inventario, el mapa de direcciones antiguas y nuevas, las redirecciones, los formularios, la ventana de cambio y el plan de vuelta atrás.
Qué se mueve realmente en una migración
Trasladar una web a otra plataforma son cuatro trabajos distintos bajo un mismo nombre: las direcciones que ya conocen las personas y los buscadores, el contenido y los archivos, los datos de formularios e integraciones, y la infraestructura sobre la que la web funciona. Fallan de forma independiente y cada uno necesita su propio plan.
La mayor parte del daño de una migración mal hecha no se ve el día del lanzamiento. La web nueva parece correcta y se aprueba; las pérdidas aparecen dos semanas después en forma de páginas que ya no responden, un formulario que dejó de entregar y una analítica que empieza de cero sin manera de comparar.
La forma de evitarlo no tiene ningún atractivo. Anotar lo que existe antes de cambiar nada, decidir a dónde va cada elemento y comprobar la lista después del cambio en lugar de fiarse de la impresión de que todo funciona.
Este artículo recorre esa lista en orden, termina con el plan de vuelta atrás que se escribe antes de necesitarlo y sitúa la migración dentro de paquetes con precio fijo, incluido el que explícitamente no cubre este trabajo.
El inventario: anote lo que existe antes de cambiar nada
Empiece por una lista completa de las direcciones de la web actual. Expórtela del mapa del sitio, de los registros del servidor, de la plataforma de analítica y de un rastreo de la web, y después combine las cuatro fuentes. Cualquiera por separado se dejará páginas, y las que se deja suelen ser antiguas que todavía reciben visitas.
Añada qué es cada dirección: una página, un archivo, una redirección que ya existe o algo que hoy devuelve un error. Conviene conocer las direcciones ya rotas antes del traslado, porque después cualquier fallo parece culpa de la migración.
Inventaríe los archivos aparte — imágenes, documentos, vídeo — indicando la carpeta de cada uno. Las rutas de los archivos cambian más a menudo que las de las páginas al cambiar de plataforma, y un documento que deja de abrirse cuesta más de notar que una página ausente.
Por último, enumere las integraciones: qué envía correo, qué recibe solicitudes, qué lee o escribe datos, qué carga un script en la página. Esta lista es la que más a menudo vive en la cabeza de alguien, y justo por eso su lugar está en un archivo.
El mapa de direcciones: una dirección antigua, una nueva
El documento central de una migración es una tabla de dos columnas: a la izquierda cada dirección antigua, a la derecha la que la sustituye. Construirla es tedioso y es lo único que decide si el traslado resulta invisible para los visitantes o no.
Cada fila necesita una decisión y solo hay tres: la página continúa en una dirección nueva, la página se fusiona con otra, o la página se retira. Retirar es una opción legítima; dejar la fila vacía no lo es, porque las filas vacías se convierten en páginas de error.
Resista la tentación de mandar a la portada todo aquello sobre lo que dude. Un visitante que pulsó un artículo concreto y aterriza en la portada ha recibido un callejón sin salida con cara amable, y los buscadores leen ese patrón como un fallo suave y no como un traslado.
Guarde el mapa como archivo en el repositorio, no como hoja de cálculo en el correo de alguien. Es el documento que releerá durante las comprobaciones posteriores al cambio y de nuevo dentro de un año, cuando alguien pregunte por qué una dirección antigua se comporta como lo hace.
Redirecciones y lo que una redirección no arregla
Una redirección permanente indica al navegador y al rastreador que una página se ha mudado para siempre. Implemente el mapa con redirecciones permanentes y no temporales salvo que el traslado sea de verdad temporal, porque se tratan de forma distinta y la diferencia no es cosmética.
Las cadenas son el coste silencioso. Una dirección que redirige a otra que vuelve a redirigir funciona, pero es más lenta para cada visitante y más débil como señal. Aplane las cadenas para que cada dirección antigua apunte directamente a su destino final.
Las redirecciones no arreglan los enlaces dentro de su propio contenido. El cuerpo de una página que enlaza a una dirección interna antigua seguirá funcionando a través de la redirección, pero ahora paga un salto que no necesita. Reescriba los enlaces internos hacia sus nuevos destinos como parte del traslado.
Y una redirección no hace nada con los enlaces externos que usted no controla. Ese es el argumento para conservar la estructura de direcciones siempre que sea razonable: cada dirección conservada es un enlace que nunca hay que redirigir y una cosa menos que se puede configurar mal.
Contenido y archivos: la parte más grande de lo que parece
El contenido rara vez se traslada limpio entre plataformas. El formato se almacena de otra manera, los archivos incrustados se referencian de otra manera y hay campos de un sistema que no tienen sitio en el otro. Reserve tiempo para revisar lo que llegó, no solo para moverlo.
Revise una muestra de verdad en lugar de ojearlo todo. Tome una docena de páginas de tipos distintos — un artículo largo, una ficha de producto, una página con tabla, una página con vídeo incrustado — y léalas enteras en la plataforma nueva.
Los archivos merecen su propia pasada. Confirme que se transfirieron, que sus direcciones están cubiertas por el mapa y que los textos alternativos sobrevivieron al traslado. El texto alternativo suele guardarse en un campo que no tiene equivalente en la plataforma nueva y se pierde en silencio, lo que es a la vez una regresión de accesibilidad y una pérdida de contenido; la referencia rápida de WCAG 2.2 del W3C es el estándar práctico contra el que comprobarlo.
Aproveche para corregir el peso de las imágenes ya que los archivos se mueven de todos modos. La documentación de rendimiento de MDN es una referencia honesta sobre lo que aquí importa de verdad, y una migración es el único momento en que tocar todas las imágenes casi no cuesta nada extra.
Formularios, integraciones y los fallos que no hacen ruido
Una página rota se anuncia sola. Un formulario roto no: acepta el envío, da las gracias al visitante y entrega el mensaje a ninguna parte. Es el modo de fallo que más cuesta y que más tarde se descubre.
Pruebe cada formulario con un envío real y confirme que llega a todos los destinos previstos: el buzón, el CRM, el canal de avisos. Pruébelos otra vez tras el cambio de DNS, porque la entrega de correo en particular puede comportarse distinto cuando el dominio se mueve.
Enumere los scripts de terceros que cargaba la web antigua y decida sobre cada uno de forma deliberada. Una migración es un buen momento para quitar aquellos cuyo propósito nadie sabe nombrar; cada uno que se queda es una petición que la página paga en cada visita.
Donde los datos van en ambos sentidos — existencias, pedidos, reservas — planifique un periodo en el que pueda verificar las dos direcciones con registros reales antes de apagar el sistema antiguo. Una comprobación en un solo sentido confirma la mitad de una integración y crea confianza en la otra mitad sin pruebas.
Analítica: mantener legible el historial tras el traslado
Decida antes del cambio si la web nueva informa a la misma propiedad de analítica o a una nueva. Conservar la propiedad conserva el historial pero mezcla dos estructuras de sitio distintas en un mismo conjunto de datos; empezar de cero da datos limpios y quita la comparación.
Elija lo que elija, marque la fecha. Una anotación el día del cambio es lo que evita que un lector futuro confunda un cambio de plataforma con un cambio de mercado, y añadirla cuesta un minuto.
Vuelva a comprobar que los eventos de los que depende siguen disparándose. Envíos de formulario, compras, descargas, clics en un número de teléfono: suelen implementarse como código ligado a la página, y ese código es exactamente lo que un cambio de plataforma reescribe.
Espere que los primeros días tras una migración se vean raros y dé tiempo a las cifras antes de sacar conclusiones. Los rastreadores revisan una web trasladada a su propio ritmo, y reaccionar a los datos de la primera semana suele producir cambios que después hay que deshacer.
DNS, certificados y la ventana de cambio
El cambio en sí es una modificación de DNS: el dominio deja de apuntar al servidor antiguo y pasa a apuntar al nuevo. Baje el tiempo de vida del registro un día antes para que el cambio se propague deprisa, y vuelva a subirlo cuando el traslado se asiente.
Tenga el certificado emitido y verificado en la plataforma nueva antes del cambio, no después. Una web que responde pero lanza un aviso de seguridad es peor que una web brevemente no disponible, porque los navegadores hacen ruidoso ese aviso y los visitantes lo leen como un compromiso de seguridad.
No mueva los registros de correo sin revisarlos. El correo y la web comparten dominio a menudo y proveedor rara vez, y una migración que se lleva por accidente los registros de correo tumba la dirección con la que responde el negocio.
Elija la ventana de forma deliberada. Las horas más tranquilas para su público, con la gente capaz de actuar todavía despierta, valen más que un momento técnicamente cómodo en el que no haya nadie para leer las primeras comprobaciones.
Visibilidad en buscadores: qué esperar y qué vigilar
Una migración bien mapeada suele producir un periodo corto de inestabilidad y no una caída duradera, pero la respuesta honesta es que el tamaño del movimiento depende de cuánto cambió la estructura de direcciones y de con cuánta amplitud la cubre el mapa.
Envíe el mapa del sitio nuevo y mantenga el antiguo accesible un tiempo para que los rastreadores encuentren las direcciones trasladadas. Las dos primeras semanas mire los informes de error y no los de posiciones: un aumento de páginas inaccesibles es accionable, una oscilación de posiciones normalmente no.
Compruebe que las páginas no están bloqueadas por instrucciones olvidadas. Los entornos de pruebas se cierran por costumbre a los rastreadores, y una regla escrita para proteger el entorno de pruebas ha viajado con más de un proyecto hasta producción y lo ha retirado en silencio de los buscadores.
Tenga el mapa a mano durante todo ese periodo. Casi cualquier problema que se reporte el primer mes se reduce a una de sus filas: vacía, apuntando a la página equivocada o escrita con una errata.
El plan de vuelta atrás, escrito antes de necesitarlo
Antes del cambio, escriba cómo volver: qué registros DNS restaurar, cuánto tiempo sigue disponible el entorno antiguo, quién puede tomar la decisión y qué situación la justificaría. Tres frases bastan y cambian cómo se vive el día.
Mantenga la web antigua funcionando y accesible en segundo plano durante un periodo definido tras el traslado. Cuesta un mes más de alojamiento y es la diferencia entre un mal día y una mala semana.
No borre nada el día del cambio. Bases de datos, carpetas de archivos y la configuración antigua deben sobrevivir al traslado durante un periodo fijado de antemano, porque lo que falta suele anunciarse tras la primera semana completa de tráfico.
Nombre en el plan a quien decide. Las decisiones de vuelta atrás tomadas en grupo, con prisa y con información incompleta son la manera de convertir un problema recuperable en dos migraciones en lugar de una.
Comprobaciones antes del cambio y después
Antes del cambio, pase la web nueva por las mismas comprobaciones que hará después: cada plantilla abre, los formularios envían, el buscador funciona, las páginas cargan en móvil, la estructura de direcciones coincide con el mapa. Hacerlo en el entorno de pruebas elimina la mayoría de las sorpresas.
Después del cambio, ejecute el propio mapa. Solicite cada dirección antigua y registre qué devuelve. Esto es un script y no una tarde de clics, y convierte la pregunta de si la migración funcionó en una lista de filas que no funcionaron.
Revise las páginas fáciles de olvidar: las legales, las enlazadas solo desde el pie, los archivos enlazados desde una campaña de correo y todo lo que tenga una dirección escrita a mano en lugar de generada.
Y vuelva a revisarlo una semana después. Algunos fallos solo aparecen cuando caducan las cachés y regresan los rastreadores, y una segunda pasada por la misma lista es una manera barata de cazarlos mientras el contexto sigue fresco.
Dónde encaja una migración en los paquetes de VITON13
Conviene ser directo con el alcance, porque una migración se presupuesta a menudo como si fuera una corrección menor. Site Fix Pack cuesta $70 y ocupa 1-2 días laborables para un máximo de cinco correcciones acordadas, con revisión en móvil y escritorio, una lista de antes/después en la entrega y una ronda de revisiones — y las migraciones figuran explícitamente como no incluidas.
Un traslado que produce una web nueva corresponde a Sitio para lanzamiento: $380 en 3-5 días laborables por una construcción adaptable, conexión del CMS o de los datos básicos y configuración del despliegue, con dos rondas de revisiones antes del lanzamiento; el contenido y las traducciones los aporta usted. Launch Site Express son $520 y entrega ese mismo alcance en cola prioritaria en 2 días laborables con compilaciones diarias, una lista de comprobación de lanzamiento y una llamada de entrega, con una ronda de revisiones tras la primera construcción completa y sin contenido, fotografía ni soporte posterior.
Cuando el traslado además cambia lo que hace el producto — funcionalidades nuevas, lógica de estados y rutas, pruebas y endurecimiento — corresponde a Desarrollo de producto: $880 en 2-3 semanas con dos rondas de revisiones por funcionalidad entregada, y con las aplicaciones móviles nativas y las licencias de pago fuera del alcance.
Las semanas posteriores al cambio son justo donde Soporte técnico continuo se gana su sitio: $290 al mes en ciclo mensual con 30 días de preaviso para detenerlo, con actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico; el volumen se acuerda al inicio de cada ciclo y una construcción nueva o un rediseño se presupuestan aparte.
Lista práctica
- Construya la lista de direcciones desde el mapa del sitio, los registros, la analítica y un rastreo, y combine las cuatro.
- Escriba la tabla de dirección antigua a dirección nueva y no deje ninguna fila vacía.
- Aplane las cadenas de redirección para que cada dirección antigua apunte directamente a su destino final.
- Envíe una solicitud real por cada formulario y verifique cada destino tras el cambio de DNS.
- Baje el tiempo de vida del DNS un día antes y emita el certificado antes del cambio.
- Escriba el plan de vuelta atrás y el periodo durante el cual el entorno antiguo sigue accesible.
Preguntas frecuentes
¿Perderá posiciones la web al cambiar de plataforma?
Una migración bien mapeada suele producir un periodo corto de inestabilidad y no una caída duradera. El tamaño del movimiento depende de cuánto cambió la estructura de direcciones y de con cuánta amplitud la cubre el mapa de redirecciones, y por eso el mapa es la protección principal.
¿Entra una migración en el paquete de correcciones pequeñas?
No. Site Fix Pack cuesta $70 en 1-2 días laborables para un máximo de cinco correcciones acordadas, y las migraciones figuran explícitamente como no incluidas. Un traslado que produce una web nueva corresponde a Sitio para lanzamiento por $380 en 3-5 días laborables, o a Launch Site Express por $520 en 2 días laborables.
¿Puedo redirigir todas las direcciones antiguas a la portada?
Técnicamente sí, y es una mala decisión. Un visitante que pulsó un artículo concreto y aterriza en la portada recibe un callejón sin salida, y los buscadores leen una redirección masiva a la portada como un fallo suave y no como un traslado.
¿Cuánto tiempo debe seguir en pie la web antigua?
Fije el periodo de antemano y no borre nada el día del cambio. Bases de datos, carpetas de archivos y la configuración antigua deben sobrevivir al traslado durante ese periodo declarado, porque lo que falta suele anunciarse tras la primera semana completa de tráfico.
¿Qué se rompe de forma más silenciosa en una migración?
Los formularios y las integraciones. Un formulario acepta el envío, da las gracias al visitante y entrega el mensaje a ninguna parte. Pruebe cada formulario con un envío real antes y después del cambio de DNS y confirme que llega a todos los destinos: buzón, CRM y canal de avisos.