How to move a VPS to another provider: a migration checklist

Choose a migration method that fits the workload

To move a VPS between providers, first decide whether you can export and import a compatible virtual-machine image or should rebuild the destination and move the application and its data. Do not assume a provider snapshot can be restored by another platform: supported image formats, virtual devices, boot configuration, licences and network settings vary. Check both providers’ current documentation before relying on an image transfer.

For a website or application, a tested file and database move is often easier to validate than carrying over an entire server image. The right method depends on the operating system, application, storage and acceptable interruption. A VPS migration is not automatically a live migration, and no checklist can guarantee zero downtime. Keep the source available until you have verified the destination and have a defined rollback decision.

A snapshot is useful only for the recovery task and platform that support it. See what a VPS snapshot can and cannot recover before treating one as a portable backup.

Inventory the source VPS and its dependencies

Record what the server runs and who controls each dependency before ordering or building the replacement. Include the operating-system release and architecture; CPU, memory and disk use; attached block or storage volumes; every container image and service; Docker or other container persistent volumes and bind mounts; web server and application versions; database engine and version; scheduled jobs; service users; firewall rules; TLS certificates; monitoring; and any external storage, APIs, SMTP relays or IP allow-lists.

Record the public IP addresses and DNS records, including mail-related records if the server sends email. Check whether reverse DNS, provider licences, IP restrictions or application licences are tied to the old address or supplier. List which credentials, keys and secrets must be rotated or transferred through an approved secure method. Do not copy the old machine identity or private keys blindly, and never put secrets in a migration checklist or support ticket.

Confirm who is authorised to change the guest operating system, application, DNS and provider account. Managed service labels do not by themselves identify who owns every migration step; follow the accepted Order and service schedule.

Prepare the destination and copy recoverable data

Provision the destination with a supported operating system and enough tested disk, memory and CPU headroom. Apply security updates, configure access and firewall rules, and verify console or recovery access before moving the application.
Take an application-aware backup of files and databases. Store a separate copy that will remain available if either VPS is lost, then verify that the archive can be read and test a restore where practical. A successful file copy alone does not prove that the application can recover.
If the workload uses containers, inventory and back up each persistent volume and bind mount separately from the container image. Follow the container runtime’s supported procedure, preserve required ownership and mount paths, restore the data on the destination, and verify it before cutover. A copied image alone does not include data held in an external volume.
Copy application files and required configuration using an authenticated encrypted transfer. Preserve intended file ownership and permissions, but review machine-specific paths and settings instead of copying them unchanged.
Export and import databases using the database vendor’s version-matched procedure. Check consistency requirements, table engines, character sets, extensions, users and grants. For example, MySQL documents that --single-transaction gives a consistent view for InnoDB tables but not changing non-transactional tables; concurrent DDL can also affect a dump.
Recreate scheduled jobs, background workers, mail routing, TLS and monitoring with the target’s actual addresses and service configuration. Verify that required secrets are present without exposing them in logs or shell history.

For a website database, see how to move a database and verify character encoding. If the application writes while files or a database are copied, plan a later final sync or a controlled write pause; an early copy can become stale.

Test the new VPS before changing public DNS

Keep the public hostname pointing to the old VPS while you test the destination. Where the application supports it, use a temporary hostname or a local hosts-file override so you can test the real site name against the new IP without changing what other visitors reach. Restrict or noindex a temporary public test site so it is not mistaken for the live site.

Check sign-in, representative pages, uploads, database writes, forms, background jobs, scheduled tasks, outbound email, TLS, redirects and monitoring. Confirm that logs reach the expected place and that the replacement handles the workload without resource or permission errors. Test the backup and restore path for the destination, not just the initial import. Google’s hosting-move guidance likewise recommends testing the new infrastructure, reviewing site features and monitoring old and new traffic after the DNS change.

Do not run two writable copies of an application against independent databases unless the application is specifically designed for that setup. Decide which server is authoritative during each migration phase.

Cut over with a final data sync and a rollback plan

Choose a maintenance window if writes cannot safely continue during the final copy. Lower relevant DNS TTLs in advance where the DNS provider permits it, and note the previous values.
Take a final application-consistent database export or synchronisation step. Pause writes or use the application’s supported replication procedure so changes are not split between two independent copies.
Apply the final file and data changes to the target. Check DNS, TLS, firewall access and any services that depend on the public IP.
Change only the necessary DNS records at the authoritative DNS provider. Keep mail records and other unrelated records intact. Use the reversible DNS cutover checklist for the website side of the move.
Monitor both VPSs, application and database logs, DNS answers, error rates, forms and email delivery. Resolver caches can mean that some users still reach the old address for a time.

Define rollback triggers before cutover, such as failed health checks, missing data or an unresolved application error. If you roll traffic back after new writes have reached the destination, reconcile those writes before reopening the old copy; otherwise customers may see missing or conflicting changes. Restore the previous DNS values only after you know which copy is authoritative.

Retire the old VPS only after verification

Keep the old VPS and a recoverable backup until the destination has handled real traffic successfully and the migration owner has checked that required data, mail, scheduled work and integrations are present. There is no universal waiting period: agree one that fits the application, DNS caching, data-change rate and recovery plan. Check provider billing, licence and retention terms before cancelling the old service.

After decommissioning, remove temporary credentials, test host entries and obsolete firewall rules. Update monitoring and documentation with the new provider, IP addresses, recovery owner and verified restore procedure. If the server sends mail, check the receiving provider’s requirements for the new IP, including reverse DNS; see the VPS reverse-DNS (PTR) guide.

For a Novasean Managed VPS, use only the switching and exit terms incorporated into your accepted Order. The current VM Start with Managed OS schedule includes reasonable infrastructure switching assistance and available VM data/configuration handover information without a separate switching or data-egress charge, when that schedule applies to your accepted Order. This does not include moving or changing your application, reconciling application data, or other application-specific work; agree the scope and price for that separately. Exit rights do not promise that another provider will reproduce the same managed features or that every application can be moved without work. Contact support before a planned change if you need to confirm which service boundary applies.

Common questions about moving a VPS

Can I move a VPS by copying its snapshot? Sometimes, if the destination provider accepts a compatible image and the guest configuration works there. Verify the exact image format, boot mode, virtual devices, licence and network requirements with the destination provider; otherwise plan an application and data migration.

Can I move a VPS without downtime? Some workloads can reduce interruption with replication and a short final cutover, but this depends on the application, database, DNS and both providers. Plan for a maintenance window unless your tested design demonstrates otherwise.

When can I cancel the old VPS? Only after the destination has passed the agreed checks, required data is available, the rollback period is over and the old provider’s contractual and retention terms have been checked.

Will my website keep its Google rankings after a VPS move? Keeping the same URLs and testing the new hosting can reduce avoidable problems, but rankings are not guaranteed. Follow Google’s current hosting-change guidance and monitor Search Console and site availability.

Sources and technical references

Prepared by Team Novasean from the references above. Menus and available features depend on your installed version and service permissions.

Related guides

Was this guide helpful?

If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .

Need help with your service?

Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.