Migration

Yes. Our migration assistant is included with every plan, Start included: it transfers your domains and restores your cPanel accounts in a single order, with no service interruption. From Business upwards, end-to-end handling by our team is also included.

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.

How long it takes depends on the size of the site and the volume of data. It runs in three stages: transfer (domains by EPP code, cPanel account restored from a backup or by direct transfer), verification of the site on our servers, then the DNS switch — your site stays online at your current host until that switch. 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.

The migration assistant (transfer of your domains and restoration of your cPanel accounts) is included with every plan, Start included: you only pay for your services. From Business upwards, end-to-end handling by our team is also included.

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, use the Linear API: you carry out the migration yourself, and our support answers your questions from 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. You carry out this migration yourself; our support answers your questions via a 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.

ServOrbit offers an assisted migration that copies your files and database to our servers before any DNS change. Once validated on the new hosting, the DNS switch takes only a few minutes, limiting downtime to TTL propagation. Contact [email protected] to schedule your migration.

We do not quote a typical duration: it depends on the volume of data and the number of accounts to migrate. The process, however, is always the same: transfer (domains by EPP code, cPanel accounts restored from a backup or by direct transfer), verification on our servers, then the DNS switch. Your source hosting is not modified: the site stays online at your current host until the switch. The migration assistant is included with every plan, Start included, and end-to-end handling by our team is included from Business upwards. For a special case, write to [email protected].

The recommended approach is to export your database via mysqldump on the old hosting, import it on the VPS while the old one stays active, then switch your application configuration to the new server after a consistency test. ServOrbit can coordinate this operation for you; contact [email protected] to schedule the migration outside peak hours.

Yes, it is possible to migrate your company emails from shared hosting to a ServOrbit VPS. The migration involves transferring mailboxes, contacts, and message history via the IMAP protocol. We recommend using a tool like imapsync to avoid any data loss: you carry out the migration yourself, and our support answers your questions. Plan an appropriate DNS cutover window and keep access to the old hosting for 48 to 72 hours to ensure service continuity.

Migrating from Odoo.sh or the official SaaS to a self-hosted VPS is technically feasible, but involves several steps. First, export a PostgreSQL database dump and the `filestore` directory from the source platform. On the VPS, an Odoo installation at the same major version is required before importing the data. Modules developed specifically for the cloud platform (Odoo.sh integrations, paid Enterprise modules not included in Community) must be identified and replaced. Finally, SSL certificates, DNS configuration, and SMTP access must be reconfigured on the new server before switching over traffic.

Migration happens in three steps: export your content from Squarespace (Tools → Export), import it into Ghost via its admin panel, then point your domain to your ServOrbit VPS. Ghost installs in minutes on a VPS via our Marketplace; plan for at least 1 GB of RAM. For any question, open a ticket from your client area with your migration timeline.

Yes, migrating Plex or Jellyfin to a ServOrbit VPS involves three steps: exporting the database and metadata folder from your current installation, transferring it via rsync or SCP to your new VPS, then reinstalling the server pointing to the same paths. Metadata, playlists, and watch progress are preserved as long as library paths remain identical or are correctly reconfigured. Our root VPS plans give you full freedom over directory structure. Contact [email protected] with any question about the data transfer.

Plane includes a native Asana importer accessible from workspace settings (Settings → Importers → Asana). It imports projects, tasks, sub-tasks, assignees, due dates, and comments. Activity history is partially preserved: dated comments and status changes are included, but large attachments may require manual transfer depending on their size. Before starting the import, generate an Asana personal access token and grant read access to the relevant workspaces. The migration does not delete anything on the Asana side: you can run both systems in parallel while validating. Once Plane is installed on your ServOrbit VPS (it is not yet offered for order on the Marketplace), the importer runs directly in the web interface — no CLI commands are needed. For large-scale migrations (more than 10,000 tasks), run the import outside peak hours to avoid timeouts.

The process always follows three steps: export your data from the SaaS platform (dashboard or API depending on what it offers), deploy the application on your ServOrbit VPS, then import your data. Some applications include a built-in native importer; for others, the transfer goes through files or the database. ServOrbit offers ready-to-use VPS templates on the Marketplace for the most common applications — the template includes initial configuration and the reverse proxy. Open a ticket from your client area if you need help with a specific migration.

The migration takes a few steps, which you carry out yourself: export your emails via Google Takeout (MBOX format), then import them into Nextcloud Mail or Roundcube on your ServOrbit VPS. For Google Drive files, install Nextcloud from the ServOrbit marketplace with one click, then use the built-in migration tool (rclone or the Nextcloud Google Drive connector). The full procedure is documented in our Google Workspace migration guide.

The recommended approach is to prepare the environment on ServOrbit before switching DNS: duplicate your site on the target VPS or hosting, test it via your local hosts file, then lower the DNS TTL to 300 seconds 48 hours before migration. Once the transfer is validated, update your DNS at ServOrbit. Propagation typically takes less than 15 minutes with our Cloudflare infrastructure. Our support team can assist with this switchover on request.

