What to check before migrating a hosting account

A safe migration starts before you copy any files. Preparing this inventory tells you what needs to be moved, helps you choose a suitable plan and stops a website, mailbox or external service from being left behind at the previous provider.

If you have not yet decided on the route, start with the guide to migrating a hosting account to Hostsuar.

Migrating your hosting service to Hostsuar is free. You can use this list to prepare it yourself or to give us the information we need so our team can handle the process.

Define the scope

Write down which items must work at Hostsuar after the move:

• Domains and subdomains.
• Websites, directories and applications.
• Databases.
• Email accounts and stored messages.
• Redirects, filters and autoresponders.
• Scheduled tasks or cron jobs.
• DNS records for external services.
• Your own certificates, if you use any that cannot be issued again.

Transferring the domain does not copy any of these items. Decide separately whether you only want to migrate the hosting or also change the domain's registrar.

Identify the current panel and provider

Check whether the source uses cPanel, Plesk or another panel:

• cPanel: usually lets you generate a full backup that the destination supports.
• Plesk or another panel: confirm which transfer method the source supports. If there is no compatible import, files, databases, email and configuration will have to be moved separately.
• Closed platform: services such as Wix may not let you export a complete application and may require a rebuild.

Also confirm whether the provider keeps the hosting and the DNS zone active when the domain is transferred. Do not start the administrative transfer if it could lead them to delete the content before it has been copied.

Work out the space you need

Check separately:

• Website files.
• Databases.
• Mailboxes.
• Backups stored inside the account.
• Temporary directories, logs and caches.

The total space shown by the panel may include old backups or files you can do without. Do not choose the destination plan based on that figure alone: tell apart the content you need from what can be cleaned up before migrating.

Check application compatibility

For each website, write down:

• Application and version: WordPress, PrestaShop, Joomla or another.
• PHP version and required extensions.
• MySQL or MariaDB version and size.
• Scheduled tasks.
• External processes, queues or commands that need to run.
• Licences tied to the domain or IP address.
• Integrations with payment gateways, APIs, storage or third-party services.

A successful copy does not guarantee that an old application will work with a different version of PHP or the database. Resolve these incompatibilities before the move or temporarily keep a compatible version on the destination.

Inventory domains and DNS

Save a copy of the DNS zone and pay particular attention to:

• A and AAAA records for the website and subdomains.
• MX records for email.
• TXT records for SPF, DKIM, DMARC and verifications; some providers publish DKIM using CNAME.
• CNAME and SRV records for Microsoft 365, Google Workspace or other services.
• Subdomains used by applications, phone systems, calendars or external tools.

If email stays with Google Workspace, Microsoft 365 or another provider, recreate their records in the new zone before changing the DNS servers.

If you change the DNS servers and the domain uses DNSSEC, also coordinate the change of its keys and DS records. Keeping a DS record that does not match the new zone can stop the domain from resolving.

Inventory email

For each domain, find out:

• Which provider currently receives the email.
• How many mailboxes there are and how much space each one uses.
• Whether IMAP, POP or Exchange is used.
• Whether messages stay on the server or only on the devices.
• Which forwarders, filters and autoresponders are set up.
• Whether contacts, calendars or files that are not part of the IMAP mailbox are used.

Imapsync copies messages, folders and their status between IMAP servers, but it does not replace a full Microsoft 365 migration and does not copy calendars, contacts or external rules on its own.

Prepare access

Depending on the source, you may need:

• Temporary cPanel access to generate a full backup.
• SFTP or FTPS restricted to the directories that will be copied.
• A temporary database user limited to the databases needed.
• IMAP access or an app password for each mailbox to be synchronised.
• Access to the DNS provider to make the final change.
• Availability to approve a second authentication factor when needed.

Do not send passwords, auth codes or two-factor codes in the text of a ticket or email. If support needs to access the source, ask for the secure channel and use temporary credentials, different from your usual ones and with the smallest possible scope.

Decide when the move will happen

The usual route is:

1. Create and size the destination service.
2. Make a first copy of websites, databases and mailboxes.
3. Check the content without changing the DNS.
4. Fix incompatibilities and recreate the external DNS records.
5. Schedule a window with little activity.
6. Copy the latest database changes and synchronise email again.
7. Change the DNS.
8. Check the website, email, HTTPS and external services.
9. Keep the source active during the transition.
10. Revoke access and cancel the previous provider only after the final check.

For shops, booking systems, forums and websites with dynamic content, avoid changes continuing to happen on both servers during the cutover. If activity cannot be stopped, agree how the final synchronisation will be done.

Decide which server will run the scheduled tasks during the transition to avoid duplicated emails, payments or other processes. Write down when to stop the move and how to recover the service. Pointing the DNS back to the source does not on its own recover orders or messages that have already reached the destination.

Information you can provide without including secrets

To review a migration, tell us:

• Current provider and panel.
• Domains, websites and subdomains included.
• Space used by files, databases and email.
• Main applications and versions.
• Email provider and number of mailboxes.
• Whether email will stay elsewhere or also be moved.
• Who currently manages the DNS zone.
• Deadline or preferred window for the move.
• Whether the website receives orders, forms or frequent changes.

With this information we can assess the scope and then confirm which temporary access is actually needed.

Check before you start

Do not start the move until you can answer yes to all of these:

• I have a recoverable backup of the current content.
• I know which provider serves the website and which serves email.
• I have identified all external DNS records.
• The destination service has enough space and compatible versions.
• I can access the content, databases and mailboxes that will be copied.
• I can change the DNS when the time comes.
• The previous provider will stay active during the transition.
• I know how to check the website and email before cancelling the source.

Once the inventory is complete, continue with the hosting migration route.