Migración

Sí. La migración asistida está incluida en los planes Business y Pro: nuestro equipo transfiere su sitio sin interrupción del servicio.

Sí. El asistente de migración le permite agrupar la transferencia de sus dominios (mediante código EPP) y de sus cuentas cPanel en UN solo pedido guiado — ideal para repatriar toda una cartera. Para cada alojamiento, elija el método: un enlace de copia de seguridad (.tar.gz) o una transferencia directa desde su antiguo cPanel (con sus credenciales, utilizadas al vuelo y nunca almacenadas).

No. Preparamos la transferencia en nuestros servidores y luego cambiamos el DNS una vez que todo está verificado, para una transición sin corte perceptible.

Transferimos sus archivos, sus bases de datos y sus cuentas de correo para reconstituir su entorno de forma idéntica.

Una migración suele tardar de 24 a 72 horas según el tamaño del sitio, propagación DNS incluida. Puede seguir su avance en su área de cliente (registro del servicio correspondiente), y le mantenemos informado en cada etapa.

Sí, nos encargamos de la migración desde la mayoría de los proveedores de alojamiento, en particular los que utilizan cPanel.

Está incluida en los planes Business y Pro. En los demás casos, se ofrece un servicio de migración asistida como opción.

Sí, un cambio de IP de envío requiere una fase de calentamiento: empiece con volúmenes pequeños (de 50 a 100 correos al día la primera semana) para construir progresivamente la reputación de la nueva IP. Asegúrese de que SPF, DKIM y DMARC estén configurados correctamente en el nuevo servidor desde el primer envío y, después, vigile los informes DMARC durante 2 a 4 semanas para detectar cualquier anomalía. Nuestro equipo de soporte está disponible en [email protected] para acompañarle.

La migración se desarrolla en cuatro etapas: exporte sus imágenes y volúmenes (`docker save`, `rsync` de los datos), prepare el VPS de destino instalando Docker y configurando sus variables de entorno, transfiera los datos y arranque los contenedores, y cambie el DNS únicamente después de haber validado el correcto funcionamiento en el destino. Para las aplicaciones sensibles al tiempo de inactividad, mantenga activo el servidor antiguo hasta que la propagación DNS sea completa. Si necesita ayuda, abra un ticket desde su área de cliente.

WHM integra una herramienta nativa llamada Transfer Tool (Packages > Transfer Tool) que permite migrar el conjunto de las cuentas cPanel de un servidor WHM de origen hacia su nuevo servidor ServOrbit, incluyendo los archivos, las bases de datos MySQL, los correos electrónicos y las zonas DNS. Usted indica la dirección IP o el hostname del WHM de origen, las credenciales root o un token de API, y después selecciona las cuentas que desea transferir. La duración de la migración depende del volumen total de datos: calcule entre 30 minutos y varias horas para un revendedor de gran tamaño. Se recomienda dejar los DNS apuntando al servidor antiguo durante la migración y cambiarlos una vez finalizada la verificación, para minimizar la interrupción.

Exporte su base de datos con `pg_dump`, transfiera el archivo mediante `rsync` o `scp` a su VPS ServOrbit y luego restaure con `pg_restore` o `psql`. Compruebe las versiones de PostgreSQL antes de la migración para evitar incompatibilidades, y pruebe la conexión de su aplicación antes de cambiar el DNS. Nuestro equipo de soporte puede acompañarle si encuentra algún bloqueo.

Sí. Estas forjas Git son aplicaciones estándar que se instalan en cualquier VPS Linux. Haga una copia de seguridad de sus datos (repositorios, configuración, base de datos), transfiéralos a su VPS ServOrbit y vuelva a lanzar la aplicación — el procedimiento es idéntico al de una migración de servidor clásica. Nuestro blog ofrece guías detalladas paso a paso para las principales forjas.

Antes de migrar, exporte todos sus workflows desde la interfaz de n8n (menú Settings → Import/Export) y anote sus variables de entorno (clave de cifrado, credenciales de la base de datos). Detenga el proceso npm, instale Docker y Docker Compose en su VPS y utilice después la receta oficial n8n Docker montando el mismo directorio de datos (~/.n8n) en el volumen del contenedor para conservar sus workflows y credenciales. El equipo de n8n recomienda la migración a Docker antes de la v3.0, que abandona el soporte de la instalación global npm; nuestro soporte puede acompañarle a través de [email protected].