Migrating from Bitwarden Cloud to a self-hosted Vaultwarden instance takes three steps: export your vault from the Bitwarden app (unencrypted or encrypted JSON), deploy Vaultwarden on your ServOrbit VPS via Docker, then import the file into your new instance. Vaultwarden is compatible with the official Bitwarden client: no app reinstallation is needed, just point it to your domain. Our detailed guide covers every step: Migrate from Bitwarden Cloud to Vaultwarden on VPS.

Migrating an e-commerce site follows the same main steps as a standard migration, with particular attention to the database: export a full backup (files + SQL dump) from your current host, import it to your ServOrbit hosting, then test your site by editing your local hosts file before changing any DNS records — this keeps your store accessible to your customers throughout the operation. Then update the database connection settings in your application's configuration file (wp-config.php for WooCommerce, parameters.php or .env for PrestaShop). Once testing is complete, update your DNS records; propagation generally takes less than 24 hours. Our assisted migration service can handle the entire process — contact us at [email protected].

Yes, you can migrate only your database (MySQL, MariaDB, or PostgreSQL) to a ServOrbit VPS while keeping your site on another hosting provider, provided your application can connect to a remote database. You will need to configure network access (firewall rules, remote MySQL user) and update the connection credentials in your application. The migration assistant covers full cPanel accounts moving to a hosting plan; a single database moving to a VPS is migrated by you, and our support answers your questions by ticket from your client area.

Yes, with conditions. YNAB lets you export your transactions in CSV format from the Reports tab. Maybe.co (formerly Maybe Finance) accepts CSV transaction imports. The process preserves amounts, dates, and categories, but YNAB budget rules (envelopes) do not transfer natively — you will need to recreate them manually in Maybe. First run a test on a partial export before migrating your full history.

Atlassian provides an official Cloud-to-Server (or Data Center) migration tool accessible from your Cloud instance's administration interface; it exports projects, issues, spaces, and history into an archive importable on your new VPS. Before starting the migration, provision a VPS with at least 4 GB of RAM, install the same major version of Jira or Confluence, and ensure the server is reachable over HTTPS with a valid TLS certificate. Our support team answers your questions at [email protected] about import steps and DNS configuration.

Your ranking on Google.ma depends on the geographic targeting declared in Google Search Console, not the physical location of the server. Before migrating, set your Morocco geographic target in Search Console, ensure your .ma domain remains the canonical URL, and put 301 redirects in place if any URLs change. You copy your files and databases to the VPS yourself, and our support answers your questions; the assistant described on our migrations page covers cPanel hosting.

A zero-downtime migration relies on three steps: first, an initial logical dump with `pg_dump` followed by a restore on your VPS; then, setting up logical replication (PostgreSQL replication slot, version 10 or later) to catch up on ongoing writes; and finally, switching the application connection string during a short planned window. You should test the restore and performance on your ServOrbit VPS before switching, and keep the RDS instance active in read-only mode for a few hours after migration to allow a quick rollback if needed. See the dedicated article in our knowledge base or open a ticket at [email protected] for personalised guidance.

Yes: the subscriber list can be exported, usually as a CSV file, from your current tool and imported into the new one. Also export each contact's status (subscribed, unsubscribed, bounced address) and import unsubscribed contacts as such, never as active: emailing them again triggers complaints that damage your domain's reputation. Before the first send from the new service, add the SPF and DKIM records it provides to your domain's DNS zone, and keep bulk sending on that service rather than on your professional mailbox. For help with these DNS records, open a ticket from your client area.

The project export brings over the code, issues and merge requests, but not CI/CD variables, webhooks, tokens, job artifacts or container registry images. List these items before switching and recreate them by hand on the new instance, keeping the old project read-only until you have validated everything. ServOrbit provides a step-by-step guide but does not carry out the migration for you.

During DNS propagation some visitors still reach the old server, and whatever they submit there does not arrive on the new one. Lower the TTL in advance, run a final sync of the database and files just before the switch, then put the old site in maintenance mode or disable checkout and forms for the duration of the transition. Keep the old hosting active afterwards and check that no order or comment landed there after the sync before you cancel it. For a shop, assisted migration can help: write to [email protected].

Duplicate the files and the database on a separate subdomain, password-protected and set to noindex, then replace the site address in the database with a tool that handles serialized data, not a plain search-and-replace. On the copy, switch off outgoing e-mails, real payments and scheduled tasks, so the client receives nothing. Validate the update on the copy, then redo it on production after a backup rather than copying the staging site back: it would overwrite the orders and comments received in the meantime.

Avoid doing both at the same time: if the site breaks, you will not know whether the move or the upgrade is to blame. Migrate as is first, choosing in cPanel the same PHP version as on the old host, and validate the site. Then upgrade on a copy, test, and apply to production with a fresh backup. If the current version is no longer maintained, plan the upgrade right after the switch rather than putting it off.