Migración

Sí. Nuestro asistente de migración está incluido en todas las ofertas, Start incluido: transfiere sus dominios y restaura sus cuentas cPanel en un solo pedido, sin interrupción del servicio. A partir de Business, la gestión de principio a fin por nuestro equipo también está incluida.

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.

Su duración depende del tamaño del sitio y del volumen de datos. Se desarrolla en tres etapas: transferencia (dominios mediante código EPP, cuenta cPanel restaurada desde una copia de seguridad o por transferencia directa), verificación del sitio en nuestros servidores y, por último, el cambio de DNS — su sitio sigue en línea en su proveedor actual hasta ese cambio. 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.

El asistente de migración (transferencia de sus dominios y restauración de sus cuentas cPanel) está incluido en todas las ofertas, Start incluido: solo paga sus servicios. A partir de Business, la gestión de principio a fin por nuestro equipo también está incluida.

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, use la API de Linear: usted realiza la migración y el soporte responde a sus preguntas desde el á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. Tú realizas esta migración; el soporte responde a tus preguntas a través de un ticket.

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.

Desde Kommo, exporte sus contactos, empresas y tratos en formato CSV desde el menú Configuración → Exportaciones. Luego importe estos archivos en Twenty desde la pestaña Importar de cada objeto (People, Companies, Opportunities). Para los archivos adjuntos y el historial de conversaciones, compruebe las exportaciones disponibles en Kommo y consérvelas por separado. Nuestro equipo puede acompañarle si necesita ayuda para planificar la migración.

Jellyfin lee directamente las mismas carpetas de medios que Plex: no es necesario copiar ni mover sus archivos. Apunte las bibliotecas de Jellyfin a sus directorios existentes y deje que escanee y construya sus metadatos. Sin embargo, sus listas de reproducción e historial de visualización no se transfieren automáticamente desde Plex. Si su instancia se ejecuta en un VPS ServOrbit, el almacenamiento adjunto permanece sin cambios.

ServOrbit ofrece una migración asistida que copia sus archivos y base de datos a nuestros servidores antes de cualquier cambio de DNS. Una vez validado en el nuevo alojamiento, el cambio de DNS tarda solo unos minutos, limitando la interrupción a la propagación del TTL. Contacte a [email protected] para planificar su migración.

No anunciamos una duración tipo: depende del volumen de datos y del número de cuentas que migrar. El proceso, en cambio, es siempre el mismo: transferencia (dominios mediante código EPP, cuentas cPanel restauradas desde una copia de seguridad o por transferencia directa), verificación en nuestros servidores y, por último, el cambio de DNS. Su alojamiento de origen no se modifica: el sitio sigue en línea en su proveedor actual hasta el cambio. El asistente de migración está incluido en todas las ofertas, Start incluido, y la gestión de principio a fin por nuestro equipo lo está a partir de Business. Para un caso particular, escriba a [email protected].

El método recomendado es exportar su base de datos mediante mysqldump en el alojamiento antiguo, importarla en el VPS mientras el antiguo sigue activo y luego cambiar la configuración de su aplicación al nuevo servidor tras una prueba de coherencia. ServOrbit puede coordinar esta operación por usted; contacte a [email protected] para programar la migración fuera de las horas punta.

Sí, es posible migrar los correos de tu empresa desde un alojamiento compartido a un VPS de ServOrbit. La migración incluye la transferencia de buzones, contactos e historial de mensajes mediante el protocolo IMAP. Recomendamos utilizar una herramienta como imapsync para evitar cualquier pérdida de datos: usted realiza la migración y el soporte responde a sus preguntas. Planifica una ventana de cambio DNS adecuada y mantén el acceso al alojamiento antiguo durante 48 a 72 horas para garantizar la continuidad del servicio.

La migración desde Odoo.sh o el SaaS oficial a un VPS autohospedado es técnicamente viable, pero implica varios pasos. Primero, es necesario exportar un volcado de la base de datos PostgreSQL y el directorio `filestore` desde la plataforma de origen. En el VPS, se requiere una instalación de Odoo en la misma versión principal antes de importar los datos. Los módulos desarrollados específicamente para la plataforma cloud (integraciones Odoo.sh, módulos Enterprise de pago no incluidos en Community) deben identificarse y reemplazarse. Por último, los certificados SSL, la configuración DNS y el acceso SMTP deben reconfigurarse en el nuevo servidor antes de conmutar el tráfico.

La migración se realiza en tres pasos: exporte su contenido desde Squarespace (Herramientas → Exportar), impórtelo en Ghost a través de su panel de administración y luego apunte su dominio a su VPS de ServOrbit. Ghost se instala en minutos en un VPS a través de nuestro Marketplace; prevea al menos 1 GB de RAM. Para cualquier pregunta, abra un ticket desde su área de cliente indicando su calendario de migración.