Sí, Docker v29 introduce varias rupturas de compatibilidad que conviene anticipar: la red bridge por defecto ha evolucionado, algunas opciones de `docker run` obsoletas desde la v24 se han eliminado, y el formato de los manifiestos multiarquitectura ha cambiado. Antes de la migración, audite sus `docker-compose.yml` y sus Dockerfiles para detectar las opciones obsoletas, pruebe en un entorno de preproducción y después haga el cambio. Nuestro artículo de blog sobre la migración a Docker v29 detalla los pasos de verificación.

El procedimiento consiste en respaldar sus flujos de LangFlow (exportación JSON desde la interfaz) y sus modelos de Ollama (carpeta `~/.ollama/models`), y después transferirlos al nuevo VPS mediante `rsync` o `scp`. Tras la reinstalación de los servicios en el nuevo VPS, vuelva a importar sus flujos y compruebe las variables de entorno (claves de API, URL). Prevea una ventana de mantenimiento corta para el cambio de DNS, con el fin de evitar cualquier interrupción.

La migración desde Oracle Cloud a un VPS ServOrbit sigue un esquema sencillo: exporte sus imágenes Docker con `docker save`, transfiéralas por SSH o mediante un registro privado, y vuelva a crear sus servicios con sus archivos `docker-compose.yml` existentes. Para los datos persistentes, copie sus volúmenes con `rsync` o `docker cp`. Conviene probar la configuración en el nuevo servidor antes de cambiar el DNS, conservando un TTL corto (300 segundos) para limitar la ventana de conmutación. ServOrbit ofrece VPS con Debian o Ubuntu, compatibles con todas las distribuciones de imágenes Docker estándar. Se dispone de un acceso SSH root desde la activación del servidor.

Sí, Mattermost ofrece una herramienta de importación nativa compatible con el formato de exportación de Slack. El procedimiento consiste en exportar sus datos desde Slack (formato ZIP proporcionado por su interfaz de administración), y después convertirlos e importarlos mediante el comando `mattermost import slack` o la herramienta `mmetl`. Los mensajes, los canales públicos y los archivos adjuntos se recuperan generalmente. Los mensajes directos y algunos emojis personalizados pueden requerir un tratamiento adicional según la versión. Se recomienda efectuar una importación de prueba en una instancia vacía antes del cambio definitivo. La operación se realiza enteramente desde su VPS ServOrbit, sin dependencia de ningún servicio de terceros.

OpenProject dispone de un Jira Migrator oficial, disponible desde la versión 17.4 (beta publicada en mayo de 2026). Migra los proyectos, las issues (título, descripción, archivos adjuntos, fecha de vencimiento, horas estimadas), los identificadores de issues, los campos personalizados simples (texto, números, fechas, listas desplegables), los usuarios, los estados, los tipos y los comentarios. Lo que NO se migra: las relaciones entre issues, las asignaciones a sprints, los workflows automatizados y los permisos complejos. Procedimiento: desde su instancia de Jira, exporte un archivo XML completo (Administración → Sistema → Copia de seguridad). En OpenProject, vaya a Administración → Importación → Jira y cargue el archivo XML. El tiempo de migración depende del volumen — prevea de 15 a 30 minutos para menos de 10 000 issues.

Gitea ofrece una herramienta de migración integrada (Administración → Repositorios → Migrar) que importa un repositorio de GitHub por URL, conservando el historial completo de commits, las ramas y las etiquetas mediante un `git clone --mirror`. Para migrar varios repositorios, utilice la API de Gitea con un script que recorra sus repositorios de GitHub y lance la migración de cada uno. Una vez terminada la migración, actualice sus remotes locales con `git remote set-url origin <nueva-url>`. Consulte nuestra página `/vps-cloud` para desplegar una instancia de Gitea en su VPS ServOrbit.

Gitea integra una migración de las issues y los milestones desde GitHub: al crear o actualizar el repositorio mediante la herramienta de migración (o la API `POST /api/v1/repos/migrate`), active las opciones `issues`, `milestones` y `labels`. Se requiere un token de acceso personal de GitHub con el alcance `repo` para sortear los límites de la API y acceder a los repositorios privados. Los comentarios, los asignados y las etiquetas también se importan. Para conjuntos de issues grandes, prevea un plazo proporcional al volumen, ya que Gitea respeta los límites de tasa de la API de GitHub.

Sí, mediante la importación CSV nativa de Plane: en Linear, exporte sus issues en formato CSV (Settings → Export) y después, en su instancia de Plane, vaya a Configuración → Importadores → CSV y cargue el archivo. Se importan los títulos, las descripciones, las prioridades y las etiquetas; los comentarios no están cubiertos por el formato CSV de Linear — solo una exportación JSON completa a través de la API de Linear los preserva. Para una migración completa con el historial de comentarios, nuestro equipo de soporte puede acompañarle; contáctenos a través del área de cliente.

