A faster server does not guarantee a faster public site. The migration may change PHP version, cache behaviour, database configuration, DNS route, CDN origin and scheduled jobs. A warm homepage test immediately after cutover proves very little.
Compare equivalent conditions and verify business functions as well as speed.
Preserve a meaningful baseline
Before migration, test representative URLs from a logged-out cold session: homepage, service page, article, uncached search, form and WooCommerce flow where present.
Record:
- DNS and redirect chain;
- TTFB for cache hit and miss;
- LCP and layout stability;
- transferred bytes and request count;
- PHP/database time for dynamic routes;
- cache headers and CDN status.
Save versions, active PHP extensions and relevant hosting settings. Do not copy secrets into the report.
Test the new host before DNS cutover
Use the host’s preview method or an authorised local hosts-file entry so the real domain reaches the new server. SSL and CDN behaviour may differ before public DNS, so label those limitations.
Avoid temporary URL replacements inside the WordPress database if the final domain can be tested through host mapping. They can create mixed content and serialised-data problems.
Confirm robots and indexing controls remain appropriate for the private test environment.
Match cache conditions
Compare old hit with new hit and old miss with new miss. Warm each page deliberately, then record repeated requests. Test a purge and first regeneration too.
Inspect response headers to confirm which layer served the request. A host may advertise server cache that WooCommerce cookies bypass unexpectedly.
Do not cache cart, checkout or account to produce an impressive number.
Verify PHP, database and object cache
Check PHP version, handler, memory, workers and required extensions. Review logs for deprecations or fatal errors that visitors may not immediately trigger.
Compare database query time and connection latency on dynamic requests. Confirm table charset/collation and scheduled database maintenance.
If Redis or another persistent cache was migrated, verify isolation, authentication, hit behaviour and graceful failure. Flush only the new site’s cache through supported controls.
Test visitor geography and media
A new origin closer to the administrator may be farther from customers. Test from relevant regions and inspect whether the CDN is active, caching static files and fetching from the intended origin.
Verify images, WebP/AVIF variants, video range requests and cache-control headers. Missing server modules can cause the new host to serve full-size originals or incorrect content types.
Check upload processing and disk/inode headroom, not only download speed.
Run complete application journeys
Submit each form and verify delivery. Test login, password reset, search, multilingual pages and scheduled tasks.
For WooCommerce, use authorised sandbox payments and confirm cart persistence, taxes, shipping, stock, emails, webhooks and order status. Check cron and Action Scheduler queues after cutover.
Performance is not improved if an external callback still points to the old server.
Observe after DNS changes
Lower DNS TTL in advance only when change policy permits it. During propagation, monitor both old and new hosts; some visitors may reach either.
Keep the old environment intact and non-conflicting for an agreed rollback window. Prevent two sites from independently processing cron, subscriptions or incoming orders.
After propagation, test the public SSL chain, canonical redirects and cache again.
Make the hosting decision from evidence
Compare medians and slow samples under matched conditions. Note improvements and regressions by route. A homepage cache hit may improve while checkout worker queue worsens.
Request a post-migration assessment when results vary by region, cache headers are unclear or dynamic flows slow down. Share baseline and public timings; hosting access can follow after scope and rollback are agreed.