Migration

Yes. Assisted migration is included on the Business and Pro plans: our team transfers your site with no service interruption.

Yes. The migration wizard lets you group the transfer of your domains (by EPP code) and your cPanel accounts into ONE guided order — ideal for bringing over an entire portfolio. For each hosting account, choose the method: a backup link (.tar.gz) or a direct transfer from your old cPanel (with your credentials, used on the fly and never stored).

No. We prepare the transfer on our servers and then switch the DNS once everything has been verified, for a transition with no perceptible downtime.

We transfer your files, your databases and your email accounts in order to reconstruct your environment identically.

A migration usually takes 24 to 72 hours depending on the size of the site, DNS propagation included. You can follow its progress in your client area (the log of the relevant service), and we keep you informed at every step.

Yes, we support migration from most hosting providers, particularly those using cPanel.

It is included on the Business and Pro plans. In other cases, an assisted migration service is offered as an option.

Yes, changing your sending IP requires a warm-up phase: start with small volumes (50 to 100 emails per day in the first week) to gradually build the new IP's reputation. Make sure SPF, DKIM, and DMARC are correctly configured on the new server from your very first send, then monitor DMARC reports for 2 to 4 weeks to catch any issues. Our support team is available at [email protected] to guide you through the process.

The migration follows four steps: export your images and volumes (`docker save`, `rsync` of data), prepare the target VPS by installing Docker and configuring your environment variables, transfer the data and start your containers, then switch DNS only after validating that everything works correctly on the target. For downtime-sensitive applications, keep the old server active until DNS propagation is complete. If you need assistance, open a support ticket from your client area.

WHM includes a built-in tool called Transfer Tool (Packages > Transfer Tool) that lets you migrate all cPanel accounts from a source WHM server to your new ServOrbit server, including files, MySQL databases, emails, and DNS zones. You enter the source WHM's IP address or hostname, the root credentials or an API token, then select the accounts to transfer. Migration time depends on the total data volume — expect anywhere from 30 minutes to several hours for a large reseller. It is recommended to keep DNS pointing to the old server during migration, then switch records once verification is complete to minimize downtime.

Export your database with `pg_dump`, transfer the file via `rsync` or `scp` to your ServOrbit VPS, then restore with `pg_restore` or `psql`. Check PostgreSQL versions before migrating to avoid incompatibilities, and test your application connection before switching DNS. Our support team can assist if you hit a blocker.

Yes. These Git forges are standard applications that install on any Linux VPS. Back up your data (repositories, configuration, database), transfer them to your ServOrbit VPS, then restart the application — the process is identical to a standard server migration. Our blog offers detailed step-by-step guides for the main forges.

Before migrating, export all your workflows from the n8n interface (Settings → Import/Export) and note your environment variables (encryption key, DB credentials). Stop the npm process, install Docker and Docker Compose on your VPS, then use the official n8n Docker recipe, mounting the same data directory (~/.n8n) into the container volume to preserve your workflows and credentials. Migrating to Docker is recommended by the n8n team before v3.0, which drops support for the global npm installation; our support team can assist you at [email protected].

Yes, Docker v29 introduces several breaking changes to plan for: the default bridge network has evolved, some `docker run` options deprecated since v24 have been removed, and the multi-arch manifest format has changed. Before migrating, audit your `docker-compose.yml` files and Dockerfiles for obsolete options, test in a staging environment, then switch. Our blog post on Docker v29 migration details the verification steps.

The process involves backing up your LangFlow flows (JSON export from the UI) and your Ollama models (`~/.ollama/models` directory), then transferring them to the new VPS via `rsync` or `scp`. After reinstalling the services on the new VPS, reimport your flows and verify environment variables (API keys, URLs). Plan a short maintenance window for the DNS switch to avoid any interruption.

Migrating from Oracle Cloud to a ServOrbit VPS follows a straightforward process: export your Docker images with `docker save`, transfer them via SSH or a private registry, then recreate your services using your existing `docker-compose.yml` files. For persistent data, copy your volumes with `rsync` or `docker cp`. It is recommended to test the setup on the new server before switching DNS, keeping a short TTL (300 seconds) to minimize the cutover window. ServOrbit VPS instances run Debian or Ubuntu and are compatible with all standard Docker images. Root SSH access is available from the moment your server is activated.