Confluence Data Center llega a su fin de vida el 28 de marzo de 2029 y pasa a modo de solo lectura en esa fecha. Docmost es una alternativa de código abierto que admite espacios, permisos y edición colaborativa; el importador nativo de Confluence (edición Enterprise) conserva la jerarquía de los espacios, los archivos adjuntos, los enlaces internos y los diagramas draw.io. La migración pasa por exportar espacio por espacio en formato XML desde Confluence (Administración → Backup Manager) y luego importar en Docmost. Para las instancias sin edición Enterprise, la migración es manual (exportación HTML, recreación de la estructura y copiar y pegar el contenido). Pida un VPS ServOrbit con al menos 2 GB de RAM, despliegue Docmost desde el marketplace y abra un ticket de soporte a través del área de cliente si necesita acompañamiento.

Planka v2.2.0 (publicada el 9 de agosto de 2026) retiró la autenticación SSO/OIDC de la Community Edition y la trasladó a Planka Pro. Las cuentas que se autenticaban exclusivamente mediante SSO quedan desactivadas tras la actualización. Planka no ofrece exportación nativa de los tableros en JSON o CSV (issues de GitHub #22 y #670 sin resolver) — la única extracción fiable pasa por un dump de PostgreSQL (`pg_dump`). Para migrar: (1) haga un snapshot completo de la base antes de cualquier corte, (2) instale Kaneo o Vikunja en un subdominio temporal y mantenga las dos instancias en paralelo 1–2 semanas, (3) transfiera manualmente los tableros activos, (4) cambie el DNS en D+7 y conserve el snapshot 90 días. Kaneo (MIT, v2.16.2) mantiene el SSO OIDC gratuito; Vikunja (AGPL-3.0, v2.4.0) también — ambos están disponibles en el marketplace de ServOrbit.

La actualización de Immich v2→v3 elimina la extensión pgvecto.rs y la sustituye por pgvector nativo. Antes de lanzar la actualización (a partir de la v1.132.3), haga una copia de seguridad de todo el volumen PostgreSQL con `docker compose exec database pg_dumpall -U postgres > backup.sql`. Actualice su archivo `docker-compose.yml` a la imagen `ghcr.io/immich-app/immich-server:v1.132.3` y ejecute después `docker compose pull && docker compose up -d`: la migración del esquema se realiza automáticamente al arrancar. Sus fotos, álbumes y elementos compartidos no se ven afectados — contacte con [email protected] si la migración falla al arrancar.

Passbolt CE acepta las importaciones CSV y JSON (Admin > Import passwords). Desde Bitwarden: exportar en CSV sin cifrar. Desde 1Password: exportar en formato 1PUX y después adaptar las columnas al formato esperado. Las contraseñas importadas se vuelven a cifrar con las claves GPG de los destinatarios designados.

Forgejo v16 rompió la compatibilidad ascendente directa con Gitea: el equipo ha finalizado el giro hacia un esquema de base de datos y unas rutas de configuración independientes. Para migrar desde Gitea, la vía recomendada es pasar primero por Forgejo v7 o v8 (la última versión aún perfilada para la importación desde Gitea), ejecutar las migraciones de esquema y luego subir progresivamente hasta la v16. Un volcado `gitea dump` seguido de un `forgejo admin` sigue siendo el método más limpio para las instancias de tamaño moderado. Abra un ticket desde su área de cliente si necesita acompañamiento para la operación en su VPS ServOrbit.

Supabase sustituyó Kong por Envoy Gateway como proxy interno a partir de agosto de 2026: las variables de entorno de enrutamiento, los timeouts y la configuración de los plugins difieren sensiblemente. Antes de descargar la actualización (`docker compose pull`), revise sus overrides personalizados en `docker-compose.override.yml` (rutas Kong, plugins de rate-limit, CORS), lea las notas de versión oficiales para conocer los equivalentes en Envoy, y haga un snapshot de sus volúmenes Docker. Pruebe la actualización en un VPS de preproducción antes de aplicarla en producción, y revise los logs de Envoy en el primer arranque para detectar las rutas no migradas.

Instale el binario Forgejo Runner en su VPS, regístrelo con un token generado en su instancia Forgejo (Configuración → Actions → Runners) y luego cree sus flujos de trabajo en `.forgejo/workflows/` con la misma sintaxis YAML que GitHub Actions. La mayoría de las etapas son compatibles; solo los runners alojados por GitHub (`ubuntu-latest`) deben sustituirse por la etiqueta de su runner (`self-hosted`). Para cualquier pregunta sobre el dimensionamiento o la configuración, abra un ticket desde su área de cliente.

Una interrupción breve (unos minutos) suele ser inevitable durante una actualización mayor de Chatwoot, ya que las migraciones de base de datos son bloqueantes. Para minimizar el impacto: haga una copia de seguridad íntegra de PostgreSQL y de los volúmenes, pruebe la actualización en un entorno de staging y planifique después el cambio fuera de las horas punta. El canal de notificación de Chatwoot sigue siendo accesible para los agentes durante la ventana de mantenimiento si difunde previamente un mensaje de estado. Para obtener ayuda con la planificación, abra un ticket desde su área de cliente.

La migración de un sitio WordPress puede hacerse sin tiempo de inactividad siguiendo este procedimiento: **Paso 1: Respaldar el antiguo proveedor de alojamiento** - Exportación de la base de datos MySQL mediante phpMyAdmin o `mysqldump` - Archivo de los ficheros de WordPress (en particular la carpeta `wp-content/`) **Paso 2: Crear el entorno en ServOrbit** - Crear un VPS con Debian/Ubuntu e instalar WordPress - Restaurar la base de datos y los archivos - Configurar `wp-config.php` con los nuevos datos de conexión **Paso 3: Probar antes de cortar** - Acceder al nuevo sitio mediante su IP (o un archivo `/etc/hosts` local) antes de cambiar el DNS - Comprobar que todas las páginas, medios y funcionalidades funcionan **Paso 4: Reducir el TTL del DNS** - 24–48 h antes de la migración, reducir el TTL de sus DNS a 300 segundos **Paso 5: Cambiar el DNS** - Cambiar el registro A/AAAA hacia la nueva IP - La propagación tardará de 5 a 30 minutos con un TTL bajo El antiguo proveedor de alojamiento permanece activo durante la propagación — ningún visitante ve interrupción alguna.

Sí, la transferencia de un nombre de dominio no interrumpe su sitio si sigue el procedimiento correcto. **Principio clave:** el DNS y el registrador son dos cosas separadas. Su sitio funciona mientras los servidores DNS respondan correctamente — con independencia de quién sea el registrador. **Procedimiento sin interrupción:** 1. **Antes de iniciar la transferencia**, compruebe que sus DNS están gestionados por un proveedor estable (Cloudflare, su alojamiento actual, etc.) — no directamente por el registrador de origen. 2. **Desbloquee el dominio** en el antiguo registrador y recupere el código EPP/Auth. 3. **Inicie la transferencia** en ServOrbit (o deje sus DNS en Cloudflare si ya están allí). 4. **Durante la transferencia** (de 5 a 7 días para los .com, .net; de 2 a 3 días para los .fr; hasta 7 días para los .ma), su sitio sigue funcionando — los DNS no se mueven. 5. **Después de la transferencia**: si sus DNS estaban gestionados por el antiguo registrador, deberá reconfigurarlos en el nuevo. Planifique esta etapa con antelación. **Importante para los .ma:** la transferencia de nombres .ma sigue reglas específicas definidas por la ANRT y puede requerir justificantes adicionales.

Desde Notion, vaya a Configuración → Espacio de trabajo → Exportar el contenido y elija el formato Markdown & CSV para obtener un archivo con sus páginas y bases de datos. Ese archivo sirve de punto de partida para la importación en Docmost (importación Markdown) o AppFlowy (importación Notion). Para un espacio de trabajo voluminoso, prevea unos minutos de espera antes de que Notion envíe el enlace de descarga por correo electrónico. Si necesita ayuda, contáctenos en [email protected].

Plane ofrece una importación nativa desde Jira: en su instancia de Plane, acceda a Configuración → Importers → Jira, indique su URL de Jira y un token de API, y seleccione después los proyectos que desea importar — las incidencias, las asignaciones, las etiquetas y los estados se transfieren. Para un proyecto de Jira Data Center (no cloud), el conector de importación puede necesitar un acceso de red directo a su instancia; prevea una prueba en un proyecto de tamaño reducido antes de la migración completa.

El método más seguro es un dump/restore: detenga sus servicios de aplicación, exporte la base de datos con `docker exec <pg15> pg_dumpall -U postgres > dump.sql`, lance un nuevo contenedor PostgreSQL 17, importe el dump y verifique cada base con `pg_dump --schema-only` antes de eliminar el contenedor antiguo. Un VPS de ServOrbit con acceso root completo le permite mantener ambos contenedores simultáneamente durante las pruebas. Consulte `/vps-cloud` para elegir la configuración adecuada según el tamaño de sus bases de datos.

Sí, ServOrbit ofrece un servicio de migración de M365 a Nextcloud que cubre correos electrónicos (IMAP-a-IMAP), calendarios (CalDAV) y contactos (CardDAV). La migración se realiza en modo cutover o delta según el volumen de buzones, sin interrupción de servicio perceptible para sus usuarios. Las licencias de M365 pueden mantenerse temporalmente en paralelo mientras se valida la migración y cancelarse a su ritmo. Contacte con nuestro equipo de soporte para una auditoría previa y un presupuesto adaptado al tamaño de su organización.

La migración de Sentry a GlitchTip se basa en un simple reemplazo del DSN (Data Source Name) en cada aplicación: GlitchTip expone una API compatible con Sentry, por lo que sólo hay que apuntar la variable de entorno `SENTRY_DSN` al nuevo DSN de GlitchTip sin modificar el SDK ni el código. Las reglas de alerta, equipos y proyectos deben recrearse manualmente en GlitchTip, ya que no existe exportación automática entre ambas plataformas. Recomendamos una fase de doble envío (mantener Sentry activo en paralelo durante unos días) para confirmar que GlitchTip captura todos los errores antes del corte definitivo.

Exportar los contactos desde HubSpot mediante Settings > Data Management > Export > Contacts en formato CSV. En Twenty CRM, usar People > Import > CSV para cargar el archivo; los campos estándar (nombre, apellido, correo, teléfono) se mapean automáticamente. Las propiedades personalizadas de HubSpot deben recrearse manualmente en Twenty antes de la importación.

Stalwart incluye una herramienta de migración y un proxy de migración que trabajan juntos para mover cuentas de forma continua: los usuarios siguen enviando y recibiendo correos durante la transferencia, cuenta por cuenta. En la práctica, apunta el proxy al servidor antiguo mientras la herramienta copia correos, carpetas, filtros Sieve, libretas de direcciones y calendarios; una vez migrada una cuenta, el proxy la redirige directamente a Stalwart. Antes de cambiar el DNS, verifica los registros SPF, DKIM y DMARC en el nuevo VPS. Nuestro equipo puede asistirte a través de un ticket desde tu área de cliente.

Antes de cualquier migración, exporte sus datos en formatos abiertos: CSV o JSON para las bases de datos, PDF para los documentos, ZIP para los archivos multimedia. Compruebe que la exportación es completa — algunos SaaS no incluyen los adjuntos ni el historial. Guarde una copia fuera del servicio (almacenamiento local o de objetos) antes de cancelar: una vez cerrada la cuenta, los datos son inaccesibles. Pruebe también la importación en su solución de destino antes de cortar el acceso anterior, para evitar pérdidas de datos no detectadas.

Comience auditando sus servicios actuales: liste lo que paga, los datos asociados y las integraciones críticas. A continuación, elija un equivalente de código abierto y pruébelo en un VPS de desarrollo antes de cualquier cambio. Planifique la migración en horas de baja actividad, prepare un plan de rollback y exporte sus datos con antelación. Migre servicio por servicio en lugar de todo a la vez: esto limita los riesgos y facilita el diagnóstico si algo sale mal. Compruebe que las copias de seguridad automáticas funcionen antes de cancelar sus suscripciones anteriores.

Antes de cualquier migración, realiza una copia de seguridad completa con el comando `bench backup` de Frappe — exporta la base de datos y los archivos en un único archivo. En el nuevo VPS de ServOrbit, instala ERPNext mediante la plantilla del Marketplace o manualmente, importa la copia de seguridad con `bench restore` y actualiza la dirección del sitio en `currentsite.txt`. Verifica los permisos de los archivos subidos y prueba el acceso antes de cambiar el DNS del servidor antiguo para evitar interrupciones. Nuestro equipo puede acompañarte en esta migración a través de un ticket de soporte.

Usa la API REST de GitLab (`/api/v4/projects?owned=true`) para listar tus repositorios y luego clona cada uno con `git clone --mirror`. Gitea incluye un asistente de importación integrado (Administración → Migración) que acepta una URL de GitLab y crea automáticamente repositorios, issues y pull requests. Para los espacios de nombres de solo lectura o grupos, exporta primero un archivo tarball desde GitLab (Ajustes → General → Exportar proyecto) y luego impórtalo en Gitea a través de la interfaz o su API. Prevé al menos 2 GB de RAM en tu VPS para una migración sin problemas.