¿Vienes a Server Manager desde otro alojamiento? El asistente Importar desde otro alojamiento inicia sesión en tu servidor antiguo, lo escanea en busca de sitios WordPress, sitios estáticos y bases de datos, y luego copia uno de ellos como un paquete .tar.gz. Después, ese paquete pasa al asistente de restauración, que instala el servicio en este servidor con tu aprobación en cada paso.
El origen es de solo lectura. No se modifica nada en tu alojamiento anterior. El asistente escanea, copia lo que necesita y se desconecta. Puedes volver a ejecutarlo más tarde para migrar otro sitio.
¿Qué puedo migrar?
El asistente reconoce tres tipos de “cosas que mover”:
| Tipo | Qué encuentra | Qué acaba aquí |
|---|---|---|
| Sitio WordPress | Un wp-config.php + una base de datos a la que puede acceder (rellena las credenciales automáticamente si puede leerlas) | Instalación completa de WordPress en contenedores, con una base de datos nueva y tus medios, plugins y temas restaurados |
| Sitio estático | Una raíz de documentos con index.html (bajo /var/www/, /home/<user>/public_html/, estructuras habituales de cPanel…) | El árbol de archivos bajo /var/www/<your-new-domain>/, servido por Caddy |
| Base de datos | Una instancia MySQL / MariaDB accesible desde el inicio de sesión SSH del origen | Un contenedor de base de datos nuevo con una copia restaurada mediante mysqldump |
No migra: aplicaciones web arbitrarias (frameworks Node/Python/PHP más allá de WordPress; para eso usa Desplegar desde un repositorio git), correo/buzones, registros DNS ni nada que quede fuera de las convenciones estándar de webroot/base de datos.
Cómo acceder a tu alojamiento anterior: SSH o cPanel
El asistente admite dos formas de conectarse:
| Tipo de origen | Cuándo elegirlo |
|---|---|
| Inicio de sesión SSH | Tienes acceso a la shell (el mismo inicio de sesión que usarías con el comando ssh). La mayoría de proveedores de servidores te lo dan por defecto. |
| API de cPanel | Solo tienes cPanel y no SSH (habitual en alojamiento compartido). Usa el token de API propio de cPanel en lugar de un inicio de sesión Linux. |
Si no lo tienes claro, prueba primero con SSH: es la vía con menos fricción. Cambia de pestaña si la conexión falla o si tu alojamiento solo ofrece cPanel.
Recorrido paso a paso
Barra superior → menú → Importar desde otro alojamiento.
Elige el tipo de origen, rellena las credenciales y haz clic en Escanear el origen.
El modo Inicio de sesión SSH necesita: host (IP o dominio del servidor antiguo), puerto (normalmente 22), nombre de usuario (root, ubuntu, tu usuario de cPanel, etc.) y una contraseña o una clave privada OpenSSH. ¿Ya tienes esas mismas credenciales guardadas como servidor en Server Manager? Haz clic en Usar credenciales de un servidor guardado para rellenarlas desde ahí.
El modo API de cPanel necesita: la URL completa de cPanel (incluido el puerto; normalmente https://your-domain:2083), tu nombre de usuario de cPanel y un token de API. Obtén el token en cPanel → busca "Manage API Tokens" → Create. cPanel solo lo muestra una vez, así que cópialo y pégalo enseguida.
Qué hace el asistente con las credenciales. Solo permanecen en esta sesión del navegador y se envían por HTTPS directamente al origen. No las escribimos en disco en este servidor ni las guardamos entre ejecuciones del asistente.
El asistente inicia sesión en el origen y recorre sus rutas web/de bases de datos habituales durante unos 10–30 segundos, agrupando por tipo todo lo que reconoce.
Elige un elemento para migrar en esta ejecución (todavía no hay selección múltiple; vuelve a abrir el asistente para el siguiente). La tarjeta seleccionada queda marcada con un borde melocotón.
Si el escaneo no devuelve nada, el asistente te indica qué raíces comprobó y cualquier aviso (errores de permisos, wp-config ilegible, etc.). Ajusta las credenciales del origen o la estructura de rutas si el elemento que falta está en una raíz no estándar.
Este paso varía según el tipo:
- WordPress → elige el dominio donde se alojará el sitio migrado (puede ser el mismo que antes —cambiarás el DNS después— o uno totalmente nuevo) y confirma las credenciales de la BD (rellenadas desde
wp-config.phpsi puede leerse). - Sitio estático → opcionalmente, elige un dominio. Déjalo en blanco para servirlo por ahora desde la IP de tu servidor; podrás asociar un dominio más tarde desde el panel del servicio.
- Base de datos → elige un título para la nueva base de datos en este servidor y, en casos poco habituales, sobrescribe las credenciales de
mysqldump.
Haz clic en Iniciar la importación.
Server Manager extrae los datos del origen y monta en este servidor un paquete con formato de Server Manager. Las líneas de progreso se actualizan en tiempo real (creando archivo, transfiriendo, calculando hashes, etc.). En el origen solo se hacen lecturas: sin escrituras y sin dejar archivos temporales.
No cierres el diálogo a mitad de la importación. Si lo haces, se abortará la transferencia en curso y tendrás que empezar de nuevo. La limpieza se hace automáticamente: los archivos parciales en /tmp/helm-restore/ de este servidor se eliminan en un plazo de 24 horas, o puedes limpiarlos al momento desde la pantalla de error si algo falla.Cuando el paquete está listo, el modal de migración se cierra y se abre el asistente de restauración con el paquete recién llegado ya preseleccionado. Es el mismo modal que usa el flujo Mover a otro servidor al llegar al destino, con el mismo botón de un clic Restaurar este paquete.
Haz clic en Restaurar este paquete y el chat toma el relevo: Faro lee el manifiesto, inicia la instalación en este servidor y se pausa para pedirte aprobación en cada comando: docker compose up, la edición del Caddyfile, el wp search-replace si cambió el dominio, etc.
Cuando termina, el sitio migrado aparece como una tarjeta de carga de trabajo en tu pantalla de inicio, igual que cualquier otra cosa que hubieras desplegado aquí de forma nativa.
Si usaste un dominio nuevo para el destino, ya está: Caddy emite un certificado TLS para él en unos ~30 s y el sitio queda publicado.
Si usaste el mismo dominio que en el alojamiento anterior, la migración se hizo contra la IP de tu servidor antiguo. Para mover el tráfico, actualiza el registro A en tu proveedor de DNS para que apunte a este servidor. Dentro del tiempo de propagación DNS (normalmente 1–10 min), el tráfico pasará a la copia migrada y Caddy renovará el certificado bajo la nueva IP automáticamente. La instalación antigua en el origen seguirá sirviendo el mismo dominio hasta que el DNS se propague; puedes apagarla en el origen cuando estés conforme con la migración.
Aviso sobre DNS en la pantalla final. El asistente muestra un aviso si el dominio de destino aún no apunta aquí: Caddy no puede obtener un certificado HTTPS hasta que el DNS se propague. El paso de restauración también se detiene y te avisa si el DNS todavía no está configurado.
Preguntas frecuentes
¿Mi sitio estará caído durante la migración? No: el origen sigue sirviendo tráfico todo el tiempo. La migración solo copia. Solo tendrás una interrupción en el momento en que cambies el DNS (o nunca, si usas un dominio nuevo en el servidor nuevo).
¿Qué pasa con los plugins / temas / código personalizado en WordPress? Van incluidos. La migración captura los archivos de WordPress (temas, plugins, subidas) Y la base de datos en una instantánea coherente. Después de restaurarlo, el sitio se comporta igual: mismo contenido, mismas URL (o URL reescritas si elegiste un dominio distinto).
Mi base de datos es más grande que el espacio libre en disco del origen. Así no funcionará: mysqldump necesita temporalmente espacio de trabajo en el origen equivalente al tamaño del volcado. Libera espacio primero en el origen o migra manualmente mediante volcados SQL (descarga el volcado → súbelo aquí con Restaurar desde una copia de seguridad).
¿Puedo migrar desde algo que no sea SSH/cPanel? Hoy, no: la lógica de escaneo/sondeo solo conoce esas dos vías. Para otros paneles (Plesk, DirectAdmin, etc.), el camino es: entra por SSH en el origen manualmente, empaqueta tu webroot con tar, vuelca tu base de datos con mysqldump, crea un .tar.gz que coincida con la estructura de paquete de copia de seguridad e impórtalo con Restaurar desde una copia de seguridad. Si necesitas la especificación exacta del formato del paquete para crearlo a mano, escríbenos desde Contacto y te la compartimos.
¿Qué pasa si la migración falla a mitad de camino? La pantalla de error ofrece un botón de un clic Limpiar ahora que elimina cualquier directorio de preparación escrito parcialmente bajo /tmp/helm-restore/. En el origen no se ha modificado nada. Puedes volver a ejecutar el asistente desde el principio sin riesgo.
¿Sobrescribirá un sitio existente en este destino? Solo si lo aceptas explícitamente en el paso de restauración. De forma predeterminada, en el traspaso al chat se instala en paralelo: elegirías "clonar a dominio nuevo" (o, para bases de datos, "clonar junto a la existente" con un sufijo) si ya hay una carga de trabajo en el dominio de destino.
¿Queda algo en el origen después de la migración? Ningún artefacto añadido por nosotros. El asistente solo hace llamadas de lectura; lo único que escribe en el origen es mysqldump (en migraciones de WordPress + base de datos), que genera un archivo que el asistente descarga y elimina de inmediato. Después de que el asistente se desconecta, el origen queda en el mismo estado que antes.
Secretos: ¿se reutilizan o se rotan? La contraseña de BD de wp-config.php se usa para ejecutar mysqldump en el origen y luego se descarta. El sitio restaurado arranca con credenciales de base de datos nuevas generadas durante el traspaso al chat: no se filtra ninguna credencial del origen a la nueva instalación.
Qué NO entra aquí
- Restauración de paquete a paquete (ya tienes un
.tar.gzexportado desde otro sitio) → ve directamente a Restaurar desde una copia de seguridad. - Movimiento de servidor a servidor dentro de Server Manager (origen + destino están gestionados por Helm) → consulta Copias de seguridad → Mover a otro servidor. Esa vía es más eficiente: sin paso de sondeo y sin reconstrucción de manifiesto.
- Cambio de motor (usas nginx/Apache y quieres Caddy aquí) → consulta Migrar a Caddy. Es otro problema; ese flujo reescribe configuraciones in situ, no trae un paquete.
- Correo + DNS → fuera de alcance. Configúralos por separado con Conectar un dominio y Configurar el correo para tu dominio.
Referencia
Rutas de origen que comprueba el escaneo SSH:
/var/www/*/— raíz común de vhost en Nginx / Apache/srv/www/*/— alternativa al estilo Debian/home/*/public_html/— raíz de documentos al estilo cPanel/home/*/domains/*/public_html/— raíz de documentos al estilo DirectAdmin- WordPress: cualquiera de las anteriores que contenga un
wp-config.php - Bases de datos: enumeradas mediante
mysql -e "SHOW DATABASES"usando el~/.my.cnfdel usuario SSH si existe
Endpoints de escaneo de cPanel utilizados:
WebVhosts(lista las raíces de documentos de los vhost)MysqlFE/listdbs(lista bases de datos)- Sondeo del árbol de archivos por vhost en busca de
wp-config.php
Preparación en disco durante la migración:
- Lado del origen: mysqldump temporal bajo
/tmp/y eliminado inmediatamente después - Este servidor:
/tmp/helm-restore/<id>/<bundle>.tar.gz— la misma ruta que usa el asistente de restauración
Formato del paquete: el formato propio de Server Manager, intercambiable con el que produce la pestaña Copias de seguridad; por eso, migrar y luego restaurar es idéntico byte a byte a hacer una copia de seguridad y restaurarla (la única diferencia es de dónde salió el paquete).