Cyclone Hosting practical guide: A low-downtime migration is a sequence of inventory, copying, testing, DNS planning, and post-move monitoring.
Good Migrations Are Planned Before Files Move
A website migration involves more than copying public files. You may also need databases, email, DNS records, SSL, scheduled tasks, configuration files, and application-specific settings.
Inventory The Current Site
- Website files and document roots
- Databases and users
- Email accounts and forwarders
- DNS records
- PHP version and extensions
- Scheduled tasks
- SSL and redirects
Create Independent Backups
Download copies of files and database exports before the move. Do not rely only on a control-panel transfer.
Build And Test Before DNS Changes
Upload the site to the new server and test it using a temporary URL, hosts-file entry, or staging domain. Verify forms, logins, database writes, uploads, and email.
Prepare DNS
Lower TTL values ahead of time when possible. Record every existing DNS entry, especially mail, verification, and third-party service records.
Handle Dynamic Data Carefully
Stores, forums, and membership sites can change while the migration is happening. Plan a brief maintenance window or final database synchronization to avoid losing new orders or posts.
Switch Traffic
Update the required DNS records or nameservers. Keep the old hosting account active while caches expire and visitors begin reaching the new server.
Monitor After The Move
Check access logs, error logs, forms, email, SSL, and important application functions. Keep the old backup until the new environment has been stable for several days.
Inventory The Website Before Copying It
Record the application, PHP version, database engine, storage use, database size, scheduled jobs, mailboxes, DNS provider, SSL coverage, external services, and any license tied to the old server address. List every hostname, including www, subdomains, mail, staging, and API endpoints. A migration can copy all visible pages and still fail because a cron job, webhook, or private upload directory was missed.
Separate The Transfer From The Cutover
The transfer copies data to the destination. The cutover changes public traffic. Keeping those as separate stages creates time to test. Build the destination, import files and databases, set the required PHP version, update private configuration, and test without changing public DNS. A local hosts-file entry or provider-approved preview method can direct one test computer to the new server while visitors remain on the old one.
| Before cutover | During cutover | After cutover |
|---|---|---|
| Inventory, backup, lower TTL, copy, and test | Freeze changes if needed, make a final sync, update the smallest required DNS records | Check authoritative DNS, HTTPS, forms, logs, mail, jobs, and external integrations |
| Define rollback conditions | Record exact old and new values | Keep the old service available through the agreed window |
Dynamic Sites Need A Final Sync
A store, forum, or membership site can change while the first copy is being made. Plan how new orders, posts, uploads, and account changes will be handled. Options include a brief maintenance window, a database replication method, or a final database and upload sync immediately before DNS changes. Do not overwrite newer destination data with an older source copy after testing begins.
Plan Email As Its Own Migration
Website and mail records can point to different providers. Determine whether mailboxes are moving, how existing messages will be copied, and which MX, SPF, DKIM, DMARC, autodiscovery, and client settings must remain. If only the website moves, preserve the existing mail records exactly. Test inbound and outbound mail from an outside account after the cutover.
Use A Written Validation List
- Home page, representative inner pages, images, downloads, and redirects
- Administrator login, file uploads, search, forms, and password-reset mail
- Store checkout or another safe transaction test when applicable
- HTTPS on every required hostname with no mixed-content warnings
- Background jobs, webhooks, APIs, analytics, and license callbacks
- Server logs and resource use under real traffic
Do Not Cancel The Old Host Too Early
Wait until DNS caches have expired, traffic reaches the new destination consistently, email is verified, and the rollback window has passed. Keep a final archive independent of both providers. Only then remove old data according to the provider’s cancellation and retention process.
WordPress maintains an official migration reference. Cyclone Hosting migration requests are reviewed individually because source access, application size, email, and downtime requirements differ.