Systematically narrowing down error patterns after server migration

How do you systematically isolate technical errors after a server migration?

The investigation begins with a reproducible query via the old and new endpoints, ideally without any additional variables. Status, headers, content, time values, and logs indicate whether the difference originates in DNS, network, web server, runtime, application, or cache.

Control case: "Mixed DNS operation"

After switching, pages usually load correctly, but forms fail sporadically. Identical requests to both endpoints show no PHP difference, but the new server is only allowed to access the external mail service via a restricted address; the cause is therefore clearly in the network share.

Layer-based finding

1. Save the error with time, client, host, and path, and compare the old and new target addresses with an identical request.

2. Check DNS, certificate, network time, status, headers, response content, runtime, and logs layer by layer instead of simultaneously.

3. Correct the confirmed difference in isolation and rerun the acceptance matrix, including background jobs and integrations.

Known initial state

Comparable request

• Comparable request Host, path, method, header, and application version are the same; only the resolved endpoint differentiates the test.

• Layer-based finding Measurement or log entry traceably assigns the error to a specific level from DNS to application.

• Known initial state – Important responses, redirects, headers, and runtimes of the old system are available as a reference or acceptance matrix.

Mixed DNS operation

• Mixed DNS operation – Different resolvers or expiring TTLs are redirecting users to both the old and new systems, resulting in inconsistent results.

• Modified application – Simultaneous code and configuration releases prevent the separation of infrastructure and application causes.

• Missing ancillary services – Mail, jobs, storage, or external shares were not fully migrated and are only failing in certain processes.

Follow-up to "Isolating Errors After a Server Migration"

Checking for Technical Causes of Suddenly Falling Impressions Answers the next practical question: What technical causes can trigger a sudden drop in impressions?

Differentiating PHP-FPM problems between code errors and resource limits Continues the thought with another question: How do you distinguish between a code error and exhausted process resources in PHP-FPM?

If you want to put "Isolating Errors After a Server Migration" into practice, you can go to Robust Website Systems Refer back to this resource. The focus there is on "HTTP, Redirects, and Server Changes" and "Comparable Requests."

Conclusion: Identifying Errors After a Server Change

A server change affects several layers, which can only be separated through controlled comparisons. A known reference shortens the path from a vague error pattern to the responsible component.

Sources and Further Information

The primary sources define the technical framework for "Identifying Errors After a Server Change."

• How HTTP status codes affect Google's crawlers – Google Crawling InfrastructureOfficial description of how Google handles 2xx, 3xx, 4xx, and 5xx responses, including soft 404 errors.

• Redirects and Google Search – Google Search CentralOfficial classification of permanent and temporary server-side and client-side redirects.