PoolByte

cPanel migration: Move website files, databases and email

· PoolByte

cPanel migration: Move website files, databases and email

cPanel site migration is broader than just uploading an archive to a new account. Web files, database, email, working versions and DNS scheme should be considered together. Opening the home page on the new server does not indicate that critical operations such as login and order are working. For a controlled migration, first determine the scope, then test the new environment and change the release target.

List the services to be migrated

Type the main domain, additional domain and subdomain names in your account. Determine which name uses which folder and where the database and mail service are located. Do not consider an application that goes to a separate server to be moved to a new hosting account just because it is under the same domain. If there are shared folders or external storage connections, add them to the inventory as well.

Add scheduled task, redirect, PHP version, required extensions, and application connection settings to this list. A panel copy can carry some elements, but the scope depends on the chosen method and authorizations. Assuming that a service that has not yet been created in the new account has been automatically created, makes post-migration error investigation difficult.

Verify compatibility of new environment before release

Compare the PHP and database versions of the source and target environment. The newer version may not work smoothly with every older application; Test plugin, theme and custom code compatibility. Downgrading the version to a level where there is no security support just to finish the migration is not a permanent solution.

Check that the disk, mail quota, number of files and resource limits are sufficient in the new account. During migration, both the archive and the unzipped copy may consume temporary space. It may be insufficient to calculate vacancy based on current usage. If there are databases with the same name on the target, find out how the transfer will handle them.

Choose the migration method based on your access level

WHM Transfer Tool can be used to transfer accounts and configurations with the required server privileges. Do not assume that you can use all WHM tools with normal cPanel user access. Clarify which method is appropriate, such as provider transfer, account backup, or moving files and database separately. cPanel Transfer Tool documentation describes authority and scope.

Check that your own file transfer includes hidden files, application configurations, and uploaded content. Export and import the database separately, verify the target connection information. If you only copied public_html, other folders or mail data of the account will not be complete. Prepare the backup plan for the method used.

Schedule final sync for changed data

While the first copy is being prepared, a new order, comment or file may occur on the old site. Determine in advance how this data will be transferred to the new account. Having two servers accept independent records at the same time can make merging data difficult. Maintenance or write pause patterns appropriate to the application may be required.

In a store example, loading the test copy with the data received on Monday morning and changing the DNS in the evening may cause forgetting the orders in between. The last transfer time and the transactions occurring at that time should be included in the transfer note. Do not load the old database over the new data without reconciling the application data with the external payment records.

Test the new site without changing DNS

Examine how the actual domain name request is answered on the new server with a suitable test address or controlled hosts scheme. Direct IP address may not give the same result in terms of domain selection and HTTPS. Restrict access to the test copy; Prevent customer data from being exposed and unnecessary indexing of the test environment.

Next to the home page, open the internal page, image, download, session, form and critical operations of the application. Use the payment provider's appropriate test flow if necessary; Do not leave the test copy for actual collection. Also check email notifications to prevent test messages from going to real customers.

Control DNS, email and HTTPS relay separately

It may be sufficient to update the web records for the new IP; You don't have to change the nameserver in any case. If the nameserver is to be changed, prepare the entire existing DNS zone in the new location. Maintain MX and authentication records of external email, subdomains of individual applications. Nameserver and deployment guide details this step.

In addition to the A record, examine the AAAA target. Test that the new server's certificate covers the required names and that HTTP redirection and the preferred www/root address are working. For HTTPS authentication, you can refer to SSL guide. If mailboxes have been moved, verify new sending and receiving actions as well as historical content.

Close the old service once the results are verified

Keep track of access and error logs of the new server after the migration. There may be users reaching the old destination for a while due to DNS caches. Rather than immediately deleting the old environment, determine how to terminate traffic and data acceptance. This waiting period should be managed according to your application and migration pattern; No single exact time can be given for all projects.

When the URLs remain the same, don't add redirects to every page just because the hosting has changed. Google's URL immutable migration guide explains the steps to prepare the new environment, DNS migration, and monitor traffic on both sides. Also verify that test settings such as robots and noindex are not accidentally left in the live environment.

Transport acceptance list

  1. The file, database and required mail data have been verified.
  2. Version and application functions were tested in the new environment.
  3. Final data transfer and maintenance completed.
  4. DNS, IPv4/IPv6 and HTTPS targets are checked.
  5. Form, login and critical user operations are working.
  6. The return point and the closing condition of the old service are clear.

Consider web hosting coverage and current domain management together. Sharing the list of services to be moved, removing confidential information, from contact page will help clarify the scope.

Frequently asked questions

Is domain name transfer mandatory for hosting migration?

No. Hosting and domain registration are separate issues. You can change DNS accordingly while keeping your current registration account; Verify provider terms separately.

Does the migration tool copy all security settings?

Don't assume it carries all the settings. For example, the cPanel Transfer Tool documentation states that the account 2FA scheme must be re-established. Check access and authorizations at the end of the migration.

Is the migration considered successful if only the home page works?

No. Actual workflows such as login, forms, internal pages, file upload, and mail should be verified. Decide based on your application's acceptance list.

Resources