Move to CloudExa from another hosting provider

A provider move includes access, application data, databases and DNS. Plan those pieces before cancelling your old service. This checklist applies to websites, VPS applications and game communities; use the Minecraft file-transfer guide for game-specific steps.

Write down what needs to move

List the services you actually use: application files, uploaded media, databases, scheduled jobs, mail, certificates and external integrations. Record software versions and storage usage. Check whether your old host runs a database or mail service outside your server; a machine or game-file backup may not include either.

Confirm that you can sign in to the old service, CloudExa and your domain's DNS account. Store recovery codes somewhere you can access during the move. Use your own accounts or authorised team access rather than sending passwords in chat.

Prepare a destination and rollback copy

1. Check the new service's resources, assigned addresses and available disk space. An archive and its extracted contents need space at the same time.
2. Start with compatible software versions. Keep upgrades separate until the move works so you can identify migration problems.
3. Download a complete backup to a location outside both servers. Check that the archive opens and includes the folders you expect.
4. Export databases using the application's supported procedure. Preserve database names, character sets and required users without publishing passwords.
5. Choose a quiet maintenance window and tell users when writes or logins will pause.

Keep a record of the original DNS values and TTLs. Export the zone if your provider supports it, then check that the export includes your records. Preserve unrelated mail, verification and service records.

Transfer and test before changing DNS

Stop writes on the old application for the final file copy and database export. For Minecraft, stop the server and wait for saving to finish. Import files and databases into the destination, then update application connection details, paths, ports and scheduled tasks.

Test with the new address or a temporary hostname. For a website that requires its normal hostname, use a local hosts-file override or another application-supported test method. This changes only your test computer; other users still reach the original service.

Check login, uploads, database writes and application-specific actions. For a game, visit existing builds and verify inventories and permissions. Restart the application during the window and confirm changes persist. Check certificate names and redirects before relying on HTTPS.

Switch traffic and keep one writable copy

Change the intended DNS records after testing. Check both A and AAAA records where present. Keep the old application stopped or read-only while cached DNS answers expire, so users cannot write conflicting data on two machines. Recheck scheduled jobs and outbound integrations to avoid duplicate processing.

If you must roll back after accepting new writes, reconcile those changes first. Pointing DNS back alone can lose recent activity. Keep the old service and verified backups until you have checked normal traffic and any remaining commitments. Cancelling a service is a separate billing action.

For help, send a support ticket with your service ID, application, approximate data size and planned window. Never include passwords in screenshots.

Further reading: Cloudflare DNS import and export; Paper migration notes.