WordPress is the most common thing people migrate, and it’s one of the smoothest. Because a full cPanel migration preserves your database names, your wp-config.php keeps pointing at the right database after the move — no manual edits, no search-and-replace.
Why WordPress migrations usually ‘just work’
A WordPress site is two things: the files (themes, plugins, uploads, core) and the database (posts, settings, users). A full migration brings both across intact. Crucially, the database keeps its original name, and the migrated account is granted access to it — so the credentials in wp-config.php stay valid.
DB_NAME, DB_USER, or run a URL search-replace for a like-for-like migration. The site comes up as it was.Step by step
- Run a single-account migration with your old cPanel credentials
- Wait for it to show completed
- Preview the site on iWebVault before switching DNS
- Log into
/wp-adminon the migrated copy to confirm content and settings - Point your domain to iWebVault when satisfied
After DNS points here
Once your domain resolves to iWebVault, AutoSSL issues a fresh certificate so your site loads over HTTPS. If you’d hardcoded an old IP or absolute URLs anywhere unusual, check those, but standard installs need nothing.
Large WordPress sites
Big media libraries or large databases (e.g. WooCommerce stores) simply take a little longer to back up and transfer. The process waits for the full backup before restoring, so even large stores arrive intact.
The two halves of a WordPress site
Every WordPress site is files plus a database. The files are your themes, plugins, uploads, and WordPress core. The database holds your posts, pages, settings, users, and (for stores) orders and products. A full cPanel migration moves both halves together and intact, which is why WordPress sites come across so cleanly.
Why no search-replace is needed
Some WordPress migrations require a database search-and-replace to fix the site URL or database references. With a like-for-like cPanel migration, your domain and database names are unchanged, so there’s nothing to rewrite. The site that comes up on iWebVault is byte-for-byte the site you had.
Plugins and themes
All your plugins and themes come across exactly as installed, including their settings stored in the database. Premium plugins keep their license activations in most cases, though a few license systems tie to the domain or server — if a premium plugin asks you to reactivate after cutover, that’s the plugin’s licensing, not the migration.
Caching after cutover
Once you’ve switched DNS, clear your caching plugin’s cache and purge any CDN cache. WordPress caching plugins sometimes store absolute URLs or server paths; a cache clear ensures visitors get freshly generated pages from iWebVault. This is a 30-second step that prevents ‘why does it look odd’ confusion right after going live.
WooCommerce and large stores
Stores migrate the same way, just with more data — bigger media libraries and larger databases. The migration waits for the full backup before restoring, so even a large catalogue arrives complete. After cutover, do a test purchase to confirm payments and emails fire, since those touch external services.
A pre-flight check for WordPress
Before migrating a WordPress site, it’s worth noting a couple of things about your current setup so you can confirm them afterward: which PHP version your site runs on, and whether you use any caching or security plugin that stores server-specific settings. Neither blocks the migration, but knowing them means you can verify PHP compatibility and clear caches confidently once the site is on iWebVault.
Why the same-domain case is the easy case
The smoothest WordPress migration is a straight host move keeping the same domain. Because both the domain and the database names are unchanged, WordPress comes up identical to before — same URLs in the database, same database connection in wp-config, same everything. There’s genuinely nothing to reconfigure. The more involved case is only when you change domain at the same time, which requires a URL update and is a separate, guided process.
Post-cutover WordPress steps
- Confirm the site loads on iWebVault over HTTPS once AutoSSL issues
- Clear your caching plugin’s cache
- Purge any CDN cache so visitors get freshly served pages
- Re-save permalinks (Settings → Permalinks) to refresh rewrite rules
- Do a test action — submit a form or place a test order
Premium plugins and licensing
Your premium plugins and themes migrate with their settings intact. A small number of premium licenses are tied to a specific domain or server and may prompt you to reactivate after cutover. That’s the plugin’s own licensing system, not a migration issue — reactivating with your license key resolves it. The vast majority of plugins carry on without any prompt.
Large WordPress sites and stores
Big media libraries and WooCommerce databases simply take longer to back up and transfer; the migration waits for the full backup before restoring, so even large catalogues arrive complete. For an active store, take a brief maintenance window for the final run so no orders slip in between the backup and the cutover, then do a test purchase afterward to confirm payments and order emails fire correctly on iWebVault.
What’s next
- How Your Databases Are Preserved
- SSL/HTTPS After You Migrate
- What to Check After Your Migration Completes
Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.
Was this helpful?
Thanks for your feedback!