Yes, Mattermost includes a native import tool compatible with the Slack export format. The process involves exporting your data from Slack (a ZIP file provided through their admin interface), then converting and importing it using the `mattermost import slack` command or the `mmetl` tool. Messages, public channels, and attachments are generally recovered. Direct messages and some custom emoji may require additional handling depending on your version. It is recommended to run a test import on a clean instance before the final switch. The entire operation takes place on your ServOrbit VPS, with no dependency on any third-party service.

OpenProject includes an official Jira Migrator available since version 17.4 (beta released in May 2026). It migrates projects, issues (title, description, attachments, due date, estimated hours), issue identifiers, simple custom fields (text, numbers, dates, dropdowns), users, statuses, types, and comments. What is NOT migrated: issue relationships, sprint assignments, automated workflows, and complex permissions. Procedure: from your Jira instance, export a full XML file (Administration → System → Backup). In OpenProject, go to Administration → Import → Jira and upload the XML file. Migration time depends on volume — allow 15 to 30 minutes for fewer than 10,000 issues.

Gitea includes a built-in migration tool (Administration → Repositories → Migrate) that imports a GitHub repository by URL, preserving the full commit history, branches and tags via a `git clone --mirror`. To migrate multiple repositories, use the Gitea API with a script that iterates over your GitHub repos and triggers migration for each one. Once done, update your local remotes with `git remote set-url origin <new-url>`. See our `/vps-cloud` page to deploy a Gitea instance on your ServOrbit VPS.

Gitea includes native migration of issues and milestones from GitHub: when creating or updating the repository via the migration tool (or the `POST /api/v1/repos/migrate` API), enable the `issues`, `milestones` and `labels` options. A GitHub personal access token with `repo` scope is required to bypass API rate limits and access private repos. Comments, assignees and labels are also imported. For large issue sets, allow extra time proportional to volume as Gitea respects GitHub API rate limits.

Yes, via Plane's native CSV import: in Linear, export your issues as CSV (Settings → Export), then in your Plane instance go to Settings → Importers → CSV and upload the file. Titles, descriptions, priorities and labels are imported; comments are not covered by Linear's CSV format — only a full JSON export via the Linear API preserves them. For a complete migration including comment history, our support team can assist; contact us through the client area.

Confluence Data Center reaches end-of-life on March 28, 2029, when all instances become read-only. Docmost is an open-source alternative supporting spaces, permissions and collaborative editing; its native Confluence importer (Enterprise edition) preserves space hierarchy, attachments, internal links and draw.io diagrams. Migration involves exporting spaces as XML from Confluence (Administration → Backup Manager), then importing into Docmost. Without the Enterprise edition, migration is manual (HTML export, structure recreation and content copy-paste). Order a ServOrbit VPS with at least 2 GB RAM, deploy Docmost from the marketplace, and open a support ticket through your client area if you need assistance.

