WordPress Site Migration and Cloning: Step-by-Step Tutorial

WordPress site migration means moving your website from one location to another—different domain, different server, different environment, or creating identical copies for testing. Every migration requires careful URL replacement throughout your database and files because WordPress stores URLs everywhere: database content, plugin settings, theme options, and hardcoded file paths.

Done correctly, migration is smooth—site works perfectly at new location with zero downtime and no broken features. Done incorrectly, migration results in white screens, broken images, non-functional plugins, lost customizations, and panicked troubleshooting at 2 AM.

This intermediate guide walks through complete migration process using find-replace tools, explains serialized data considerations (the most common migration pitfall), and covers common scenarios: domain changes, staging-to-production deployments, server moves, and site cloning for development. By the end, you’ll migrate confidently knowing exactly what changes, why it matters, and how to verify success

What You’ll Learn

Understanding WordPress site migration
Using find-replace for URL changes
Migrating between domains
Moving from staging to production
Cloning WordPress sites
Post-migration checklist
Troubleshooting migration issues

Migration Scenarios

When You Need to Migrate

Changing Domains: Rebranding requires new domain. Moving from startup-name.com to acquired-brand.com. Upgrading from .net to .com after finally acquiring desired domain. Correcting original poor domain choice.

Server Upgrades: Moving from shared hosting to VPS for better performance. Switching hosting providers for better support/features. Upgrading to managed WordPress hosting. Consolidating multiple sites onto single powerful server.

Development Workflow: Pushing completed staging site to production. Cloning production site to staging for safe testing. Creating development environment from production data. Provisioning testing environments for QA teams.

Business Acquisitions: Merging acquired company’s website into parent company domain. Consolidating multiple brands under umbrella domain. Migrating legacy sites to modern infrastructure.

Testing and QA: Creating exact production replicas for plugin testing. Testing major updates safely before applying to production. Allowing clients to review changes before going live.

Types of Migrations

Development to Staging: Move work-in-progress from local development (localhost, .test domain) to staging server (staging.domain.com) for team review and testing. Changes from http://localhost:8888/mysite to https://staging.example.com.

Staging to Production: Deploy tested, approved changes from staging environment to live production site. Changes from https://staging.example.com to https://example.com. Critical process requiring zero-downtime strategies for high-traffic sites.

Domain Changes: Rebrand from olddomain.com to newdomain.com while maintaining site functionality, SEO value, and preventing broken links. Requires 301 redirects and careful URL replacement throughout site.

Server Moves: Migrate from one hosting provider to another without changing domain. Same URL but different server infrastructure, requiring backup/restore process with database credential updates.

Creating Site Clones: Duplicate production site for development, staging, or testing purposes. Creates exact replica with different URL for safe experimentation without risking live site

Understanding Find and Replace

Why URL Replacement is Critical

WordPress stores absolute URLs (full URLs including domain) rather than relative paths. This means database and files contain thousands of references to your domain name.

Database Examples:

Post content: <img src="https://olddomain.com/wp-content/uploads/2024/photo.jpg">
Plugin settings: {"api_endpoint":"https://olddomain.com/api/webhook"}
Theme options: a:2:{s:4:"logo";s:45:"https://olddomain.com/uploads/logo.png";}

Without finding and replacing every instance of old URL with new URL, migrated site loads with broken images, dead links, incorrect API endpoints, and non-functional features.

Simple text find-replace (Ctrl+F in database) would break serialized data (more on this below), corrupt the database, and cause white screen of death. Proper find-replace tools understand WordPress data structures and handle replacements safely.

What Needs to be Replaced

Database Tables:

wp_options: Site URL, home URL, plugin settings, theme options
wp_posts: Post/page content with embedded media and links
wp_postmeta: Custom fields, page builder content, meta boxes
wp_comments: Comment content with embedded URLs
wp_usermeta: User profile URLs
Custom plugin tables: WooCommerce orders, form submissions, etc.

Specific Examples:

Every <img src="https://olddomain.com/..."> in post content
Gallery shortcodes with URLs: where IDs reference media with old URLs
Page builder data storing section background images with full URLs
WooCommerce product images and downloadable file URLs
Contact form redirect URLs after submission

File Paths (less common, but possible):

Hardcoded URLs in theme files (poor practice but exists)
JavaScript configuration with API endpoints
CSS files with background image URLs

Total URL references in typical WordPress site: 500-5,000 depending on content volume and plugin usage.

Serialized Data Considerations

Serialized data is PHP’s method of converting complex data structures (arrays, objects) into storable strings. WordPress uses serialization extensively for plugin settings, theme options, and widget data.

Example Serialized Data:

a:2:{s:4:"logo";s:45:"https://example.com/wp-content/uploads/logo.png";s:5:"color";s:7:"#FF0000";}

This represents:

array(
    'logo' => 'https://example.com/wp-content/uploads/logo.png',
    'color' => '#FF0000'
)