Sí, la migración de Plex o Jellyfin a un VPS de ServOrbit se realiza en tres pasos: exportar la base de datos y la carpeta de metadatos desde su instalación actual, transferirla mediante rsync o SCP al nuevo VPS y, por último, reinstalar el servidor apuntando a las mismas rutas. Los metadatos, listas de reproducción y el progreso de visualización se conservan siempre que las rutas de la biblioteca permanezcan idénticas o se reconfiguren correctamente. Nuestros planes VPS root le ofrecen total libertad sobre la estructura de directorios. Contacte a [email protected] para cualquier pregunta sobre la transferencia de datos.

Plane incluye un importador nativo para Asana accesible desde los ajustes del workspace (Settings → Importers → Asana). Importa proyectos, tareas, subtareas, asignados, fechas límite y comentarios. El historial de actividad se conserva parcialmente: los comentarios con fecha y los cambios de estado se incluyen, pero los adjuntos de gran tamaño pueden requerir transferencia manual según su tamaño. Antes de iniciar la importación, genere un token de acceso personal de Asana y conceda permisos de lectura sobre los workspaces correspondientes. La migración no borra nada en Asana: puede ejecutar ambos sistemas en paralelo mientras valida. Una vez instalado Plane en su VPS de ServOrbit (aún no se ofrece para su contratación en el Marketplace), el importador funciona directamente desde la interfaz web, sin necesidad de comandos CLI. Para migraciones a gran escala (más de 10.000 tareas), ejecute la importación fuera de horas pico para evitar timeouts.

El proceso siempre sigue tres pasos: exportar sus datos desde la plataforma SaaS (panel de control o API según lo que ofrezca), desplegar la aplicación en su VPS de ServOrbit y, a continuación, importar sus datos. Algunas aplicaciones incluyen un importador nativo integrado; para otras, la transferencia se realiza a través de archivos o la base de datos. ServOrbit ofrece plantillas VPS listas para usar en el Marketplace para las aplicaciones más habituales — la plantilla incluye la configuración inicial y el reverse proxy. Abra un ticket desde su área de cliente si necesita ayuda con una migración específica.

La migración se hace en varias etapas, que usted realiza: exporte sus correos mediante Google Takeout (formato MBOX), luego impórtelos en Nextcloud Mail o Roundcube en su VPS de ServOrbit. Para los archivos de Google Drive, instale Nextcloud desde el marketplace de ServOrbit con un clic y use la herramienta de migración integrada (rclone o el conector Nextcloud Google Drive).

El método recomendado es preparar el entorno en ServOrbit antes de cambiar el DNS: duplique su sitio en el VPS o alojamiento de destino, pruébelo mediante el archivo hosts local y luego baje el TTL de DNS a 300 segundos 48 horas antes de la migración. Una vez validada la transferencia, actualice sus DNS en ServOrbit. La propagación suele tardar menos de 15 minutos con nuestra infraestructura Cloudflare.

La migración de Bitwarden Cloud a una instancia Vaultwarden autoalojada se realiza en tres pasos: exporte su bóveda desde la aplicación Bitwarden (JSON no cifrado o cifrado), despliegue Vaultwarden en su VPS de ServOrbit mediante Docker, luego importe el archivo en su nueva instancia. Vaultwarden es compatible con el cliente oficial de Bitwarden: no es necesario reinstalar la aplicación, solo apunte al dominio. Nuestro artículo detallado cubre cada paso: Migrar de Bitwarden Cloud a Vaultwarden en VPS.

La migración de un sitio de comercio electrónico sigue los mismos pasos principales que una migración estándar, con especial atención a la base de datos: exporte una copia de seguridad completa (archivos + volcado SQL) desde su proveedor actual, impórtela en su alojamiento ServOrbit y luego pruebe su sitio modificando localmente el archivo hosts antes de cambiar ningún registro DNS — así su tienda permanece accesible a sus clientes durante toda la operación. Actualice a continuación los parámetros de conexión a la base de datos en el archivo de configuración de su aplicación (wp-config.php para WooCommerce, parameters.php o .env para PrestaShop). Una vez validadas las pruebas, actualice sus registros DNS; la propagación suele tardar menos de 24 horas. Nuestro servicio de migración asistida puede encargarse de todo el proceso — contáctenos en [email protected].

Sí, puede migrar únicamente su base de datos (MySQL, MariaDB o PostgreSQL) a un VPS de ServOrbit manteniendo su sitio en otro proveedor, siempre que su aplicación soporte conexión a una base de datos remota. Deberá configurar el acceso de red (firewall, usuario MySQL remoto) y actualizar las credenciales de conexión en su aplicación. El asistente de migración cubre cuentas cPanel completas que llegan a un alojamiento; una base de datos sola hacia un VPS la migra usted, y el soporte responde a sus preguntas por ticket desde su área de cliente.