Planka v2.2.0 (released August 9, 2026) moved OIDC SSO from Community Edition to Planka Pro. Accounts that authenticated exclusively via SSO are deactivated after the upgrade. Planka has no native JSON or CSV board export (GitHub issues #22 and #670 unresolved) — the only reliable extraction is a PostgreSQL dump (`pg_dump`). To migrate: (1) take a full database snapshot before any cutover, (2) install Kaneo or Vikunja on a temporary subdomain and run both instances in parallel for 1–2 weeks, (3) manually transfer active boards, (4) switch DNS at D+7 and keep the snapshot for 90 days. Kaneo (MIT, v2.16.2) and Vikunja (AGPL-3.0, v2.4.0) both maintain free OIDC SSO — both available on the ServOrbit marketplace.

The Immich v2 to v3 upgrade removes the pgvecto.rs extension and replaces it with native pgvector. Before starting the update (from v1.132.3 onwards), back up the entire PostgreSQL volume with `docker compose exec database pg_dumpall -U postgres > backup.sql`. Update your `docker-compose.yml` to the `ghcr.io/immich-app/immich-server:v1.132.3` image, then run `docker compose pull && docker compose up -d`: the schema migration runs automatically at startup. Your photos, albums and shares are unaffected — contact [email protected] if the migration fails at startup.

Passbolt CE accepts CSV and JSON imports (Admin > Import passwords). From Bitwarden: export as unencrypted CSV. From 1Password: export in 1PUX format then adapt the columns to the expected format. Imported passwords are re-encrypted with the GPG keys of the designated recipients.

Forgejo v16 broke direct backward compatibility with Gitea: the team finalised the pivot to an independent database schema and config paths. To migrate from Gitea, the recommended path is to first move to Forgejo v7 or v8 (the last version still profiled for Gitea imports), run the schema migrations, then step up progressively to v16. A `gitea dump` followed by `forgejo admin` restore remains the cleanest method for moderately sized instances. Open a ticket from your client area if you need support for the operation on your ServOrbit VPS.

Supabase replaced Kong with Envoy Gateway as its internal proxy from August 2026: routing environment variables, timeouts, and plugin configuration differ significantly. Before pulling the update (`docker compose pull`), review your custom overrides in `docker-compose.override.yml` (Kong routes, rate-limit plugins, CORS), read the official release notes for Envoy equivalents, and snapshot your Docker volumes. Test the update on a staging VPS before applying it to production, and check Envoy logs on first start to identify any unmigrated routes.

Install the Forgejo Runner binary on your VPS, register it with a token generated in your Forgejo instance (Settings → Actions → Runners), then create your workflows under `.forgejo/workflows/` using the same YAML syntax as GitHub Actions. Most steps are compatible; only the GitHub-hosted runners (`ubuntu-latest`) need to be replaced with your runner's label (`self-hosted`). For sizing or configuration questions, open a ticket from your client area.

A brief interruption (a few minutes) is generally unavoidable during a major Chatwoot upgrade because database migrations are blocking. To minimise the impact: fully back up PostgreSQL and your volumes, test the upgrade on a staging environment, then schedule the switch outside peak hours. Chatwoot's notification channel remains available to agents during the maintenance window if you broadcast a status message beforehand. For help with planning, open a ticket from your client area.

WordPress migration can be done without downtime by following this procedure: **Step 1: Backup from old host** - Export MySQL database via phpMyAdmin or `mysqldump` - Archive WordPress files (especially the `wp-content/` folder) **Step 2: Set up environment on ServOrbit** - Create a VPS with Debian/Ubuntu and install WordPress - Restore database and files - Configure `wp-config.php` with new connection details **Step 3: Test before cutting over** - Access the new site via its IP (or a local `/etc/hosts` entry) before changing DNS - Verify all pages, media, and features work **Step 4: Reduce DNS TTL** - 24–48h before migration, reduce your DNS TTL to 300 seconds **Step 5: Switch DNS** - Change A/AAAA record to the new IP - Propagation takes 5 to 30 minutes with a low TTL The old host stays active during propagation — no visitor sees any interruption.

Yes, transferring a domain name doesn't interrupt your site if you follow the right procedure. **Key principle:** DNS and registrar are two separate things. Your site works as long as DNS servers respond correctly — regardless of who holds the registrar. **Zero-downtime procedure:** 1. **Before initiating the transfer**, ensure your DNS is managed at a stable provider (Cloudflare, your current host, etc.) — not directly at the registrar you're leaving. 2. **Unlock the domain** at the old registrar and get the EPP/Auth code. 3. **Initiate the transfer** at ServOrbit. 4. **During the transfer** (5–7 days for .com, .net; 2–3 days for .fr), your site continues working — the DNS doesn't move. 5. **After the transfer**: if your DNS was managed by the old registrar, you'll need to reconfigure it at the new one. Plan this step in advance.

In Notion, go to Settings → Workspace → Export content and select the Markdown & CSV format to get an archive of your pages and databases. This archive is the starting point for import into Docmost (Markdown import) or AppFlowy (Notion import). For large workspaces, allow a few minutes for Notion to send the download link by email. If you need help, reach out at [email protected].

Plane offers a native Jira importer: in your Plane instance, go to Settings → Importers → Jira, enter your Jira URL and an API token, then select the projects to import — issues, assignments, labels and statuses are transferred. For Jira Data Center (non-cloud), the import connector may require direct network access to your instance; run a test on a small project before the full migration.

The safest approach is a dump/restore: stop your application services, export the database with `docker exec <pg15> pg_dumpall -U postgres > dump.sql`, launch a new PostgreSQL 17 container, import the dump, and verify each database with `pg_dump --schema-only` before removing the old container. A ServOrbit VPS with full root access lets you run both containers simultaneously during validation. See `/vps-cloud` to choose the right configuration for your database size.

Yes, ServOrbit offers an M365-to-Nextcloud migration service covering emails (IMAP-to-IMAP), calendars (CalDAV) and contacts (CardDAV). The migration is performed in cutover or delta mode depending on mailbox volume, with no perceptible service interruption for your users. M365 licences can be temporarily maintained in parallel while validating the migration, then cancelled at your own pace. Contact our support team for a preliminary audit and a quote tailored to your organisation's size.

Migrating from Sentry to GlitchTip relies on a simple DSN (Data Source Name) swap in each application: GlitchTip exposes a Sentry-compatible API, so you only need to point your `SENTRY_DSN` environment variable to the new GlitchTip DSN without modifying the SDK or code. Alert rules, teams and projects must be recreated manually in GlitchTip as no automatic export exists between the two platforms. We recommend a dual-send phase (keeping Sentry active in parallel for a few days) to confirm GlitchTip captures all errors before the final cutover.

Export contacts from HubSpot via Settings > Data Management > Export > Contacts in CSV format. In Twenty CRM, use People > Import > CSV to upload the file; standard fields (first name, last name, email, phone) are mapped automatically. Custom HubSpot properties must be recreated manually in Twenty before importing.

Stalwart includes a migration tool and a migration proxy that work together to move accounts continuously: users keep sending and receiving emails throughout the transfer, account by account. In practice, point the proxy at the old server while the tool copies emails, folders, Sieve filters, address books and calendars; once an account is migrated the proxy redirects it straight to Stalwart. Before switching DNS, verify SPF, DKIM and DMARC records on the new VPS. Our team can assist you via a ticket from your client area.

Before any migration, export your data using open formats: CSV or JSON for databases, PDF for documents, ZIP for media files. Check that the export is complete — some SaaS providers do not include attachments or history. Keep a copy outside the service (local or object storage) before cancelling: once the account is closed, data becomes inaccessible. Also test the import into your target solution before cutting the old access, to avoid undetected data loss.

Start by auditing your current services: list what you pay for, the associated data and the critical integrations. Then choose an open source equivalent and test it on a development VPS before any switch. Plan the migration during off-peak hours, prepare a rollback plan and export your data beforehand. Migrate service by service rather than all at once: this limits risk and makes diagnosis easier if something goes wrong. Check that automatic backups are in place before cancelling your existing subscriptions.

Before any migration, take a full backup using Frappe's `bench backup` command — it exports the database and files in a single archive. On the new ServOrbit VPS, install ERPNext via the Marketplace template or manually, import the backup with `bench restore`, then update the site address in `currentsite.txt`. Verify uploaded file permissions and test access before switching the DNS from the old server to avoid any interruption. Our team can assist you with this migration via a support ticket.

Use the GitLab REST API (`/api/v4/projects?owned=true`) to list your repositories, then clone each one with `git clone --mirror`. Gitea includes a built-in import wizard (Administration → Migration) that accepts a GitLab URL and automatically creates repositories, issues, and pull requests. For read-only namespaces or groups, first export a tarball archive from GitLab (Settings → General → Export project), then import it into Gitea via the interface or its API. Plan for at least 2 GB of RAM on your VPS for a smooth migration.

From Kommo, export your contacts, companies and deals as CSV files via Settings → Exports. Then import these files into Twenty from the Import tab of each object (People, Companies, Opportunities). For attachments and conversation history, check the exports available in Kommo and keep them separately. Our team is available to help you plan the migration.

Jellyfin reads the same media folders as Plex directly: there is no need to copy or move your files. Point Jellyfin's libraries to your existing directories, let it scan and build its metadata. However, your playlists and watch history are not automatically carried over from Plex. If your instance runs on a ServOrbit VPS, the attached storage remains unchanged.