What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Create and verify a restorable copy before you move anything. A safe host change preserves the website’s files, database, email, DNS records, and configuration; restores the copy on the new server; tests the private copy; and changes DNS only after the new site works. The exact procedure depends on the platform. The workflow below is strongest for cPanel accounts and WordPress sites, while identifying the parts that must be confirmed with your new hosting provider.
What a complete website backup must contain
A website is rarely just the files visible in its public web directory. A database-driven site also stores posts, pages, customers, orders, settings, user accounts, and other content in a database. Themes, plugins, uploaded media, configuration files, scheduled tasks, email, and DNS may live in separate parts of the hosting account.
Before changing hosts, aim for two things: a copy you can retrieve without relying on the old server, and a destination that can actually restore that copy. A downloaded archive that cannot be extracted, imported, or restored is not a dependable rollback.
- Files: site code, themes, plugins, uploads, media, documents, and any files outside the main web directory that the application needs.
- Database: required for WordPress and most content-management systems, stores, forums, and custom applications.
- Configuration: connection settings, rewrite rules such as
.htaccess, environment values, redirects, scheduled jobs, and permissions. - Account services: email mailboxes, forwarding rules, autoresponders, and delivery settings.
- DNS and certificates: A, AAAA, CNAME, MX, TXT, CAA, and other custom records, plus the information needed to issue or install SSL certificates on the new host.
For WordPress, the Open Migration plugin documentation describes an archive containing the database and wp-content, including themes, plugins, uploads, and other content stored there. That archive does not include wp-config.php or WordPress core files, so it is not the same thing as a complete hosting-account archive.
#1 Best Overall
Choose the backup and transfer method
There are two practical approaches covered here. Select the one that matches your access, platform, and required services rather than assuming one method is universally safer.
| Approach | Best fit | What to verify | Important limitation |
|---|---|---|---|
| cPanel full-account backup or transfer | A cPanel account that includes multiple sites, mailboxes, databases, and account settings | Archive contents, remote destination, available disk space, restore responsibility, email and DNS handling, and whether root or WHM access exists | The cPanel user interface cannot automatically restore a full backup; WHM or the hosting provider may be required |
| WordPress migration plugin | A supported single WordPress installation where the destination can run WordPress and the plugin | PHP and extension requirements, archive contents, URL conversion, overwrite behavior, disk space, and rollback copies | The cited Open Migration listing refuses multisite networks and excludes WordPress core and wp-config.php |
Ask the new host, before you commit, whether it accepts your archive format, whether it can restore a full account, which database versions it supports, and how it handles mailboxes and DNS. If the provider offers a migration service, establish exactly what it transfers and what remains your responsibility.
Inventory the site before creating an archive
Make a written inventory while the old site is still accessible. It becomes a checklist for the destination and exposes dependencies that a file copy will not reveal.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Inventory item | Record | Why it matters during the move |
|---|---|---|
| Domains | Every primary domain, subdomain, parked domain, and domain used for administration | Each name may need its own DNS records, certificate, document root, or redirect |
| Application | CMS, version, active theme, plugins or extensions, custom code, and runtime requirements | The new server must support the same software or a tested upgrade path |
| Databases | Database names, users, engines, and which site uses each one | Files without the matching database produce an incomplete or broken site |
| Mailboxes, aliases, forwarders, autoresponders, catch-all behavior, and storage needs | Web content can be correct while mail still points to the old service | |
| DNS | A, AAAA, CNAME, MX, TXT, CAA, verification, and third-party service records | Migration services may not change DNS for you, and omitted custom records can disable services |
| Web behavior | Redirects, rewrite rules, scheduled jobs, cron tasks, integrations, payment callbacks, and API endpoints | These dependencies often fail even when the homepage loads |
| Security | Admin accounts, 2FA arrangements, SSH or FTP keys, firewall allowlists, and certificate renewal details | Account archives do not necessarily carry every security setting to the new server |
Save the inventory outside the hosting account. Record the current IP address, database connection details needed for restoration, and any provider-specific instructions in a secure location. Do not put passwords in an unencrypted public document.
Create a cPanel account backup
Use a full account archive when you need account-level coverage
In cPanel, open Backup or Backup Wizard and choose the full-backup option. A full archive is appropriate when the account contains several sites, databases, mail, and other services that should move together. The interface can save the archive in the account’s home directory or send it to a remote FTP or SCP destination.
Rank #2
- New
- Mint Condition
- Dispatch same day for order received before 12 noon
- Guaranteed packaging
- No quibbles returns
- Confirm that the account has enough free quota to create the archive. cPanel warns that a full backup can fail when the account is near its quota.
- Choose a destination. A remote FTP or SCP destination is useful because it places a copy away from the source server; a home-directory copy is still useful as a temporary staging file.
- Start the backup and wait for cPanel to report completion. Do not begin the DNS change merely because the job started.
- Locate the resulting archive and check that it has a plausible, non-zero size. Download it to a computer or copy it to independent storage.
- Confirm that the independent copy can be retrieved. If possible, inspect the archive contents or perform a test extraction without altering the live site.
Keep in mind that “full backup” describes the archive produced by cPanel; it does not guarantee that your new provider will restore it automatically. cPanel states that you cannot automatically restore a full backup file in the cPanel user interface. Automatic full-backup restoration is available in WHM or through the hosting provider, so obtain a written answer about who will perform the restore before canceling the old account.
Use partial backups when a full account transfer is not appropriate
Partial downloads can be useful when you are moving only one site or when the destination accepts separate files and database exports. Download the relevant home-directory files and export each required database, then preserve the email and DNS inventory separately. This approach requires more manual mapping: you must know which database belongs to which document root and recreate users, permissions, mailboxes, redirects, and scheduled tasks.
For an account-to-account cPanel transfer, a host with root access to both servers can use WHM’s Transfer Tool. If you do not have that access, ask the provider whether it will perform the transfer or restore the archive. cPanel also notes that 2FA configuration is not transferred by the account-archive workflow, so plan to enroll administrators again on the destination.
Export a WordPress site with a migration plugin
Check the plugin’s requirements and scope
The Open Migration listing specifies PHP 7.2 or newer, the PHP ZipArchive extension, and enough free disk space to build and upload the ZIP archive. Those are requirements for that plugin, not a general WordPress requirement. The listing says multisite networks are refused rather than migrated.
The documented archive includes the database and wp-content. It does not include wp-config.php or WordPress core files, so the destination must have a working WordPress installation and a configuration file before import. Confirm that your site is a supported single-site installation and that the destination meets the required PHP and extension conditions.
Export and import sequence
- On the old site, install and activate the migration plugin. Check available disk space before starting the export.
- Create the export archive and wait for it to finish. Download the ZIP to independent storage rather than leaving the only copy on the old host.
- Install WordPress on the new host with the required PHP version and database service, then install the same migration plugin.
- Upload the exported archive to the destination. Make a separate backup of the fresh destination before importing, because the import replaces destination content.
- Read the replacement warning and confirm only when you intend to overwrite the destination. The import is not an additive merge.
- Complete the import. The plugin documentation says to sign in using the source site’s user account after the replacement.
- Review the plugin’s URL and path conversion results. Save the WordPress Permalinks settings after import so rewrite rules are regenerated.
Do not run a domain-change action simply because the files have imported. Open Migration’s documented sequence is to test on the temporary address, point DNS to the new server, wait until the real domain loads there, and only then run its Change Domain action. Running that action too early can leave the site unreachable at both addresses.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Store and verify the backup independently
Keep at least one copy that does not depend on the old host. Download the cPanel archive or WordPress ZIP to your computer or another controlled storage location, and retain the source-host copy until the move is stable. For a high-value site, keep the old hosting service active while you verify the new site, mail, and DNS.
- Check that the file exists and has a plausible size for the site.
- Confirm that the download completes and can be retrieved from the independent location.
- Test extraction or import on the destination rather than assuming a completed upload is usable.
- Record the archive filename, creation date, and the site or account it belongs to.
- Protect archives because they may contain databases, private uploads, customer information, and configuration secrets.
A restore test is the strongest verification. If a full cPanel archive will be extracted on the destination, cPanel’s restore guidance says to leave at least twice the archive file’s size free for extraction. Check this space requirement before uploading a large archive; insufficient space can make an apparently valid backup unusable.
Prepare the new hosting account
Before importing anything, compare the destination with the inventory. Confirm storage, database availability, supported software versions, PHP extensions, file-upload limits, SSL support, cron access, and the provider’s restore procedure. Create the required domains and document roots, but do not point public DNS at them yet.
- Ensure the destination has enough free space for the archive and the extracted site. For a cPanel restore, allow at least twice the archive size for extraction.
- Create databases and database users when your chosen method requires manual setup, and grant the required permissions.
- Recreate email mailboxes and forwarding rules if they are not included in the transfer.
- Plan how certificates will be issued for the destination hostname and the real domain.
- Have the independent backup available before beginning an overwrite or account restore.
If the destination provider cannot restore a full cPanel archive, ask for its accepted format and a step-by-step import method. Do not interpret the existence of a download button as evidence that the provider can recover the account.
Rank #4
- Provides a Vital On-The-Road Reference for Drivers On CSA Issues
- Covers All Information Drivers Need to Operate Successfully Under CSA
- Provides Fingertip Access of the Seven Basics
- How to Prepare for Roadside Inspections
Test the copied site before changing DNS
cPanel recommends verifying each website after migration and before changing DNS records. Use a temporary URL supplied by the host or map the real domain to the destination IP on your own computer with a local hosts-file entry. A hosts-file test changes only your computer’s resolution, allowing you to inspect the new server while public visitors continue using the old one.
- Obtain the destination IP address or temporary hostname from the new host.
- Use the temporary URL, or add a local mapping for the domain to that destination IP on your test computer.
- Open the homepage and several deep links. Check both HTTP and HTTPS behavior, redirects, canonical URLs, and mixed-content warnings.
- Sign in and test administrator functions, user registration, password resets, search, forms, uploads, and any editorial workflow.
- For a store or subscription site, test the complete non-production checkout or other transaction workflow according to the application’s safe testing procedure.
- Check images, downloads, embedded media, APIs, webhooks, scheduled jobs, and third-party integrations.
- Inspect application and web-server error logs. Pay special attention to file permissions,
.htaccessrules, missing absolute links, database connection errors, and PHP extension failures. - Test representative email sending and receiving on the destination without changing production MX records prematurely.
- Remove the local hosts-file mapping after testing so your computer does not continue bypassing public DNS.
For WordPress, test the temporary address carefully. Verify that links, media URLs, login redirects, and the site URL behave as expected before the public domain is moved. Follow the plugin’s documented domain-change order rather than changing URLs manually in the database unless you have a recovery plan.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan DNS and email cutover
Review records before switching traffic
cPanel’s migration guidance says its migration service does not make DNS changes for the customer and advises inspecting custom DNS records after a transfer. Export or record every authoritative record at the current DNS provider, including records unrelated to the website. A missing TXT record can break email authentication or domain verification; a missing CAA record can affect certificate issuance; an omitted MX record can divert mail.
| Record type | Check before cutover |
|---|---|
| A and AAAA | Destination IPv4 and IPv6 addresses, where used |
| CNAME | Aliases for subdomains, verification names, and external services |
| MX | Mail provider and priority order |
| TXT | SPF, DKIM, DMARC, verification, and service-authorisation values |
| CAA | Certificate-authority restrictions that must remain valid |
| Other custom records | Any record used by an API, CDN, monitoring system, or SaaS integration |
Lower TTL deliberately, then restore it
cPanel’s current migration guidance recommends lowering DNS TTL to 300 seconds before migration and restoring the standard 3600 seconds afterward. These are cPanel recommendations, not a universal promise about propagation time or downtime. Apply the values at the authoritative DNS provider and follow that provider’s rules. Lowering TTL does not force every resolver to forget an earlier cached value immediately.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsSwitch only after private testing passes
- Confirm the destination site, database, certificates, redirects, forms, and key integrations have passed private testing.
- Confirm that mailboxes exist and that the intended MX, TXT, CAA, and custom records are ready.
- Change the website’s authoritative A, AAAA, or relevant CNAME records to the destination values.
- Monitor the domain from more than one network and check both the website and email. Some visitors may still reach the old server while DNS caches expire.
- Keep the old host available during verification. If editors can still publish or customers can still submit data there, coordinate a final content or database sync so changes are not split between servers.
- After the cutover is stable, restore the normal TTL of 3600 seconds if that matches your DNS provider’s standard practice.
Visitors may continue reaching the old server until their DNS cache updates. That is why the old account should remain available during the verification window and why new writes, orders, submissions, and mail need special coordination.
Best Value
- Used Book in Good Condition
Troubleshoot common migration failures
The full backup will not complete
Check account quota first; cPanel identifies near-quota accounts as a cause of full-backup failure. Remove only disposable temporary data, or use a remote destination and ask the provider about a server-side archive. If the account remains too large for the available quota, create verified partial backups for the required files and databases and obtain a provider-assisted transfer.
The provider cannot restore the archive
Do not delete the old account. Ask whether WHM access or provider assistance is available and whether the host has an account-transfer limit. If it accepts only partial imports, use the inventory to restore files, databases, email, DNS, permissions, redirects, and scheduled tasks separately.
The site shows a database or blank-page error
Check that the destination database exists, the imported data belongs to the correct site, the application’s connection settings point to the new database, and the destination PHP version and extensions meet the application’s requirements. Review server and application logs before changing production DNS again.
Recommended Free Tools
Permalinks or media return 404 errors
Verify that all required files were copied, rewrite rules such as .htaccess are present and permitted, and the web server points to the correct document root. In WordPress, save the Permalinks settings after import. Check for absolute URLs that still reference the old host and for case-sensitive filename differences.
Email stopped after the website moved
Compare the live MX, SPF, DKIM, DMARC, and other TXT records with the inventory. Recreate missing mailboxes and forwarding rules, and confirm whether mail is hosted by the old provider, the new provider, or a separate service. Website DNS and email DNS may be controlled by different systems, so changing one does not automatically update the other.
WordPress is inaccessible at both addresses
If the Open Migration workflow was used, check whether its Change Domain action was run before the real domain pointed to the new server. Its documentation warns that this order can make the site unreachable at both addresses. Restore the destination backup or obtain host-level access, then correct the domain sequence while retaining the original archive.
A practical cutover checklist
- Inventory domains, software, databases, email, DNS, certificates, redirects, jobs, permissions, and integrations.
- Create a cPanel full archive or a supported WordPress export.
- Download an independent copy and verify its existence, size, retrieval, and extraction or import path.
- Confirm who can restore the archive and reserve sufficient destination disk space.
- Prepare the new account, databases, mailboxes, certificates, and application prerequisites.
- Import the site and preserve a destination rollback copy before any overwrite.
- Test privately with a temporary URL or local hosts-file mapping.
- Check custom DNS records and email configuration.
- Lower TTL to 300 seconds only if appropriate for your DNS provider and migration plan.
- Change DNS after testing, monitor both hosts, and coordinate final writes while caches update.
- Keep the old host and independent backup until the website, mail, and DNS are stable.
- Restore TTL to 3600 seconds when the cutover is complete and that value suits your DNS provider.
How to decide whether you are ready
You are ready to switch traffic when you can answer “yes” to all of these questions: Can you retrieve the backup without the old host? Does the destination have a documented restore path? Does the private copy load the important pages and workflows? Are mailboxes and custom DNS records accounted for? Can you identify which server receives a new submission or order during propagation? Do you still have a rollback copy and access to the old account?
If any answer is “no,” postpone the DNS change and resolve that gap. A few extra preparation steps are less risky than discovering after propagation that the only copy lacked a database, an email record, or a configuration file.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