Sí, con condiciones. YNAB permite exportar sus transacciones en formato CSV desde la pestaña «Reports». Maybe.co (antes Maybe Finance) acepta la importación de CSV de transacciones. El proceso conserva importes, fechas y categorías, pero las reglas de presupuesto de YNAB (sobres) no se transfieren de forma nativa — tendrá que recrearlas manualmente en Maybe. Pruebe primero con una exportación parcial antes de migrar todo su historial.

Atlassian ofrece una herramienta oficial de migración Cloud-to-Server (o Data Center) accesible desde la interfaz de administración de su instancia Cloud; exporta proyectos, incidencias, espacios e historial en un archivo importable en su nuevo VPS. Antes de iniciar la migración, aprovisione un VPS con al menos 4 GB de RAM, instale la misma versión mayor de Jira o Confluence y asegúrese de que el servidor sea accesible por HTTPS con un certificado TLS válido. Nuestro equipo de soporte responde a sus preguntas en [email protected] sobre los pasos de importación y la configuración DNS.

El posicionamiento en Google.ma depende del targeting geográfico declarado en Google Search Console, no de la ubicación física del servidor. Antes de migrar, declare Marruecos como objetivo geográfico en Search Console, asegúrese de que su dominio .ma siga siendo la URL canónica y configure redirecciones 301 si cambian las URLs. Usted copia sus archivos y bases de datos al VPS, y el soporte responde a sus preguntas; el asistente que presenta nuestra página de migraciones cubre el alojamiento cPanel.

Una migración sin tiempo de inactividad se basa en tres pasos: primero, un volcado lógico inicial con `pg_dump` seguido de una restauración en su VPS; luego, la configuración de replicación lógica (slot de replicación en PostgreSQL 10 o superior) para ponerse al día con las escrituras en curso; y finalmente, el cambio de la cadena de conexión de la aplicación durante una breve ventana planificada. Conviene probar la restauración y el rendimiento en su VPS ServOrbit antes del cambio, y mantener la instancia RDS activa en modo solo lectura durante unas horas tras la migración para permitir un retroceso rápido si fuera necesario. Consulte el artículo dedicado en nuestra base de conocimiento o abra un ticket en [email protected] para un acompañamiento personalizado.

Sí: la lista de suscriptores se exporta, normalmente en CSV, desde la herramienta actual y se importa en la nueva. Exporta también el estado de cada contacto (suscrito, dado de baja, dirección con rebote) e importa a los que se dieron de baja como tales, nunca como activos: volver a escribirles provoca quejas que dañan la reputación de tu dominio. Antes del primer envío desde el nuevo servicio, añade a la zona DNS de tu dominio los registros SPF y DKIM que te proporcione, y reserva los envíos masivos a ese servicio en lugar de tu buzón de correo profesional. Para obtener ayuda con estos registros DNS, abre un ticket desde tu área de cliente.

La exportación del proyecto incluye el código, las incidencias y las merge requests, pero no las variables de CI/CD, los webhooks, los tokens, los artefactos de los trabajos ni las imágenes del registro de contenedores. Haz el inventario de estos elementos antes del cambio y vuelve a crearlos a mano en la nueva instancia, manteniendo el proyecto antiguo en solo lectura hasta validar. ServOrbit ofrece una guía paso a paso, pero no realiza la migración por ti.

Durante la propagación del DNS, algunos visitantes aún llegan al servidor antiguo y lo que envían allí no llega al nuevo. Reduzca el TTL con antelación, haga una última sincronización de la base de datos y de los archivos justo antes del cambio y ponga el sitio antiguo en mantenimiento, o desactive el pago y los formularios, durante la transición. Después, mantenga activo el alojamiento antiguo y compruebe que no ha llegado allí ningún pedido ni comentario tras la sincronización antes de darlo de baja. Si es una tienda, la migración asistida puede acompañarle: escriba a [email protected].

Duplique los archivos y la base de datos en un subdominio aparte, protegido con contraseña y en noindex, y sustituya la dirección del sitio en la base con una herramienta que maneje datos serializados, no con una simple búsqueda y reemplazo. En la copia, desactive el envío de correos, los pagos reales y las tareas programadas, para que el cliente no reciba nada. Valide la actualización en la copia y rehágala en producción tras una copia de seguridad, en lugar de traer la copia de vuelta: sobrescribiría los pedidos y comentarios recibidos entretanto.

Evite hacer ambas cosas a la vez: si el sitio falla, no sabrá si la causa es el traslado o la actualización. Migre primero tal cual, eligiendo en cPanel la misma versión de PHP que tenía en el alojamiento anterior, y valide el sitio. Después actualice sobre una copia, pruebe y aplique en producción con una copia de seguridad reciente. Si la versión actual ya no tiene mantenimiento, planifique la actualización justo después del cambio en lugar de aplazarla.