Hosting migration checklist with testing and rollback
Plan a hosting move with file and database copies, private credentials, destination tests, DNS cutover and a verified rollback window.
Content revised · English
- Guide type
- Move & recover
- Examples
- Illustrative, environment-specific
- Integration scope
- No remote machine connected
Inventory the complete application
Record web files, databases, uploads, scheduled jobs, mail, certificates, DNS, third-party integrations and secrets. Check runtime versions and licences on the destination. An image export is useful only if the destination supports its format and networking.
Make the first copy before changing DNS
Use a private transport and a destination directory you control. The example copies contents rather than nesting the source folder, and starts with a dry run. It deliberately omits a deletion option. Verify ownership and permissions on the destination.
rsync -avzn -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/
# After reviewing the dry run and destination:
rsync -avz -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/Export the database with its native method
Copying the files of a running database does not replace an application-consistent database export. MySQL’s single-transaction approach is appropriate for transactional tables and still needs care around schema changes or nontransactional tables. Use a protected destination for the export and prompt for the password rather than embedding it in an argument.
mysqldump --single-transaction --routines --triggers --events \
-u app_user -p app_database > /private-backup/app-database.sqlThe output path is illustrative and must be private, writable and outside the web root. For PostgreSQL, use its pg_dump / pg_restore workflow instead.
Test the destination before the cutover
Use a temporary hostname or a controlled local DNS override. Test login, writes, uploads, background jobs, outbound messages and HTTPS. Copy secrets through a private channel and avoid running both sides’ scheduled jobs against the same external service.
Make a final consistent copy and move the route
Lower TTL in advance, pause writes where necessary, export the last changes and complete the final file sync. Update DNS only after destination checks pass. Keep the old host and independent backup during the rollback window; DNS caches can continue sending some visitors to the previous origin.
Retire the old service only after acceptance
Monitor errors and compare critical records after the move. Reconcile any writes that reached the old origin. Confirm mail and external callbacks, then close the old service according to its billing and data-retention rules. No zero-downtime or automatic migration is claimed.
Leave with a verifiable result.
- Inventory files, database, runtime, scheduled jobs, mail, DNS and integration dependencies.
- Keep exports, credentials and recovery keys outside the public web root.
- Test login, writes, uploads, HTTPS and background jobs on the destination.
- Pause or reconcile writes during the final copy, then change DNS.
- Accept the application and restore checks before retiring the old service.
Questions, answered.
Does changing DNS copy my website?
No. DNS changes where visitors are routed; it does not transfer files, databases, mailboxes, scheduled jobs or credentials. Test the complete destination before moving the route.
Can both hosts continue accepting writes during a move?
Only with a deliberate synchronisation and reconciliation design. Otherwise use an appropriate maintenance window for the final consistent copy. DNS caches can still send requests to the previous origin after a change.
Is migration performed automatically by OmbraHost?
No migration or remote provider connection runs in the application. Prepared migration options need a confirmed scope, access, cutover and rollback plan before real work is offered.