Before you start
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
Choose the migration method
An application migration installs a clean compatible OS and restores selected software and data. A backup migration depends on a supported restore format. A full-system or disk-image migration additionally depends on architecture, firmware, disk layout, drivers, bootloader and virtualisation. A snapshot from one provider is not automatically portable to KVM.
Record the exact versions, startup settings, storage actually used and external dependencies. Inventory accounts, permissions, scheduled tasks, databases, licences, certificates and services outside the file directory. Check what the old provider permits you to export before cancelling anything.
- application restore
- supported backup restore
- system image compatibility
Inventory services without changing the source
Record OS, architecture, package and application versions, mounts, disk usage, users and UID/GID, permissions, ACLs and extended attributes. List enabled services, timers and cron jobs, databases, certificates and external endpoints. The read-only examples below are inventory aids, not migration commands. Commands may be absent on a minimal installation.
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
- systemd services / timers
- cron / users / UID / GID
- mounts / ACL / xattrs
OS and architecture
cat /etc/os-release
uname -mNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Disk usage and mounts
df -hT
lsblk -fNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Enabled services and timers
systemctl list-unit-files --state=enabled
systemctl list-timers --all
crontab -lNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Back up databases consistently
Select an engine-specific backup method and test restoration. A file copy of a live database or a filesystem snapshot alone does not establish application consistency. For MySQL/MariaDB, transactional dump options have engine and concurrent-DDL limits; keep schema, data, routines/events as needed and recreate appropriate users and privileges.
Prepare a destination with compatible software, enough working space for both restored data and temporary archives, and the required ports and permissions. Match versions for the first restore; plan upgrades as a separate change. A matching amount of RAM or vCPU does not prove equivalent performance.
- files ≠ SQL export
- engine / version / collation
- consistent backup
- restore test
Prepare a clean destination and safe copy
Match versions initially and confirm disk, architecture and privileges. Preserve ownership and permissions where the destination supports them. A local rsync dry run can preview a directory copy; it does not perform the transfer, open SSH or validate the application. Check paths and trailing slashes before any later real copy. Never overwrite a live destination’s network configuration from the source.
Plan a write freeze and take a final consistent export. Transfer files and database exports separately where required. Compare file counts, sizes and checksums of the same stable archive on both sides. A matching checksum proves transfer integrity, not application consistency or completeness.
- compatible OS / dependencies
- ownership / ACL / xattrs
- local dry run
- stable archive checksum
Preview a LOCAL directory copy only
rsync -aHAXn --numeric-ids -- /source/ /destination/No real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Compare the same stable archive on each side
sha256sum /path/archive.tar.gzNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Test services, certificates and access privately
Restore configuration and data, review environment variables privately and test services as their intended users. Verify SQL reads/writes, certificates, scheduled tasks, mail relays and firewall requirements. Establish a working console or recovery route before changing access rules. Do not assume the source IP, gateway or interface name exists on the destination.
Test privately before opening access: startup logs, authentication, permissions, representative data, persistence after a clean restart and external dependencies. Check certificates and required TCP/UDP ports without exposing administration interfaces publicly. Keep a record of checks and unresolved differences.
- service accounts
- SQL read + write
- certificates / scheduled jobs
- new IP / ports
Freeze writes, switch and monitor
Schedule a final coherent synchronisation, stop conflicting writers and validate the destination. Change DNS where applicable, monitor both environments during cache expiry and check scheduled work is not running twice. Keep rollback data and record the point after which new writes need reconciliation. Cancel the old service only after acceptance.
Switch the published address or DNS only after the private checks. Account for TTL and caches; an IP change is normally required when changing provider. Monitor errors, resource use and new writes. Set a rollback decision point. Rolling back after new writes requires data reconciliation, not simply switching DNS back.
- final synchronisation
- A / AAAA / MX as applicable
- avoid duplicate scheduled jobs
- rollback after new writes
For your situation
| Situation | Next check |
|---|---|
| Before moving | Do not start the cutover until a complete backup has been restored successfully in a private test. |
| During the move | A live copy can miss concurrent changes. Plan an application-specific replication and final synchronisation procedure with a qualified administrator; no uninterrupted move is promised. |
| After switching | Keep the old host and original backups until data, connections and persistence have been checked. Decide who can authorise the switch and how to handle writes created after cutover. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.