DEV Community

Cover image for How to migrate WooCommerce without losing revenue
binadit
binadit

Posted on • Originally published at binadit.com

How to migrate WooCommerce without losing revenue

Zero-downtime WooCommerce migration: A practical approach

E-commerce downtime equals lost revenue, period. When you need to migrate WooCommerce to new infrastructure, every minute offline translates directly to missed sales and frustrated customers.

This guide demonstrates how to execute a seamless WooCommerce migration using DNS switching and database synchronization, ensuring your store operates continuously throughout the entire process.

What you need before starting

Ensure you have these prerequisites locked down:

  • Root access to both current and target servers
  • SSH connectivity to both environments
  • Current WooCommerce database credentials
  • DNS control (A record modification rights)
  • 24-48 hour migration timeline
  • Scheduled maintenance window for final cutover

This approach works best for active stores where downtime directly impacts revenue and you're moving to infrastructure with equivalent or better performance specs.

Phase 1: Target environment setup

Build your destination server with matching PHP and MySQL versions:

# System preparation
sudo apt update
sudo apt install nginx mysql-server php8.1-fpm php8.1-mysql php8.1-curl php8.1-gd php8.1-xml php8.1-zip

# Database creation
mysql -u root -p
CREATE DATABASE woocommerce_new;
GRANT ALL PRIVILEGES ON woocommerce_new.* TO 'woouser'@'localhost' IDENTIFIED BY 'secure_password';
FLUSH PRIVILEGES;
EXIT;
Enter fullscreen mode Exit fullscreen mode

Configure Nginx with identical server blocks:

server {
    listen 443 ssl http2;
    server_name yourstore.com;

    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/private-key.pem;

    root /var/www/woocommerce;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
Enter fullscreen mode Exit fullscreen mode

Phase 2: Initial data migration

Create your baseline database copy:

# Source server export
mysqldump -u username -p --single-transaction --routines --triggers woocommerce_db > woocommerce_backup.sql

# Transfer to target
scp woocommerce_backup.sql user@newserver:/tmp/

# Target server import
mysql -u woouser -p woocommerce_new < /tmp/woocommerce_backup.sql
Enter fullscreen mode Exit fullscreen mode

Update WordPress configuration:

// wp-config.php adjustments
define('DB_NAME', 'woocommerce_new');
define('DB_USER', 'woouser');
define('DB_PASSWORD', 'secure_password');
define('DB_HOST', 'localhost');
Enter fullscreen mode Exit fullscreen mode

Phase 3: Real-time synchronization

The critical component is keeping data synchronized. Create this sync script:

#!/bin/bash
# sync-woocommerce.sh

# Track last synchronization
LAST_SYNC=$(cat /var/log/woo-sync-timestamp 2>/dev/null || echo "1970-01-01 00:00:00")

# Extract recent changes only
mysqldump -u source_user -p'source_password' -h source_host \
  --where="post_modified >= '$LAST_SYNC'" \
  --single-transaction source_db wp_posts > /tmp/new_posts.sql

mysqldump -u source_user -p'source_password' -h source_host \
  --where="user_registered >= '$LAST_SYNC'" \
  --single-transaction source_db wp_users > /tmp/new_users.sql

# Apply changes to target
mysql -u woouser -p'secure_password' woocommerce_new < /tmp/new_posts.sql
mysql -u woouser -p'secure_password' woocommerce_new < /tmp/new_users.sql

# Update sync timestamp
date '+%Y-%m-%d %H:%M:%S' > /var/log/woo-sync-timestamp
Enter fullscreen mode Exit fullscreen mode

Schedule via cron for continuous synchronization:

*/5 * * * * /path/to/sync-woocommerce.sh >> /var/log/woo-sync.log 2>&1
Enter fullscreen mode Exit fullscreen mode

Phase 4: File synchronization

Keep uploads and assets current:

# Initial media transfer
rsync -avz --delete source_server:/var/www/woocommerce/wp-content/uploads/ /var/www/woocommerce/wp-content/uploads/

# Ongoing synchronization
*/10 * * * * rsync -avz --delete source_server:/var/www/woocommerce/wp-content/uploads/ /var/www/woocommerce/wp-content/uploads/
Enter fullscreen mode Exit fullscreen mode

Phase 5: Pre-cutover validation

Test functionality using staging domain or direct IP:

# API connectivity test
curl -X GET "https://staging.yourstore.com/wp-json/wc/v3/orders" \
  -u "consumer_key:consumer_secret" \
  -H "Content-Type: application/json"
Enter fullscreen mode Exit fullscreen mode

Verify these elements:

  • Page rendering
  • Product catalog
  • Cart functionality
  • Payment processing
  • Order completion

Phase 6: DNS switchover

Prepare by reducing TTL 24 hours before migration:

yourstore.com.    300    IN    A    old.server.ip.address
Enter fullscreen mode Exit fullscreen mode

During maintenance window:

# Halt synchronization
sudo systemctl stop cron

# Execute final sync
/path/to/sync-woocommerce.sh
rsync -avz --delete source_server:/var/www/woocommerce/wp-content/uploads/ /var/www/woocommerce/wp-content/uploads/

# Switch DNS
yourstore.com.    300    IN    A    new.server.ip.address
Enter fullscreen mode Exit fullscreen mode

Validation and monitoring

Confirm DNS propagation:

dig @8.8.8.8 yourstore.com
dig @1.1.1.1 yourstore.com
Enter fullscreen mode Exit fullscreen mode

Test application functionality:

# Response time check
curl -w "@curl-format.txt" -o /dev/null -s "https://yourstore.com/"

# Cart functionality
curl -X POST "https://yourstore.com/?wc-ajax=add_to_cart" -d "product_id=123"
Enter fullscreen mode Exit fullscreen mode

Monitor these metrics post-migration:

  • Page load performance
  • Order completion rates
  • Payment success rates
  • Server response times
  • Database performance

Common failure points

Watch out for these issues:

Session data loss: Customer carts may reset during DNS transition. Plan for this or implement session synchronization.

Payment webhooks: Update webhook URLs in Stripe, PayPal, etc. before DNS changes to prevent payment confirmation failures.

SSL certificate problems: Install and test certificates on the new server before switching DNS to avoid trust issues.

Connection exhaustion: Database sync scripts can overwhelm connections. Monitor usage and implement pooling if needed.

Wrapping up

This approach minimizes migration risk by maintaining parallel systems until the final switchover. The key is thorough testing and monitoring throughout the process.

Post-migration, focus on performance optimization, caching implementation, and comprehensive monitoring setup to ensure your new infrastructure delivers improved results.

Originally published on binadit.com

Top comments (0)