Cómo migrar tu web desde otro constructor paso a paso
Migrar no es mover archivos, es reconstruir. Se describe la web que ya tienes, se construye la nueva versión, se copian los textos y las imágenes que quieres conservar, se comprueba y se cambia el dominio al final. El contenido viaja, la maquetación del constructor anterior no. Una construcción tarda alrededor de un minuto.
Esa frase corta esconde el motivo real: cada constructor guarda las páginas en su propio formato interno, y no existe un exportador universal entre plataformas. Lo que se transporta es lo que escribiste, no cómo se veía.
¿Qué se puede llevar y qué hay que rehacer?
Conviene saberlo antes de empezar, porque determina cuántas horas es la mudanza. La regla general es que el contenido se lleva y el sistema se rehace.
| Qué tienes | ¿Viaja? | Cómo |
|---|---|---|
| Textos de las páginas | Sí | Copiar y pegar, o dárselos al prompt |
| Imágenes y vídeos | Sí | Descargar del sitio antiguo y volver a subir |
| Dominio propio | Sí | Se apunta al proyecto nuevo, en los planes de pago |
| Entradas de blog | Sí, con trabajo | Una por una, o exportando el contenido |
| Diseño exacto | No | Se reconstruye a partir de una descripción |
| Formularios y sus envíos | Parcial | El formulario se rehace, los envíos se exportan |
| Base de clientes o pedidos | Depende | Exportar del sistema anterior e importar al tuyo |
| Suscripciones activas de pago | Sí, con cuidado | Viven en tu cuenta de Stripe, no en el constructor |
Las dos últimas filas son las que deciden si la migración es de una tarde o de una semana. Si vendes por suscripción, los cobros viven en tu propia cuenta de Stripe y no dependen del constructor, pero cualquier cambio en el flujo hay que probarlo con un cobro real antes de apagar nada.
Y sé realista con el diseño. Reproducir píxel a píxel una plantilla anterior es el objetivo equivocado: normalmente migras porque algo no te servía, así que aprovecha para simplificar en lugar de calcar.
¿En qué orden se hace para no caerse?
En un orden que deja el sitio antiguo funcionando hasta el último momento. Nunca se empieza cambiando el dominio.
Primero construye la versión nueva en la dirección temporal del proyecto, que en Zugo es una dirección terminada en zugo.run. Ahí trabajas con calma mientras tu web actual sigue en pie y nadie nota nada.
Segundo, copia el contenido. Textos, imágenes, precios, datos de contacto. Este es el paso más aburrido y el que más errores esconde, así que hazlo página por página y ve marcando.
Tercero, comprueba: en un móvil de verdad, con todos los enlaces, con el formulario enviándose de verdad y con el pago en modo de prueba si vendes. Cada construcción de Zugo se arranca en un sandbox antes de entregarse y una que no abre no se entrega, y eso no comprueba que tu teléfono esté bien escrito.
Cuarto, apunta el dominio a la web nueva y espera a que el cambio se propague. Quinto, y solo entonces, cancela el plan anterior. El orden inverso, que es el que la prisa sugiere, es como se pierde una web durante dos días.
Deja pasar al menos una semana entre el cambio de dominio y la cancelación. Es barato y te da margen para volver atrás si aparece algo que nadie vio: un enlace roto, un correo que dejó de llegar, una página que solo usaba un cliente concreto.
Elige también el momento. Migrar un viernes por la tarde o en plena campaña alta es multiplicar el coste de cualquier problema por el peor momento posible para resolverlo.
¿Qué pasa con las direcciones y el posicionamiento?
Es la parte técnica que más daño hace si se ignora. Si tus páginas antiguas tenían direcciones concretas y las nuevas son distintas, cada enlace que alguien guardó o que otra web te puso deja de funcionar.
Haz una lista de las direcciones que ya reciben visitas antes de migrar y reprodúcelas en el sitio nuevo. Si alguna cambia por fuerza, configura una redirección de la antigua a la nueva para que ni las personas ni los buscadores se topen con un error.
Es normal ver una bajada temporal en los buscadores tras una migración, incluso bien hecha. Se recupera si las direcciones se mantienen y el contenido sigue siendo el mismo o mejor, y se recupera mal si aprovechaste para recortar textos que estaban funcionando.
Una comprobación rápida que evita sorpresas: mira qué páginas del sitio antiguo reciben más visitas y trátalas como intocables. La guía de SEO en webs hechas con IA explica qué depende de la herramienta y qué depende de ti.
¿Cuánto cuesta migrar en créditos?
Depende del tamaño del sitio, y el cálculo es sencillo porque los precios son fijos. Una web de una página es una construcción; una de varias páginas es una plataforma multipágina.
| Acción | Créditos |
|---|---|
| Edición por chat | 3 |
| Construcción de una página | 6 |
| Plataforma multipágina, primeras tres páginas | 12 |
| Cada página a partir de la tercera | 3 |
| Edición en modo Hi-Fi | 6 |
| Construcción en modo Hi-Fi | 12 |
Un ejemplo con números reales: una web de seis páginas cuesta 12 por las tres primeras más 9 por las tres siguientes, es decir 21 créditos, y después cada ajuste son 3. El plan gratuito da 5 créditos, insuficiente para una migración; Pro son 25 dólares al mes con 200 créditos y Business, 99 dólares al mes.
Compáralo con lo que pagas ahora. Si migras por precio, haz la cuenta completa incluyendo lo que cuesta el dominio y los complementos en tu plataforma actual, no solo la cuota base.
Añade a la cuenta tu propio tiempo. Copiar el contenido de una web mediana son varias horas de trabajo tedioso, y ese coste es real aunque no aparezca en ninguna factura. Si la diferencia anual entre las dos plataformas es pequeña, esas horas pueden inclinar la decisión hacia quedarte donde estás.
¿Merece la pena migrar?
No siempre, y decirlo importa. Si tu web actual funciona, la mantienes sin esfuerzo y no te estorba, migrar es trabajo sin retorno. Las razones válidas son concretas.
Te has topado con un techo. Querías algo que la herramienta no contempla y no hay salida. Ese es el motivo más habitual y el más sólido, porque no se arregla esperando.
Quieres el código. Un proyecto en Zugo se exporta a GitHub como un repositorio normal y es tuyo, lo que significa que un programador puede continuarlo en cualquier momento. La guía de exportación explica cómo funciona.
El coste no encaja. Si pagas por funciones que no usas, el cambio se paga solo. Si pagas poco y estás contento, no.
Y el límite honesto en la dirección contraria: Zugo no sustituye a un equipo de desarrollo en un producto complejo. Si tu sitio actual es un sistema con integraciones profundas y lógica peculiar, migrarlo con prompts te llevará lejos y el último tramo será programación. Comparativas concretas con otras plataformas, como la comparación con Wix, ayudan a decidir antes de mover nada.
Construye la versión nueva en paralelo, sin tocar tu dominio, en zugo.dev y compárala con la que tienes.