How to Test a Migration Before Going Live

How to Test a Migration Before Going Live

Thorough testing before going live is what separates a smooth migration from a disaster. Catching issues in a staging environment is far less costly than discovering them after DNS has been updated and real users are affected. This guide covers a comprehensive testing strategy for migrations to your new Breeze instance.

Setting Up a Test Environment

The key principle is to replicate production as closely as possible without affecting the live site. There are several ways to accomplish this:

Using /etc/hosts for Local Testing

The simplest approach is editing your local machine's hosts file to point your domain to the new Breeze IP. This lets you browse the site on the new server without changing DNS for anyone else:

# On your local machine (Linux/Mac)
sudo nano /etc/hosts
# Add this line:
203.0.113.50  example.com www.example.com

Now when you visit https://example.com in your browser, you are hitting the new Breeze. Remove the hosts entry when done testing.

Using a Temporary Subdomain

Create a temporary subdomain like staging.example.com pointing to the new Breeze. Configure the web server to respond to this hostname. This allows multiple team members to test without modifying their hosts files:

server {
    listen 80;
    server_name staging.example.com example.com;
    root /var/www/mysite;
}

Functional Testing Checklist

Work through these tests systematically, checking each one off as you verify it:

Website and Application

• Homepage loads correctly with all images, styles, and scripts
• All internal pages and routes work without 404 errors
• Contact forms and other input forms submit successfully
• User registration and login work correctly
• Password reset emails are sent and received
• File uploads process and display correctly
• Search functionality returns expected results
• HTTPS works with a valid certificate (no browser warnings)

Database

• Row counts match between source and destination for critical tables
• Queries return expected data for known test records
• Write operations (inserts, updates, deletes) work correctly
• Stored procedures and views function as expected
• Database backups can be created and restored

Email

• Outgoing emails are delivered (check spam folders)
• Email headers contain correct SPF, DKIM, and DMARC alignment
• Reply-to addresses are correct
• Transactional emails (password reset, order confirmation) send properly

Performance Testing

Compare performance between the old and new servers to ensure the migration does not introduce regressions:

# Quick response time test
curl -o /dev/null -s -w "Total time: %{time_total}s\n" https://example.com

# Load testing with Apache Bench
ab -n 1000 -c 50 https://example.com/

# Check PHP execution time
time curl -s https://example.com/api/health

If performance is significantly worse on the new Breeze, investigate PHP opcache settings, database query performance, and web server configuration before going live.

Security Testing

• Verify firewall rules are correctly configured with sudo ufw status
• Check that SSH access is restricted to key authentication
• Test that directory listing is disabled in the web server
• Verify that sensitive files (.env, .git, backups) are not publicly accessible
• Run an SSL test to check for weak cipher suites or protocol issues

Monitoring and Logging

Before going live, ensure monitoring is set up on the new Breeze:

# Check that log files are being written
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
tail -f /var/log/php8.2-fpm.log

Set up uptime monitoring and alerting for the new Breeze IP so you are notified immediately if any issues arise after going live.

Go/No-Go Decision

Create a simple checklist to make the final decision:

• All functional tests pass
• Performance is equal to or better than the current server
• Security checks pass
• Monitoring and alerts are configured
• The rollback plan is documented and tested
• The team has been notified of the migration timeline

If any critical test fails, postpone the migration, fix the issue, and retest. It is always better to delay a migration than to go live with known problems. Once all checks pass, proceed with the DNS cutover confidently knowing your Breeze is ready for production traffic.