Migrating a WordPress Site to iWebVault

Moving a WordPress site between hosts sounds intimidating but follows a predictable pattern. With a clean process you can do it with zero visitor-visible downtime — the new site is fully set up and tested before any DNS change is made. This guide walks through both the plugin-based approach (easiest, works for most sites) and the manual approach (better for large or complex sites). We’ll also handle the most common gotcha: DNS propagation.

Before you start

• Have your new iWebVault hosting account active (cPanel access).
• Have access to your existing host (admin, FTP/SSH if available).
• Know where your domain DNS is managed (registrar control panel? Cloudflare? Another DNS host?).
• Have at least 2 hours of uninterrupted time. Larger sites: half day.
• Pick a low-traffic time. Even with zero-downtime approach, you want to be available to troubleshoot.

Option A: Plugin migration (recommended for most sites)

Several plugins handle the full migration with minimal manual steps:

• All-in-One WP Migration — popular, free for sites under 256 MB. Excellent for typical sites.
• Duplicator — free version handles most use cases; pro handles multisite, scheduled, large sites.
• UpdraftPlus — backup plugin that includes migration.
• WP Vivid — free, no size limits in core version.

For this guide we’ll use All-in-One WP Migration (most common). Process is similar with others.

Step 1: Export from old host

1. Old site admin → Plugins → Add New → install “All-in-One WP Migration”, activate.
2. All-in-One WP Migration → Export.
3. Export To: “File”.
4. Plugin generates a .wpress file containing your entire site (files + database).
5. Download the file to your computer.

For sites over 256 MB you’ll hit the free limit. Options: buy the pro extension, use a different plugin (WP Vivid has no limit), or do manual migration.

Step 2: Set up fresh WordPress on iWebVault

1. iWebVault cPanel → WordPress Manager (or WP Toolkit).
2. Install a fresh WordPress at your domain.
3. Or install at a temporary URL like yourdomain.com.iwebvault.com if your domain isn’t pointed here yet. WP install guide.

Step 3: Import on new host

1. Log in to the new WordPress on iWebVault.
2. Install All-in-One WP Migration plugin (same as on old host).
3. Import → Drag and drop your .wpress file.
4. Plugin overwrites the fresh install with your old site’s content.
5. Save permalinks twice (Settings → Permalinks → Save). Fixes URL rewriting.

Done. New site is a clone of the old one. Now verify everything works before pointing DNS.

Option B: Manual migration

For larger sites, or when plugin import fails:

Step 1: Export database from old host

• Old host cPanel → phpMyAdmin → select database → Export tab → Quick → Format SQL → Go.
• Saves .sql file to your computer.
• For databases over 100 MB, use SSH: mysqldump -u dbuser -p dbname > site.sql, then download via SFTP.

Step 2: Copy files from old host

• SFTP into old host → download public_html (or wherever WordPress is) to your computer.
• For large sites: SSH → compress: cd ~/public_html && tar -czf site.tar.gz . → download single archive.

Step 3: Upload files to iWebVault

• Upload everything to public_html on iWebVault.
• For tar.gz: upload archive, extract via cPanel File Manager (right-click → Extract).

Step 4: Create new database on iWebVault

1. cPanel → MySQL Databases.
2. Create database (note the name including the prefix, e.g. user_wpdb).
3. Create user, add user to database with all privileges.
4. Note credentials.

Step 5: Import database

• cPanel → phpMyAdmin → select the new empty database → Import tab → upload the .sql file → Go.
• For larger SQL files: SSH → mysql -u newuser -p newdb < site.sql.

Step 6: Update wp-config.php

Edit public_html/wp-config.php on iWebVault with the new database credentials:

define( 'DB_NAME',     'user_newwpdb' );
define( 'DB_USER',     'user_newwpuser' );
define( 'DB_PASSWORD', 'newpassword' );
define( 'DB_HOST',     'localhost' );

Step 7: Update siteurl and home if needed

If migrating to a different domain (e.g. staging.yoursite.com instead of yoursite.com), update URLs:

