Moving Your WordPress Site Between Two Different Hosting Control Panels: A Safe Path for Every Access Level
This guide is for you if you are moving a WordPress site from one hosting company to another and the two hosts use different control panels—cPanel to Plesk, a custom dashboard to a file-manager-only host, or any other mismatch. It is NOT for you if your managed WordPress host handles the entire migration for you; simpler guides exist for identical-panel moves within the same host architecture; and it is NOT for you if you need zero-downtime enterprise migrations with load balancers, which require infrastructure-level orchestration this article does not cover.
The moment you realize your old host’s control panel looks nothing like your new host’s interface is the moment most site owners freeze. The buttons are in different places, the database tool has a different name, and the backup file your old host generated may not restore cleanly on the new one. This article walks you through the WPHall Recovery Ladder—a decision framework that matches your actual access level to the safest path forward, so you do not trade a working site for a broken one.
L1: One-Click Self-Rescue Before You Touch Anything
Before you export a single file or change DNS, check whether either host gives you a rescue path you have not used yet.
If your current host offers automated backups in its dashboard, create a fresh restore point now. If your new host offers a staging environment or a one-click WordPress installer with migration assistant, note that path but do not activate it yet—staging restores work best when you have clean data to feed them.
Do NOT assume a full cPanel backup will restore cleanly on a non-cPanel host. The official cPanel documentation notes that full account backups can only be restored using WHM, which requires server-level access your new host almost certainly will not grant you. A full backup is useful as an emergency archive, but it is not your migration vehicle.
If your old host is already suspended or canceled, skip directly to the “Old Host Already Gone” branch below. Your L1 self-rescue window has closed, and your options narrow significantly.
L2: Branch Diagnosis—Three Questions That Split Your Path
Every migration fails for the same preventable reason: someone performs steps out of order for their situation. Answer these three questions before touching files or databases.
Question 1: What access does your old host still give you?
| Access level you have | What this means for your path |
|---|---|
| Full cPanel-style access (file manager, phpMyAdmin, backup wizard) | You can export everything yourself; this is the most flexible position |
| File manager and database tool, but no backup wizard | You will manually compress files and export SQL; still workable |
| Locked dashboard-only (managed host with no direct file access) | You must rely on host-provided export tools or WordPress-native exports |
Question 2: What kind of site are you moving?
A simple blog with posts and pages moves differently than a WooCommerce store with customer accounts and order history, which moves differently still from a multisite network. The WordPress developer documentation states that native export tools generate an XML file containing posts, pages, comments, custom fields, taxonomies, and users—but this XML export does not capture plugin settings, theme customizations, or WooCommerce product metadata. If you are evaluating whether your current page builder will complicate this move, see our companion coverage on how major builders handle template portability.
Question 3: Have you already changed DNS or canceled the old account?
If DNS already points to the new host but the site is incomplete, visitors see broken pages. If the old account is canceled, your database may be gone entirely. Be honest about where you are in this sequence; the recovery path changes based on your answer.
The Three Main Branches
Branch A: Full cPanel-Style Access on Old Host, New Host Has Standard Tools
This is the most documented path, which means it is also the one where people skip steps and corrupt their databases.
First, check your WordPress version from the dashboard—navigate to Dashboard → Updates to confirm your current version, as the interface patterns for plugin and theme management have shifted across recent releases. Check your dashboard for your current version; the steps below still apply but button labels may vary.
Back up first. Before any irreversible change, create a backup through your old host’s control panel. The cPanel Backup Wizard interface allows you to back up all or part of your website; use it to generate a partial backup of your home directory and databases separately, since you will need granular files, not a monolithic archive.
Do NOT begin the database export if your old host account is already suspended—the partial file will be useless and you will waste recovery time on corrupted SQL.
Export your database through phpMyAdmin using the “Quick” export method for standard WordPress installs, or “Custom” if your host has added non-standard prefixes. Download your WordPress files via the file manager or FTP, ensuring you capture wp-config.php, the wp-content directory, and any hidden files like .htaccess.
On the new host, create a fresh database and user, noting the credentials. Upload your files, import your SQL, then edit wp-config.php with the new database details. Run through the WordPress developer documentation’s standard import path at Administration → Tools → Import → WordPress only if you are supplementing a partial migration with content re-import.
Branch B: Locked Dashboard-Only on Old Host
Some managed WordPress hosts do not expose phpMyAdmin or file managers. Here your path narrows to what the host exposes.
Use Tools → Export in your WordPress dashboard to generate the XML content file the WordPress developer documentation describes. This captures posts, pages, comments, and users, but explicitly does not capture theme settings, plugin configurations, or custom CSS. If you are running WooCommerce, the official WooCommerce documentation notes that product data is stored in your WordPress database, but the native XML export will not capture it cleanly—you will need a WooCommerce-specific product export or a migration plugin that the host supports.
For your theme and plugin settings, screenshot every settings panel. There is no shame in this; it is faster than rebuilding from memory when you discover your custom color palette disappeared.
If your new host offers a WordPress import tool that accepts the native XML format, use Administration → Tools → Import → WordPress at the new site. Otherwise, you are effectively doing a content-only migration and will rebuild the site’s appearance manually.
Do NOT cancel your old hosting account until you have visually verified every page on the new site. The XML export gives you content, not a clone.
Branch C: Old Host Already Gone or Suspended
This is the panic branch, and the emotional scaffolding here matters. If you are staring at a database connection error because your old host disappeared, breathe. The Recovery Ladder still applies, but your L1 self-rescue is gone.
If you have any local backup—an export you emailed yourself, a backup plugin’s cloud storage, anything—start there. If you have nothing, check whether your domain registrar has any DNS history that might point to cached versions, or whether the Wayback Machine has snapshots of your public pages. These are desperation measures, not migration strategies, but they may recover content you thought lost.
If you have no backup and the old host is truly gone, you are not migrating anymore; you are rebuilding. This is your L4 stop line: when to hire a professional. A developer with forensic database experience may extract fragments from browser caches or CDN edge storage, but this is outside DIY scope.
WooCommerce and Multisite: The Complexity Multipliers
If your site is a WooCommerce store, the official WooCommerce documentation emphasizes that product data storage gives you full ownership and control—but that control comes with responsibility for data integrity. Customer passwords are stored hashed; if you use a migration plugin, set “Retain user passwords” to “Yes” so the hashed values transfer without forcing password resets.
For multisite networks, the WordPress developer documentation’s Advanced Administration Handbook covers migrating multiple WordPress installs into a multisite install. This requires editing wp-config.php twice and configuring subdomain structure. Do NOT attempt multisite migration if you have never edited wp-config.php before; this is an explicit L4 stop line. Hire a professional. The network architecture means a failed migration breaks every site in the network simultaneously, not just one.
The DNS Cutover: Timing That Protects Your Visitors
The most dangerous irreversible change in any migration is the DNS cutover. Once you point your domain to the new host, propagation begins, and rolling back requires re-pointing DNS and waiting again.
Back up first. Before changing nameservers or A records, note your current TTL (time-to-live) values. Lower them in advance if your host allows, so future changes propagate faster.
Do NOT change DNS until you have verified the new site works on its temporary URL or via hosts file modification. Most hosting panels provide a preview URL or allow local hosts-file testing. Use it. The panic of a site showing a database connection error mid-move is real and common; preventing it is better than recovering from it.
If you must cut DNS before full verification, do so at a low-traffic time and have your old host’s files ready for instant reversion. The Recovery Ladder L2 branch asks: did you already change DNS? If yes, your rollback path is DNS reversion, not file restoration.
Plugin-Specific Considerations: Elementor and Template Kits
If your site uses Elementor, the Elementor developer documentation establishes that template kits bundle templates, pages, popups, and site settings for export and import. Elementor’s Import/Export tool primarily supports transferring default Elementor features and settings; third-party plugins included in a kit may cause import or export issues.
If you are choosing whether to rebuild on a new theme during the move rather than migrate your existing setup, see our theme reviews for clean-start rebuilds. Sometimes a migration is the wrong moment to preserve legacy design debt.
Check your installed Elementor version before relying on kit export; the interface for kit selection has evolved across recent releases. Check your dashboard for your current version; if your version predates the current kit system, you may need to export individual templates manually.
Check Elementor’s current pricing
L3: Controlled Operation Checklist
Before any irreversible change, verify:
- Backup exists and is downloadable, not just “created” in a panel you cannot access later
- Database export is complete (check file size against your hosting panel’s reported database size)
- wp-config.php on new host uses new credentials, not old ones that will fail silently
- Permalink structure is re-saved after migration (Dashboard → Settings → Permalinks → Save Changes) to regenerate rewrite rules
Do NOT delete files from the old host until DNS has fully propagated and you have received no error reports for a reasonable period. The temptation to clean up early has destroyed many recoverable situations.
L4: Stop Line—When to Hire a Professional
Stop and hire a professional if any of the following apply:
- You are moving a multisite network and have never edited wp-config.php or configured subdomain mapping
- Your site runs a custom application stack (Bedrock, Trellis, Dockerized WordPress, or non-standard directory structure)
- Both hosts lack standard export tools and you have no command-line access to either
- The old host is gone and you have no backup, requiring data forensics
- Your WooCommerce store has more than a few dozen products and you cannot afford order history loss
The WPHall Recovery Ladder exists to keep you safe, not to push you past your competence boundary. A failed DIY migration that corrupts a live store costs more than professional help would have.
What You Trade Away with Cheaper Paths
Every shortcut in migration has a cost. Native WordPress XML export is free and reliable for content, but you trade away theme customizations, plugin settings, and WooCommerce metadata. cPanel full backups are comprehensive, but as the official documentation notes, they restore only through WHM—useless for cross-panel moves. Staging environments on managed hosts simplify the process, but you trade away granular control and may discover too late that the staging clone missed your custom uploads directory.
Choose your trade-offs consciously. The cheapest path is not the cheapest if it costs you days of rebuilding what a proper export would have preserved.
Final Verification Sequence
After migration, before declaring success:
- Log in to wp-admin on the new host and confirm your user account works
- Check that posts, pages, and media library items are present and viewable
- For WooCommerce: verify a test product displays correctly and checkout loads without error
- Submit a test contact form if your site uses one
- Check that scheduled posts and automatic updates are enabled
If any step fails, return to your backup and trace which export or import step truncated the data. Do not patch forward on a broken migration; the fractures will deepen.
Moving between hosting control panels is not a single path but a decision tree. The WPHall Recovery Ladder keeps you oriented: L1 rescue what you can automatically, L2 diagnose your actual situation honestly, L3 execute with backups before every irreversible step, and L4 know when the risk exceeds the reward. Your site survives the move not because you followed one universal checklist, but because you matched your access level, site type, and timing to the branch that fits.
Check WP Engine’s current hosting plans
Check SiteGround’s current hosting plans
This post contains affiliate links. If you purchase through our links, we may earn a small commission at no extra cost to you.
