OriginDiff Website Migration Toolkit

In development · read-only migration evidence

Know what to verify before, during, and after a website move.

OriginDiff — Website Migration Toolkit is being built to organise bounded DNS, origin, TLS, redirect, root-page SEO, and mail-record evidence around the decisions a hosting migration requires.

Review the pre-cutover checklist See the planned method

One migration, three evidence windows

Build the decision from the stage you are in.

A migration is not a single DNS lookup. The expected state, useful evidence, and responsible owner change as the cutover progresses.

Before DNS cutover

Define the expected state.

Record the current site and mail baseline, identify the new public origin, and verify the new host with the correct hostname and TLS name before traffic changes.

During propagation

Separate waiting from a fault.

Compare named authoritative and recursive resolver views with the expected origin. A few observations can explain a split view; they cannot prove every cache has converged.

After migration

Recheck the public path.

Review HTTPS, apex and www redirects, root-page canonical and robots signals, sitemap discovery, and current mail-record presence against the saved baseline where one exists.

Planned decision language

Four words, each with a boundary.

These are future result meanings, not a live assessment of your site.

GO
Critical checks passed and the declared expected state was observed in the bounded evidence.
WAIT
The expected origin appears healthy, but observed resolver results or caches have not converged.
ROLLBACK
A critical observed problem makes the current cutover decision unsafe until it is resolved.
INCOMPLETE
There is not enough evidence for a decision. Missing observations are not presented as a pass.

Useful now · pre-cutover checklist

Leave yourself evidence and a way back.

Use this before changing nameservers or address records. Store the notes with the migration ticket so another owner can reproduce the decision.

  1. Confirm ownership.Record who controls the registrar, authoritative DNS, old host, new host, CMS or app, mail service, and SEO settings.
  2. Capture DNS as a baseline.Save delegation and the relevant A, AAAA, CNAME, MX, TXT, and CAA values, including priorities and TTLs. Note the evidence source and time.
  3. Identify expected origins.Write down the intended public IPv4 or IPv6 for apex and www. Keep old and new values clearly labelled.
  4. Test the new virtual host.Verify that the new server answers for the real hostname and TLS SNI. A direct IP request alone does not exercise the same configuration.
  5. Review HTTPS and redirects.Check certificate hostname coverage, basic chain validity, apex and www behaviour, the final URL, and obvious loops or HTTPS downgrades.
  6. Record root-page signals.Capture the homepage status, title, H1, canonical, robots meta, robots.txt, and sitemap location. This is not a full crawl.
  7. Protect mail configuration.Save the exact MX, SPF, and DMARC records before a nameserver change. Current presence alone cannot prove that a record was preserved.
  8. Prepare rollback.Keep the old hosting service, backups, credentials, and a tested rollback owner available until post-cutover evidence is stable.
  9. Choose the observation window.Plan when and from which named resolver or network views you will recheck. A small sample cannot represent every resolver or client cache.
  10. Write the stop rule.Agree which TLS, origin, redirect, page, DNS, or mail-record differences require waiting, escalation, or rollback before you begin.

Planned evidence method

Expected, observed, sourced, and owned.

OriginDiff is intended to turn bounded observations into a handoff, rather than hide them behind a score.

Checks in scope

  • DNS delegation, record answers, expected origin, and named resolver views
  • HTTP and HTTPS for apex and www, TLS names, redirects, and final URL
  • Root-page title, H1, canonical, robots directives, and sitemap discovery
  • Mail-record presence, plus stable before-and-after comparison when a baseline exists

Evidence before advice

A future finding is planned to show the expected value, observed value, source, timestamp, severity, responsible owner, and a bounded next step. Unknown evidence stays unknown.

Possible owners include the registrar, DNS provider, old or new host, CMS or app, mail provider, SEO owner, or unknown when the evidence does not justify an assignment.

Limits stay visible

The toolkit is not a security audit, full-site crawler, JavaScript-rendered test, mail delivery test, or guarantee of uptime, indexing, or migration safety.

DNS and website state can change after observation. Mail or SEO records are never described as preserved or lost without a baseline or explicit expected value.

Why this workflow

Shaped by hosting support practice.

OriginDiff is being built from the recurring work of hosting support: establishing what should have changed, collecting evidence from the right layer, and routing the next action to the person who can fix it.

There are no customer results or live accuracy claims on this page. Product behaviour, retention, and report privacy will be documented when those capabilities exist.

Current page boundary

No input, tracking, or external runtime requests.

This homepage has no form, scanner, analytics, advertising, cookies, third-party scripts, remote fonts, or external media. The DNS Checker is a separate page with a bounded live lookup.