phpMyAdmin → your db → wp_options table → find siteurl and home rows → update both to new domain.

For deeper URL replacement (all post content references the old URL), use search-replace tool like WP-CLI:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables

Or the Better Search Replace plugin (UI alternative).

Testing before DNS cutover

Don’t change DNS yet. First verify the new site works.

Method 1: hosts file

Edit your computer’s hosts file to point your domain at iWebVault temporarily:

• Mac/Linux: /etc/hosts.
• Windows: C:WindowsSystem32driversetchosts.

Add a line:

YOUR_IWEBVAULT_IP    yourdomain.com www.yourdomain.com

Get IP from iWebVault cPanel → Server Information → “Shared IP Address” or your dedicated IP.

Now your browser hits the iWebVault site when you visit yourdomain.com — but only on your machine. Test thoroughly: home page, inner pages, admin login, contact form, checkout (if e-commerce), images, mail.

Remove the hosts file entry when done.

Method 2: Temporary URL

iWebVault provides a temporary URL for each cPanel account, like yourdomain.com.iwebvault.com (server-specific). Visit it to see your site without DNS changes.

Caveat: WordPress URLs in the database point to your real domain, so links may break in temporary-URL access. Use hosts-file method for full testing.

DNS cutover

Once you’ve verified the new site works:

Lower TTL beforehand

24-48 hours before the cutover, lower your DNS records’ TTL to 300 (5 minutes). This means changes propagate fast when you cut over.

(If you forget this step, no disaster — DNS still cuts over, just slower.)

Change nameservers OR A record

• If using iWebVault DNS: at your domain registrar, change nameservers to ns1.iwebvault.com and ns2.iwebvault.com.
• If using external DNS (Cloudflare, registrar’s DNS): in that DNS control panel, update A record to point at your iWebVault IP.

Propagation: typically 5-60 minutes globally with low TTL, up to 48 hours in rare cases.

Monitor during propagation

• Use dnschecker.org to see propagation status worldwide.
• Visitors hitting the old IP see the OLD site (still working).
• Visitors hitting the new IP see the NEW site.
• This is why both sites should remain functional during cutover — short-lived split brain.

Post-cutover cleanup

1. Verify HTTPS — AutoSSL should issue a cert within minutes of DNS propagating. Force HTTPS in .htaccess. .htaccess guide.
2. Test from multiple devices and networks.
3. Check that mail still works (test sending, test receiving). If MX records changed, mail routing changed too.
4. Wait 24-48 hours, verify everything still works.
5. Cancel old hosting (don’t do this immediately — keep it around as fallback for a few days).
6. Increase DNS TTL back to normal (3600 or higher).

Common migration issues

“Mixed content warnings on HTTPS.” Old URLs in content reference http:// instead of https://. Search-replace via Better Search Replace plugin.

“Permalinks return 404.” WordPress → Settings → Permalinks → Save (without changing). Regenerates .htaccess.

“Images broken.” File uploads didn’t transfer, or paths reference old domain. Check wp-content/uploads exists and contains files. Search-replace any hard-coded URLs.

“Site shows database error.” wp-config.php has wrong database credentials. Verify against actual DB name/user/password from cPanel MySQL Databases.

“All-in-One WP Migration import gets stuck at 100%.” Common bug. Disable maintenance mode manually (delete .maintenance file in WordPress root), refresh.

“Mail to my domain stopped working after DNS change.” If using iWebVault for mail, your MX records need to point here too. cPanel handles automatically if nameservers are iWebVault. If using external DNS, manually point MX records at mail.yourdomain.com (with A record pointing to iWebVault IP).

What’s next

• Performance tuning post-migration: LiteSpeed Cache setup.
• Configure SSL: AutoSSL guide.
• Set up email properly: Email setup.
• First backup on new host: JetBackup.

The plugin approach handles 90% of migrations smoothly. For larger or stranger sites, the manual approach gives full control. Either way, the principle is the same: build the new site to working state BEFORE touching DNS. With that discipline, migrations are routine — not the scary event they’re often made out to be.