The Critical Detail: String lengths are embedded (s:45: means “string with 45 characters”). Changing example.com (11 chars) to newsite.com (11 chars) works fine—same length. But changing example.com (11 chars) to new.co (6 chars) breaks serialization because length indicator still says s:45: but actual string is now 40 characters.

Result of Broken Serialization: PHP can’t unserialize corrupted data, plugin settings vanish, theme options reset to defaults, widgets disappear, customizations are lost, site breaks with white screen or fatal errors.

Proper Find-Replace Solution: Tools like Backup Copilot Pro’s built-in find-replace, WP-CLI search-replace, or Interconnect IT’s Search Replace DB script understand serialized data, detect it automatically, update string lengths correctly during replacement, and preserve data integrity

Step-by-Step Migration Process

Phase 1: Preparation

Document Current Configuration: Record current site URL (include www vs non-www, http vs https), database name and credentials, hosting provider and plan, active plugins list, active theme name, and current WordPress version. This documentation helps troubleshooting and provides reference if rollback needed.

Choose New Location Details: Determine new domain/URL, provision new server if needed, set up database on new server, configure DNS (can point after migration test), and install SSL certificate for new domain.

Create Pre-Migration Backup: Full backup of current site using Backup Copilot Pro. This is your safety net—if migration fails catastrophically, restore this backup and you’re back to working state. Download backup locally, don’t rely solely on server storage.

Enable Maintenance Mode (optional but recommended): Display “Undergoing Maintenance” message to visitors during migration. Prevents customers from encountering half-migrated broken site. Most backup plugins include maintenance mode feature.

Phase 2: Creating Migration Backup

Create backup specifically for migration using Backup Copilot Pro:

