Moving a WordPress website from one hosting environment to another can look deceptively simple.
Copy the files.
Export the database.
Import the database.
Update the domain.
Point DNS to the new server.
Done.
That approach may work for a small site with few dependencies.
A production WordPress website is rarely that simple.
A live site can depend on its hosting environment, PHP version, database configuration, caching layers, cron jobs, email delivery, DNS records, SSL certificates, third-party APIs, file permissions, scheduled tasks, background processes, and a long list of WordPress-specific settings.
A migration can therefore succeed technically while still failing operationally.
The files may be present, but forms may stop sending.
The database may import correctly, but serialized URLs may remain incorrect.
The website may load, but the CDN may still point to the old origin.
The homepage may work while checkout fails.
DNS may resolve correctly, while SSL has not been configured.
A site may appear healthy immediately after migration and fail hours later when a scheduled job runs.
This is why production WordPress migration should be treated as a controlled transition between two environments, not simply a file-transfer exercise.
The goal is not just to move the website.
The goal is to preserve its functionality, data, security, performance, integrations, and user experience while minimizing disruption.
What a WordPress Migration Actually Involves
At its simplest, a WordPress installation consists of two major components:
WordPress Website
|
+-------------------+
| |
v v
Files Database
| |
| |
wp-content MySQL/MariaDB
uploads
themes
plugins
core
configuration
But a production website usually has more dependencies:
WordPress Site
|
+----------------------+----------------------+
| | |
v v v
Files Database Configuration
| | |
v v v
Themes Content wp-config.php
Plugins Users Environment
Uploads Settings Secrets
Custom Code Metadata
|
+----------------------+
|
v
Infrastructure
|
+---------------------+---------------------+
| | |
v v v
PHP Web Server Cache
| | |
+---------------------+---------------------+
|
v
DNS
|
v
Users
And that still does not include every external dependency.
A production site may also depend on:
- CDN
- DNS provider
- Email provider
- Payment gateway
- Search service
- CRM
- Analytics
- Webhooks
- Object storage
- Monitoring
- Backup systems
- Security services
- Third-party APIs
A migration plan must therefore consider the whole application environment.
Why Production Migration Is Risky
The most dangerous assumption in a migration is:
"If the homepage loads, the migration worked."
The homepage is only one request.
A production WordPress site can have dozens of important user journeys.
For example:
- Visitor opens a page
- User submits a form
- Customer logs in
- Customer adds an item to cart
- Customer checks out
- Administrator publishes an article
- Editor uploads an image
- A scheduled task runs
- A webhook arrives
- An external API is called
- An email is sent
A migration can preserve one journey while breaking another.
This creates a more useful definition of migration success:
A migration is successful when the new environment reproduces the required functionality, data, integrations, security controls, and performance characteristics of the old environment with an acceptable level of disruption.
Start With Discovery, Not the Migration Tool
Before choosing a migration method, understand what is actually being migrated.
A useful discovery process should identify:
Application
- WordPress version
- Active theme
- Child theme
- Active plugins
- Must-use plugins
- Custom plugins
- Custom code
- WordPress configuration
- Multisite status
Infrastructure
- Hosting provider
- Web server
- PHP version
- Database engine and version
- PHP extensions
- Memory limits
- Object cache
- Page cache
- CDN
- SSL/TLS configuration
Domain and DNS
- Domain registrar
- DNS provider
- A records
- AAAA records
- CNAME records
- MX records
- TXT records
- SPF
- DKIM
- DMARC
Integrations
- Payment providers
- Email services
- CRM
- Analytics
- Search
- Authentication
- Webhooks
- External APIs
Operational Processes
- Backups
- Cron jobs
- Monitoring
- Deployment process
- Scheduled tasks
- Security scanning
- Log collection
This inventory becomes the migration baseline.
Build a Dependency Map
A simple inventory tells you what exists.
A dependency map tells you how those components interact.
For example:
Domain
|
v
DNS
|
v
CDN / Proxy
|
v
Web Server
|
v
PHP
|
v
WordPress Core
|
+----------------+----------------+
| | |
v v v
Theme Plugins Custom Code
| | |
+----------------+----------------+
|
+------------+------------+
| |
v v
Database External APIs
| |
v v
Object Cache Email / CRM
This matters because migration risk often comes from dependencies that are easy to forget.
A plugin might store data in the database.
A cron job might call an external API.
A payment plugin might depend on specific webhook URLs.
A CDN might cache content from the old origin.
An email service might authenticate against the old server's configuration.
The website is therefore more than its WordPress directory.
Define the Migration Scope
Not every migration is the same.
Common scenarios include:
- Shared hosting to managed WordPress hosting
- Shared hosting to VPS
- VPS to cloud infrastructure
- One managed WordPress host to another
- Development to production
- Staging to production
- Domain migration
- Server migration without a domain change
- Domain and hosting migration together
- HTTP to HTTPS migration
- Single-site to Multisite
- Multisite restructuring
- Infrastructure redesign
Each scenario changes the risk profile.
For example:
Server-only Migration
|
v
Domain remains unchanged
|
v
DNS changes may be minimal
Whereas:
Server + Domain Migration
|
+---- Hosting changes
|
+---- DNS changes
|
+---- URL changes
|
+---- SSL changes
|
+---- Email considerations
|
+---- SEO considerations
The second scenario requires much more planning.
Choose the Migration Strategy Before Touching Production
There is no universally best migration method.
The appropriate approach depends on:
- Site size
- Database size
- File volume
- Traffic
- Downtime tolerance
- Hosting access
- SSH availability
- Database access
- Deployment tooling
- Complexity
- Technical skill
- Business criticality
Common approaches include:
Full Backup and Restore
Create a complete backup and restore it on the new server.
This can be appropriate for smaller sites or controlled environments.
Migration Plugin
Use a WordPress migration tool to package and transfer the site.
This can simplify migrations but may introduce limitations for large sites or unusual hosting environments.
Manual File and Database Migration
Transfer the WordPress files and database separately.
This provides more control and visibility.
Staged or Incremental Migration
Build the destination environment first and synchronize changes before the final cutover.
This is more useful for larger or higher-traffic sites where downtime must be minimized.
The correct question is not:
"Which migration plugin should I use?"
It is:
"Which migration strategy gives this site the safest path from the current state to the target state?"
Design the Destination Environment First
Do not start moving production data before the destination environment is ready.
The target environment should be configured before cutover.
At minimum, verify:
- PHP version
- Database version
- Required PHP extensions
- Web server
- Document root
- File permissions
- SSL
- Storage
- Memory limits
- Upload limits
- Cron configuration
- Caching
- Object cache
- CDN
- Firewall/security controls
The target environment should be able to run the site before DNS points users toward it.
Conceptually:
Current Production
|
| Migration
v
Destination Environment
|
+---- PHP
+---- Database
+---- WordPress
+---- Plugins
+---- Theme
+---- Cache
+---- SSL
+---- Integrations
|
v
Validation
|
v
DNS Cutover
The destination should be tested before becoming production.
Match the Runtime Carefully
One of the most overlooked migration risks is the runtime environment.
The new server may use a different:
- PHP version
- Database version
- PHP extension set
- Web server
- Memory limit
- Execution time
- Upload configuration
A plugin that worked in the old environment may behave differently in the new one.
For example:
Old Environment
PHP 8.x
|
v
Plugin works
New Environment
PHP 8.y
|
v
Same Plugin
|
v
Compatibility Issue
The migration itself did not necessarily damage the plugin.
The environment changed.
This is why the destination should be validated against the application's actual requirements before cutover.
Pay Attention to PHP Extensions
WordPress and its plugins may rely on PHP extensions such as:
- cURL
- mbstring
- OpenSSL
- JSON
- XML
- ZIP
- GD
- Imagick
- MySQL extensions
A missing extension can create confusing failures.
The site may load while a specific feature fails.
For example:
WordPress loads
|
v
Image processing requested
|
v
Required PHP extension unavailable
|
v
Image operation fails
A migration checklist should therefore include the PHP extensions required by the actual application.
Database Migration Is More Than Export and Import
The WordPress database contains much more than published posts.
It may contain:
- Users
- User metadata
- Posts
- Pages
- Custom post types
- Comments
- Taxonomies
- Plugin settings
- Theme settings
- WooCommerce data
- Site options
- Scheduled task information
- Custom plugin tables
The database therefore represents a large portion of the site's state.
Before migration, determine:
- Database size
- Character set
- Collation
- Engine
- Table count
- Large tables
- Custom tables
- Autoloaded options
- Active database dependencies
Serialized Data Makes URL Changes More Complicated
WordPress and its plugins can store structured data in serialized formats.
A simple search-and-replace operation can therefore be dangerous if it does not correctly account for serialized values.
For example, changing:
https://old-example.com
to:
https://new-example.com
is not always as simple as replacing every occurrence in the database.
A migration involving a domain change should use a WordPress-aware method that correctly handles serialized data.
This is especially important for:
- Theme settings
- Page builders
- Plugin configuration
- Widget data
- Custom fields
A technically successful database import can still leave the application in an inconsistent state if URL replacement is handled incorrectly.
Do Not Forget the wp-config.php Environment
The WordPress configuration file can contain environment-specific values.
These may include:
- Database name
- Database username
- Database password
- Database host
- Authentication salts
- Table prefix
- Debug configuration
- Custom constants
- Cache settings
The destination environment may require different values.
A common migration mistake is copying the configuration blindly from the old server.
Instead:
Old Environment
|
v
Identify Environment-Specific Settings
|
v
Create Destination Configuration
|
v
Verify Secrets and Constants
|
v
Test Application
Secrets should also be handled carefully during the migration.
Move Files With Integrity in Mind
The WordPress filesystem includes more than the visible theme.
Important directories can include:
wordpress/
|
+-- wp-admin/
+-- wp-includes/
+-- wp-content/
| |
| +-- plugins/
| +-- themes/
| +-- uploads/
| +-- mu-plugins/
| +-- languages/
|
+-- wp-config.php
+-- .htaccess
+-- other configuration files
The wp-content directory deserves particular attention because it often contains the site's:
- Themes
- Plugins
- Uploads
- Custom code
- Generated assets
A migration must preserve the required filesystem contents and appropriate permissions.
Be Careful With File Permissions
Incorrect permissions can produce confusing problems after migration.
Examples include:
- Media uploads failing
- Plugin updates failing
- Cache files not being generated
- PHP unable to read files
- Web server unable to write required directories
A useful principle is:
Give processes the permissions they need, but avoid making the entire WordPress installation writable unnecessarily.
Permissions should be validated against the target hosting architecture rather than copied blindly from the old environment.
Backups Are a Safety Mechanism, Not a Checkbox
Before migration, create a known-good backup.
Ideally, preserve:
- Database backup
- WordPress files
- Uploads
- Configuration
- Relevant server configuration
- DNS information
- External integration settings
Most importantly, test the backup.
A backup that has never been restored is an assumption.
A migration plan should know:
Can we actually restore this site if the cutover fails?
Create a Rollback Plan Before Cutover
Rollback should not be invented after something goes wrong.
Define:
- What constitutes migration failure?
- Who decides to roll back?
- How will DNS be reverted?
- Is the old server still available?
- How long will it remain available?
- How will new data be handled?
- What happens to orders or form submissions created after cutover?
The last question is particularly important for dynamic sites.
For example:
Old Production
|
| Users continue interacting
v
Migration Begins
|
v
New Production
|
| New orders / forms / comments
v
Rollback Required
Those new transactions may not exist on the old server.
Rollback therefore becomes more complicated once users begin writing data to the new environment.
The Final Cutover Is a Synchronization Problem
For a static brochure site, the final migration may be relatively simple.
For a busy ecommerce site, it is fundamentally different.
Consider:
Old Site
|
| 10:00
|
+---- Customer places order
|
+---- User submits form
|
+---- Administrator publishes content
|
v
Migration Snapshot
If the database was copied before those transactions occurred, the destination does not contain them.
This creates a data consistency problem.
For dynamic websites, a safer strategy may involve:
- Short maintenance mode
- Temporary write restrictions
- Final database synchronization
- Incremental synchronization
- Application-level controls
- Carefully timed cutover
The correct method depends on the site's architecture and business requirements.
Reduce the Cutover Window
The goal is not necessarily zero downtime.
The goal is controlled and predictable downtime.
A well-planned cutover might look like:
Before Cutover
|
+---- Destination Ready
+---- SSL Ready
+---- DNS Prepared
+---- Backup Verified
+---- Testing Complete
|
v
Freeze / Maintenance
|
v
Final Synchronization
|
v
Update DNS / Routing
|
v
Verify Destination
|
v
Open Site
|
v
Monitor
Preparation determines how long the actual cutover takes.
DNS Is Part of the Migration
Changing the server is only half the problem.
Users still need to reach the new server.
DNS records may include:
- A
- AAAA
- CNAME
- MX
- TXT
- CAA
Changing the wrong record can affect unrelated services.
For example:
DNS
|
+---- Website
|
+---- Email
|
+---- Verification
|
+---- Security
|
+---- Other Services
A migration that changes all DNS records indiscriminately can accidentally break email or domain verification.
The migration plan should identify exactly which records need to change.
DNS TTL Should Be Considered in Advance
DNS changes are not necessarily visible everywhere immediately.
Caching behavior means some users may continue reaching the old destination for a period of time.
Reducing the relevant DNS TTL before migration can help make the eventual change more predictable.
But this needs to be planned before the cutover.
Changing TTL at the last minute does not retroactively control caches that have already stored the previous value.
SSL/TLS Must Be Ready Before Traffic Arrives
If the destination server does not have a valid certificate when traffic starts reaching it, users may encounter certificate warnings or connection failures.
Therefore:
Destination Server
|
v
SSL Certificate
|
v
HTTPS Validation
|
v
DNS Cutover
Do not make DNS point to an unprepared HTTPS environment.
Test:
- HTTPS
- Certificate validity
- Redirect behavior
- Mixed content
- HTTP-to-HTTPS redirects
- Canonical URLs
Domain Changes Require More Than DNS Changes
If the website is moving to a new server but keeping the same domain, the WordPress URL may not change.
If the domain itself changes, the scope is much larger.
You may need to update:
- WordPress Address
- Site Address
- Internal links
- Media URLs
- Canonicals
- Open Graph data
- Structured data
- XML sitemaps
- Redirects
- Email references
- Third-party integrations
- Webhooks
- Analytics
- Search Console configuration
A domain migration should therefore be treated separately from a server migration even when both happen at the same time.
SEO Is Part of Migration Risk
A technically successful migration can still damage organic search performance.
Potential problems include:
- Incorrect redirects
- Broken canonical URLs
- Noindex accidentally enabled
- Missing sitemap
- Incorrect robots.txt
- Broken internal links
- Changed URL structure
- Mixed content
- Inaccessible pages
- Temporary staging settings carried into production
Before migration, identify important URLs.
After migration, verify:
- Status codes
- Redirects
- Canonicals
- Robots directives
- XML sitemap
- Internal links
- Search engine accessibility
The goal is to preserve the site's existing search architecture wherever possible.
Never Let Staging Block Search Engines by Accident
A staging environment may intentionally use:
- Password protection
noindex- robots restrictions
- Temporary domains
Those controls are useful during development.
They become dangerous if accidentally carried into production.
Before launch, explicitly verify:
Staging Controls
|
+---- Password protection?
+---- noindex?
+---- robots restrictions?
+---- Temporary URLs?
|
v
Remove / Adjust for Production
|
v
Final Verification
Migration checklists should include this step.
Caching Can Make a Successful Migration Look Broken
Caching is one of the most common sources of confusing migration behavior.
A site may have:
- Browser cache
- WordPress page cache
- Server cache
- Object cache
- CDN cache
- Reverse proxy cache
After migration, different layers may contain different versions of the site.
For example:
User
|
v
Browser Cache
|
v
CDN
|
v
Reverse Proxy
|
v
Origin Server
|
v
WordPress
If the user sees stale content, the origin server may actually be working correctly.
A migration plan should therefore identify every cache layer and understand how it will behave during cutover.
Object Cache Can Be Especially Tricky
Persistent object caching may survive beyond individual requests.
Examples include Redis or Memcached-based setups.
If the destination environment uses a different cache configuration, stale or incompatible cached data can produce confusing behavior.
After migration, verify:
- Object cache configuration
- Cache connectivity
- Cache invalidation
- Persistent cache behavior
- Plugin compatibility
Do not assume that copying WordPress files and the database automatically reproduces the cache environment.
Cron Jobs Are Easy to Forget
WordPress relies on scheduled tasks for many operations.
Plugins may use scheduled events for:
- Sending emails
- Processing subscriptions
- Cleaning data
- Synchronizing APIs
- Generating reports
- Processing background jobs
- Publishing scheduled content
A migration can therefore appear successful and fail later.
For example:
Migration Complete
|
v
Website Works
|
v
Six Hours Later
|
v
Scheduled Job Runs
|
v
External API Request Fails
|
v
Business Process Breaks
This is why cron must be included in migration validation.
WP-Cron and System Cron Are Different Considerations
WordPress can trigger scheduled events through site traffic, while some environments use a server-level cron job to invoke WordPress's cron system.
The target environment should preserve the intended scheduling mechanism.
After migration, verify that important scheduled events are actually executing.
Do not stop testing when the homepage loads.
Email Delivery Is Another Hidden Dependency
A WordPress site may send:
- Password reset emails
- Form notifications
- Order emails
- Account emails
- Transactional messages
- Administrative notifications
Email delivery may depend on:
- SMTP
- External email providers
- DNS records
- API credentials
- Server configuration
A migration can therefore break email without affecting the website visually.
Test important email workflows after migration.
For production sites, this should be treated as a functional requirement, not an optional check.
Third-Party Integrations Need Explicit Testing
A plugin can be installed correctly and still fail because the destination environment changes the context in which it runs.
Examples include:
- Payment gateways
- CRM integrations
- Marketing automation
- Webhooks
- Search services
- Authentication providers
- Shipping APIs
- Analytics
For each integration, identify:
- What does it connect to?
- How is it authenticated?
- What URL does it call?
- What URL calls the WordPress site?
- Does it use IP allowlisting?
- Does it depend on DNS?
- Does it depend on SSL?
- Does it have test credentials?
- Does it require webhook updates?
This creates an integration migration checklist.
Payment Systems Deserve Extra Care
For ecommerce websites, payment processing is one of the highest-risk migration areas.
A migration can break:
- Checkout
- Payment callbacks
- Webhooks
- Order status updates
- Refund processing
- Subscription renewals
The most dangerous situation is one where the checkout page appears to work but the payment provider cannot communicate with the new server.
For example:
Customer
|
v
Checkout
|
v
Payment Provider
|
v
Webhook
|
v
WordPress
|
v
Order Status Updated
Every part of this chain should be tested.
Security Should Be Revalidated After Migration
Moving a site is also an opportunity to verify security assumptions.
Check:
- SSL/TLS
- File permissions
- Admin accounts
- Database credentials
- SSH access
- Firewall rules
- Security plugins
- PHP version
- Server software
- Debug settings
- Backup configuration
- Unused services
- Exposed files
- Authentication controls
A migration should not accidentally expose a development configuration in production.
For example, debug settings that were useful during staging should not automatically remain enabled on a public production environment.
Do Not Assume the Old Server Was Secure
Migration provides a useful opportunity to inspect the existing environment.
If the source site has a history of:
- Malware
- Suspicious files
- Unauthorized users
- Outdated plugins
- Weak credentials
- Unknown custom code
then blindly copying everything to the new server may reproduce the problem.
A migration should distinguish between:
"Move the site exactly as it is"
and:
"Move the required application while cleaning up known security and operational problems."
The appropriate approach depends on the migration scope and business requirements.
Performance Should Be Compared Before and After
A migration is not automatically an improvement just because the new server is more expensive or more powerful.
Compare meaningful metrics.
Before migration, establish a baseline for:
- Page response time
- TTFB
- Core Web Vitals
- PHP execution
- Database response
- Cache hit behavior
- Resource usage
- Error rates
After migration, compare the same metrics.
A useful model is:
Source Environment
|
v
Performance Baseline
|
v
Migration
|
v
Destination Environment
|
v
Performance Test
|
v
Compare
This helps distinguish migration problems from pre-existing performance problems.
Do Not Benchmark Only the Homepage
A homepage may be heavily cached and therefore hide infrastructure problems.
Test representative workloads such as:
- Homepage
- Content page
- Search
- Login
- Admin
- WooCommerce product
- Cart
- Checkout
- Form submission
- API request
For dynamic sites, uncached requests are particularly important.
Test the Database Under Realistic Workloads
The destination server may have a different database configuration.
Potential differences include:
- MySQL/MariaDB version
- Memory allocation
- Query cache behavior
- Storage performance
- Connection limits
- Character set
- Collation
A migration that works with a small test may behave differently under real traffic.
For important sites, database performance should therefore be considered as part of the overall application performance test.
Validate Media and Uploads
The media library is often one of the largest parts of a WordPress site.
Verify:
- Images load
- Original files exist
- Thumbnails exist
- WebP/AVIF variants work if used
- Uploads work
- New media can be uploaded
- File URLs are correct
For sites using external object storage or CDN-backed media, verify the integration separately.
Test WordPress Admin Functionality
Frontend testing is not enough.
Test critical administrative workflows:
- Login
- Logout
- Password reset
- Creating content
- Editing content
- Publishing
- Uploading media
- Updating menus
- Managing users
- Updating settings
- Running plugin-specific workflows
An enterprise WordPress site is also an internal application used by editors, marketers, administrators, and other teams.
Their workflows matter.
Test With Different User Roles
Permissions can behave differently after migration.
Test relevant roles such as:
- Administrator
- Editor
- Author
- Customer
- Subscriber
The exact roles depend on the application.
A migration should preserve:
- Users
- Roles
- Capabilities
- Authentication behavior
If a role loses a capability after migration, the website may technically be online while the organization cannot operate normally.
Build a Functional Test Matrix
Instead of testing randomly, define critical journeys.
| Area | Test | Expected Result |
|---|---|---|
| Frontend | Homepage | Loads successfully |
| Frontend | Content page | Correct content |
| Search | Site search | Results returned |
| Auth | Login | User authenticated |
| Content | Publish post | Post becomes public |
| Media | Upload image | File stored and displayed |
| Forms | Submit form | Submission delivered |
| Commerce | Add to cart | Cart updates |
| Commerce | Checkout | Payment completes |
| Password reset | Email delivered | |
| API | External integration | Request succeeds |
| Cron | Scheduled task | Task executes |
| SEO | Sitemap | Accessible |
| Security | HTTPS | Valid certificate |
The exact tests should be adapted to the site.
Monitor Immediately After Cutover
The migration is not finished when DNS changes.
The first period after cutover is when monitoring becomes especially important.
Watch:
- HTTP status codes
- PHP errors
- Server errors
- CPU
- Memory
- Database load
- Traffic
- Cache behavior
- API failures
- Form submissions
- Checkout
- Email delivery
- Scheduled tasks
A useful post-cutover flow is:
DNS Cutover
|
v
Traffic Reaches New Environment
|
v
Monitor Requests
|
+---- Errors?
|
+---- Performance degradation?
|
+---- Integration failures?
|
+---- User reports?
|
v
Stabilize
The objective is early detection.
Keep the Old Environment Available
Do not immediately destroy the old server after migration.
Keep it available long enough to:
- Compare behavior
- Recover missing data
- Investigate unexpected differences
- Roll back if necessary
The exact retention period depends on the site's risk profile.
For a critical ecommerce application, the old environment may need to remain available considerably longer than for a simple brochure site.
Be Careful With Rollback on Dynamic Websites
Rollback sounds simple:
"Point DNS back to the old server."
But imagine customers have placed orders on the new server.
If you immediately send traffic back to the old database, those orders may disappear from the application's perspective.
That means rollback planning must account for data divergence.
For example:
Old Database
|
| Migration
v
New Database
|
+---- Order A
+---- Order B
+---- Form Submission C
|
v
Rollback
|
v
Old Database
|
X
New transactions missing
This is why rollback for dynamic applications requires much more thought than simply reversing DNS.
A Safer Cutover Strategy for High-Traffic Sites
For high-value applications, consider a staged approach.
Source Production
|
v
Initial Migration
|
v
Destination Staging
|
v
Validation Tests
|
v
Final Data Sync
|
v
Cutover
|
v
Post-Cutover Tests
|
v
Monitoring
The more of the migration work completed before the final cutover, the less work needs to happen while users are waiting.
Zero Downtime Is an Architecture Goal
It is tempting to promise:
"There will be zero downtime."
But whether true zero downtime is practical depends on the architecture.
High-availability migrations may require:
- Replicated databases
- Load balancing
- Multiple application servers
- Shared or replicated storage
- Automated deployments
- Traffic switching
- Health checks
- Data synchronization
A simple WordPress site on shared hosting may not justify that complexity.
The appropriate goal is usually:
Minimize disruption while maintaining data integrity and a reliable rollback path.
Migration Complexity Should Match Business Requirements
Not every WordPress website needs enterprise migration infrastructure.
For a small informational website:
Backup
|
v
Restore
|
v
Test
|
v
DNS Change
|
v
Monitor
may be sufficient.
For a large ecommerce platform:
Discovery
|
v
Infrastructure Preparation
|
v
Initial Data Migration
|
v
Application Testing
|
v
Incremental Synchronization
|
v
Final Cutover
|
v
Monitoring
|
v
Rollback Readiness
The right architecture is the simplest one that satisfies the site's risk and availability requirements.
Common WordPress Migration Mistakes
Mistake 1: Starting Without an Inventory
If you do not know what the site depends on, you cannot reliably migrate it.
Mistake 2: Treating Files as the Entire Website
The database, DNS, integrations, cron jobs, cache, and environment configuration matter too.
Mistake 3: Testing Only the Homepage
A homepage can work while checkout, forms, APIs, or scheduled tasks are broken.
Mistake 4: Ignoring PHP Compatibility
Changing the runtime can expose plugin and theme compatibility problems.
Mistake 5: Changing DNS Too Early
The destination should be ready before production traffic is directed there.
Mistake 6: Forgetting Email
Website migration and email migration are not necessarily the same thing.
Mistake 7: Ignoring Caches
Users may see stale content even when the new server is working correctly.
Mistake 8: Forgetting Cron
Some failures appear hours after migration rather than immediately.
Mistake 9: Destroying the Old Server Too Soon
You lose an important fallback and comparison point.
Mistake 10: Assuming Rollback Is Just DNS
Dynamic data created after cutover complicates rollback.
Mistake 11: Copying Configuration Blindly
Environment-specific settings may not belong on the destination server.
Mistake 12: Treating Migration as a One-Time Event
The final step should be monitoring and stabilization, not simply "DNS updated."
A Practical Production Migration Checklist
Before Migration
- [ ] Document WordPress version
- [ ] Document PHP version
- [ ] Document database version
- [ ] Inventory themes
- [ ] Inventory plugins
- [ ] Identify custom code
- [ ] Identify must-use plugins
- [ ] Identify external integrations
- [ ] Document DNS records
- [ ] Document SSL configuration
- [ ] Document caching
- [ ] Document cron jobs
- [ ] Create a complete backup
- [ ] Verify the backup
- [ ] Prepare rollback plan
- [ ] Define critical user journeys
Destination Preparation
- [ ] Configure server
- [ ] Install compatible PHP version
- [ ] Install required PHP extensions
- [ ] Configure database
- [ ] Configure web server
- [ ] Configure storage
- [ ] Configure permissions
- [ ] Configure SSL
- [ ] Configure caching
- [ ] Configure object cache
- [ ] Configure cron
- [ ] Configure security controls
- [ ] Prepare DNS
- [ ] Prepare monitoring
Migration
- [ ] Transfer files
- [ ] Import database
- [ ] Configure wp-config.php
- [ ] Verify database connection
- [ ] Verify URLs
- [ ] Handle domain changes safely
- [ ] Verify uploads
- [ ] Verify plugins
- [ ] Verify theme
- [ ] Verify custom code
- [ ] Clear appropriate caches
Pre-Cutover Validation
- [ ] Homepage
- [ ] Important content pages
- [ ] Search
- [ ] Login
- [ ] Admin workflows
- [ ] Media uploads
- [ ] Forms
- [ ] APIs
- [ ] Ecommerce
- [ ] Payment processing
- [ ] Webhooks
- [ ] Cron
- [ ] SSL
- [ ] Redirects
- [ ] Sitemap
- [ ] Robots directives
Cutover
- [ ] Confirm destination readiness
- [ ] Confirm backup
- [ ] Apply final synchronization
- [ ] Enable maintenance/write controls if required
- [ ] Change DNS or traffic routing
- [ ] Verify DNS resolution
- [ ] Verify HTTPS
- [ ] Test critical journeys
- [ ] Monitor traffic and errors
After Cutover
- [ ] Monitor PHP errors
- [ ] Monitor server resources
- [ ] Monitor database
- [ ] Monitor integrations
- [ ] Monitor email
- [ ] Monitor forms
- [ ] Monitor checkout
- [ ] Monitor search visibility
- [ ] Verify cron
- [ ] Compare performance
- [ ] Keep rollback environment available
- [ ] Document the final environment
A Useful Way to Think About Migration Risk
Migration risk can be thought of across several dimensions:
Migration Risk
|
+------------------+------------------+
| | |
v v v
Data Risk Application Risk Infrastructure Risk
| | |
v v v
Database Plugins/Themes PHP/Server
Users Custom Code Cache/CDN
Orders Integrations DNS/SSL
|
+------------------+------------------+
|
v
Operational Risk
|
+--------+--------+
| | |
v v v
Email Cron Monitoring
A strong migration plan addresses all four.
Migration Is Also an Opportunity to Reduce Technical Debt
A migration creates a rare opportunity to inspect the production stack.
Before copying everything blindly, ask:
- Are all plugins still required?
- Are any plugins abandoned?
- Are there duplicate features?
- Are old themes still present?
- Is custom code documented?
- Are unused integrations still active?
- Is the PHP version supported?
- Are backups working?
- Is monitoring adequate?
But there is an important distinction:
Migration and application cleanup should not become one uncontrolled project.
Changing too much at the same time makes troubleshooting harder.
If possible, separate:
Migration
|
v
Stable Destination
|
v
Validation
|
v
Cleanup / Optimization
|
v
Further Improvements
This preserves the ability to identify which change caused a new problem.
Don't Upgrade Everything During the Migration
A common temptation is to combine migration with:
- WordPress upgrade
- PHP upgrade
- Plugin updates
- Theme redesign
- Database cleanup
- Performance optimization
- Security hardening
Some of these changes may be necessary.
But doing all of them simultaneously increases the number of variables.
If the migrated site breaks, it becomes difficult to determine whether the cause was:
- Migration
- PHP
- WordPress
- Plugin update
- Theme change
- Database change
- Configuration
A safer principle is:
Change only what the migration requires, unless there is a clear reason to address another issue during the same change window.
A Migration Is a Change-Management Exercise
The technical work is only part of production migration.
A business also needs to know:
- When the migration will happen
- Whether downtime is expected
- What users may experience
- Who is responsible for each step
- Who approves the cutover
- Who monitors the site
- What happens if something goes wrong
- When the migration is considered complete
This is especially important for organizations where WordPress is operated by multiple teams.
A migration plan should therefore have clear ownership.
For example:
| Area | Responsibility |
|---|---|
| WordPress application | WordPress/development team |
| Infrastructure | Hosting/devops team |
| DNS | Domain/infrastructure owner |
| Content | Editorial team |
| SEO | Marketing/SEO team |
| Payments | Ecommerce owner |
| Communications | Business/project owner |
| Monitoring | Technical team |
The exact roles vary by organization, but ownership should be explicit.
The Migration Runbook
For important sites, the migration should be documented as a runbook rather than a collection of informal instructions.
A runbook can contain:
- Preconditions
- Contacts
- Current environment
- Destination environment
- Backup procedure
- Migration procedure
- Validation tests
- DNS procedure
- Rollback procedure
- Monitoring plan
- Post-migration tasks
The value of a runbook is not just during the migration.
It becomes operational documentation for the website.
The Most Important Principle: Validate the User Journey
Infrastructure metrics matter.
Server health matters.
Database health matters.
But the ultimate test is whether users can still accomplish what they came to do.
For a publishing site:
Editor
|
v
Login
|
v
Create Content
|
v
Upload Media
|
v
Publish
|
v
Reader Sees Content
For an ecommerce site:
Visitor
|
v
Product
|
v
Cart
|
v
Checkout
|
v
Payment
|
v
Order Confirmation
For a lead-generation site:
Visitor
|
v
Landing Page
|
v
Form
|
v
Submission
|
v
CRM
|
v
Sales Team
These journeys define whether the migration actually succeeded.
Final Thoughts
A WordPress migration is not successful because the files were copied correctly.
It is successful when the destination environment behaves as a reliable replacement for the source environment.
That means preserving more than WordPress itself.
You need to account for:
- Files
- Database
- Configuration
- PHP
- Server infrastructure
- Themes
- Plugins
- Custom code
- DNS
- SSL
- Caching
- Cron
- External APIs
- Webhooks
- Security
- Performance
- SEO
- User roles
- Business workflows
The safest migrations begin with discovery, build the destination before cutover, establish a verified backup, test critical workflows, plan for data consistency, and maintain a realistic rollback strategy.
Most importantly, migration should be approached as a controlled change to a production system.
The question is not:
"How do I move this WordPress website?"
The better question is:
"How do I move this production WordPress application while preserving its data, functionality, integrations, performance, security, and user experience?"
Once the problem is framed that way, migration stops being a file-transfer task and becomes what it really is: a carefully managed transition between two production environments.
Top comments (0)