Navigate to WordPress admin → Backup Copilot Pro → Backups
Click “Create New Backup”
Select “Full Backup” (database + files)
Enable “Prepare for Migration” option
Enter old URL (https://olddomain.com) and new URL (https://newdomain.com)
Click “Create Backup”

Plugin creates backup and automatically applies find-replace during backup creation, replacing all old URLs with new URLs in backup file itself. This means restored backup already contains corrected URLs—no separate find-replace step needed after restoration.

Alternatively (manual find-replace after restore): Create standard full backup without migration preparation, restore to new location, then run find-replace tool manually on restored site.

Phase 3: Using Find-Replace Feature

If you created standard backup without migration preparation, perform find-replace after restoring:

Using Backup Copilot Pro Find-Replace:

Navigate to Backup Copilot Pro → Tools → Find and Replace
Enter old URL: https://olddomain.com (use exact format including http/https, www/non-www)
Enter new URL: https://newdomain.com
Select “All Tables” or choose specific tables
Click “Dry Run” to preview changes without applying
Review dry run results—verify replacements look correct
Click “Run” to execute actual replacements
Tool handles serialized data automatically, updating string lengths

Important: Always use full URLs (including https://) not just domains. Searching for “olddomain.com” might miss occurrences with http:// or https:// prefix. Use complete URL for thorough replacement.

Phase 4: Restoring on New Location

Upload Backup to New Server: Download backup from cloud storage or server. Upload to new server using FTP, SFTP, or hosting file manager. Place in accessible directory.

Restore Backup Using Plugin:

Install fresh WordPress on new server (if not done already)
Install Backup Copilot Pro plugin on new WordPress installation
Navigate to Backup Copilot Pro → Restore
Click “Upload Backup” if backup not already in plugin’s backup list
Select uploaded backup
Click “Restore”
Plugin restores database and files
Wait for completion (progress bar shows status)

Update wp-config.php (if database credentials changed):

define('DB_NAME', 'new_database_name');
define('DB_USER', 'new_database_user');
define('DB_PASSWORD', 'new_database_password');
define('DB_HOST', 'localhost');  // or new host

Update wp-config.php to Force URLs (temporary safety measure):

define('WP_HOME','https://newdomain.com');
define('WP_SITEURL','https://newdomain.com');

This overrides database URL settings, ensuring site loads with correct URLs even if find-replace missed something.

Phase 5: Post-Migration Configuration

Regenerate Permalinks: Navigate to Settings → Permalinks, click “Save Changes” without changing anything. This regenerates .htaccess and permalink structure for new domain.

Clear All Caches: Clear WordPress object cache, clear page cache if using caching plugin, clear CDN cache if applicable, clear browser cache when testing.

Test Site Thoroughly: Visit homepage and several internal pages. Test contact forms submission. Verify e-commerce checkout (test mode). Check user login/registration. Confirm admin area accessible. Test mobile responsiveness.

Update DNS (if domain changed): Point new domain DNS to new server. Wait for propagation (24-48 hours typical, though often faster).

Set Up 301 Redirects (if domain changed): On old domain server, redirect all traffic to new domain to preserve SEO and prevent broken links for visitors using old bookmarks.

Common Migration Scenarios

Migrating to a New Domain

Challenge: Changing domain while maintaining SEO value, preventing broken links from external sites, preserving customer bookmarks.

Solution: Complete migration process above, set up permanent 301 redirects from old to new domain, notify Google via Search Console Change of Address tool, update social media profiles, contact major backlink sources requesting URL updates, submit new sitemap with new URLs.

Timeline: Allow 2-4 weeks for search engines to recognize change. Rankings may fluctuate temporarily but should stabilize with proper redirects.

Moving to a New Host

Challenge: Same domain but different server. No URL replacement needed but database credentials likely change.

Solution: Create full backup on old host. Provision new hosting account. Restore backup to new host. Update wp-config.php with new database credentials. Test thoroughly on new host before changing DNS. Update DNS to point domain to new server IP. Monitor DNS propagation.

Downtime: Can be zero if you test new host before DNS change and switch DNS during low-traffic hours.

Subdomain to Main Domain

Challenge: Moving from staging.example.com to example.com or shop.example.com to example.com/shop/.

Solution: Standard find-replace migration replacing subdomain URL with main domain URL. Extra consideration: if moving from subdomain to subdirectory (staging.example.com → example.com/staging/), file paths need updating in addition to URLs. Backup Copilot Pro handles this automatically when you specify old and new URLs.

HTTP to HTTPS Migration

Challenge: Switching from insecure HTTP to secure HTTPS. Mixed content warnings if any HTTP resources remain.

Solution: Install SSL certificate first. Run find-replace changing http://example.com to https://example.com. Update wp-config.php to force HTTPS. Check for hardcoded HTTP links in theme files. Use Really Simple SSL plugin to catch remaining mixed content. Redirect all HTTP traffic to HTTPS via .htaccess.

Critical: Complete migration in single operation. Don’t leave site partially HTTPS—browsers show scary security warnings.

Cloning for Testing/Development

Challenge: Creating exact replica without affecting production site.

Solution: Create full backup of production site. Restore to staging subdomain (staging.example.com) or local development environment (localhost:8888). Run find-replace updating production URL to staging URL. Add robots.txt blocking search engines (User-agent: * / Disallow: /). Disable email sending (prevent test site from sending customer notifications). Test freely without affecting production.

Synchronization: Periodically clone fresh production backup to staging to keep data current. Schedule weekly or monthly depending on content change rate.

Post-Migration Checklist

Verifying Site Functionality

✓ Homepage loads without errors ✓ Internal pages accessible ✓ Admin dashboard functional ✓ Plugins activated and working ✓ Theme displays correctly ✓ Widgets present in sidebars ✓ Menus rendering properly ✓ User roles and permissions intact

Testing URLs and Links

✓ Permalink structure working (test several post/page URLs) ✓ Internal links clicking through correctly ✓ Navigation menus functional ✓ Search functionality working ✓ Archive pages (categories, tags, date archives) accessible ✓ 404 page displays for non-existent URLs ✓ Old URLs redirect to new URLs (if domain changed)

Checking Media Files

✓ Images display in posts/pages ✓ Featured images visible ✓ Gallery shortcodes rendering ✓ Media library accessible and populated ✓ PDF downloads working ✓ Video embeds playing ✓ Audio files functional

SSL Certificate Configuration

✓ HTTPS loads without browser warnings ✓ Green padlock appears in browser ✓ No mixed content warnings (HTTP resources on HTTPS page) ✓ HTTP automatically redirects to HTTPS ✓ Certificate valid and not expired ✓ Certificate covers all necessary domains (www and non-www)

Updating DNS Settings

✓ A record points to correct server IP ✓ CNAME records updated if applicable ✓ MX records updated for email (if email hosted separately) ✓ DNS propagation complete (check from multiple locations using DNS checker tools) ✓ Old domain redirects properly (if domain changed) ✓ Subdomains functioning (staging., shop., etc.)

Troubleshooting Common Issues

Broken Images and Media

Cause: URLs in content still reference old domain. Find-replace missed some occurrences.

Solution: Run find-replace again with different variations (http vs https, www vs non-www). Check wp_posts and wp_postmeta tables specifically. Regenerate thumbnails using plugin. Verify uploads folder permissions (755 for directories, 644 for files).

Cause: Browser cookies tied to old domain. Session data references old URLs.

Solution: Clear browser cookies completely. Try incognito/private browsing mode. Clear server-side sessions (delete contents of wp-content/uploads/sessions/ if exists). Verify wp_options table has correct siteurl and home values.

Database Connection Errors

Cause: wp-config.php contains old database credentials or incorrect new credentials.

Solution: Edit wp-config.php via FTP. Verify DB_NAME, DB_USER, DB_PASSWORD, DB_HOST match new server’s database. Test database connection using database management tool (phpMyAdmin). Create new database user if credentials invalid.

Permalink Problems

Cause: .htaccess not regenerated for new domain. Permalink structure not saved.

Solution: Navigate to Settings → Permalinks and click “Save Changes”. Verify .htaccess exists and is writable. If on Nginx (not Apache), update nginx.conf with correct rewrite rules. Clear server-side caching that might serve old .htaccess

Relevant External Links

Call to Action

Make migrations effortless! Backup Copilot Pro includes built-in find-replace for URLs, validation before restore, and multisite support. Migrate with confidence!