Migration monitoring
Ship the migration without the 3am phone call
A migration moves hundreds of URLs at once, and any one of them can break silently — you usually find out from a user or a ranking drop. Sitewatch records what your site looked like before you moved it, then checks the new one after cutover — redirects, pages, and every file each page loads — so you find the broken bits first.
- Baseline the old site first, so "did we break it?" has an evidence-based answer
- Catches redirects that loop, land wrong, or quietly still hit the old host
- Keeps checking for the delayed failures that appear once caches expire
Part of the site is still on the old host
Plain-English summary
Product pages are being answered by the old server while everything else has moved. Both hosts respond normally, so nothing looks wrong from the outside.
01What can go wrong
The migration "went fine". Half of it did.
A migration is the one change where everything moves at once — host, paths, redirects, files, certificates. And every one of those can fail while still answering normally.
- 01You cut over on a Friday evening and spot-check a handful of pages.
- 02They all load, so the migration goes down as a success.
- 03But one section is still being answered by the old server, and a redirect rule sends another in circles.
- 04Both hosts respond normally, so no uptime check anywhere notices.
- You find out from your rankings, weeks later.
02Why traditional monitoring misses this
Both servers answer. That is exactly the problem.
An uptime check asks whether something responded — and during a migration, something always does. We don't just check that your site is online — we check that people can actually use it, and that they reached the site you meant them to.
Traditional uptime monitoring
It never asks which host answered, or how many hops it took.
Sitewatch
Only "healthy" once the whole site has actually moved.
03How Sitewatch catches it
One question, on every check after cutover.
Not "is the domain responding?" — but the one a migration actually turns on: is every page now the page we intended to serve?
- ✓Every page still resolves
- ✓Redirects land where intended
- ✓No redirect loops
- ✓Nothing still on the old host
- ✓Scripts and styling load
- ✓Images load
- ✓Content matches the baseline
- ✓Certificate is valid
04Typical failures we catch
The migration breakage nobody spot-checks for.
A redirect rule sends visitors in circles
Two rules disagree about where a path should go.
→Those pages are unreachable and search engines drop them
Part of the site never moved
One section is still answered by the old host, which is still running.
→Edits go to one site and visitors see the other
Three redirects where one was planned
Chained rules stack up during the move and are never unwound.
→Mobile visitors drop off and link equity leaks away
Files still point at the old location
Scripts and styling reference a host or path that no longer serves them.
→Pages load unstyled or with nothing interactive working
A page now returns something that is not a page
A route that used to serve content now hands back a file or raw data.
→Visitors and crawlers both hit a dead end
The certificate did not come with you
The new host serves the domain without a valid certificate.
→Browsers block the site outright
It broke three days later
A cache expires and the underlying misconfiguration finally shows.
→The failure arrives long after everyone stopped watching
05Migration workflow
Monitor every phase of the migration
- 01
Baseline before you move
Add your URLs at least a couple of days before cutover. Sitewatch records the current state — what each page returns, what it loads, where its redirects go — so afterwards you are comparing, not guessing.
- 02
Check during cutover
Run checks on demand as you switch DNS and deploy. Scheduled checks keep running underneath, every 5 to 30 minutes depending on your plan.
- 03
Get alerted on what changed
A redirect loop, a missing file, a page still coming from the old host — each becomes an incident naming the page and the problem, confirmed with a retry so the cutover window does not flood you with noise.
- 04
Prove it is done
When every check passes consistently, you have evidence rather than a feeling: every page reachable, every file loading, nothing left on the old host, no redirect surprises.
06What happens the moment we find it
Detection is not the outcome. Finishing the migration is.
Every incident tells you which page, what changed, and what it looked like before you moved.
We confirm it is real first
Every issue is re-checked before you are alerted — which matters most during a cutover, when DNS is propagating and transient oddities are expected.
Explained in plain English
"Product pages are being answered by the old server." A sentence you can put straight into the migration channel.
Compared against the baseline
Because Sitewatch recorded the site before the move, the alert can say what changed rather than only what is wrong now.
You can verify the fix
Fix the rule, run a check on demand, and close the incident on evidence before you call the migration done.
07The cost of finding out late
The same cutover, with and without a baseline.
Without migration monitoring
Fri 22:00 — DNS switched. A dozen pages spot-checked by hand. All fine.
Fri 22:30 — Migration declared complete. Everyone goes home.
Mon — Traffic looks slightly down. Blamed on the weekend.
Week 3 — Rankings have slipped on a whole section of the site.
Week 3 — Someone finally checks and finds a redirect loop and a section still on the old host.
Found by search rankings
With Sitewatch
Wed — Site added and baselined while still on the old host.
Fri 22:00 — DNS switched. An on-demand check runs immediately.
Fri 22:04 — Two incidents: a redirect loop, and product pages still on the old host.
Fri 22:40 — Both fixed. A second on-demand check confirms it.
The following week — A delayed failure appears as a cache expires, and is caught the same way.
Found by monitoring
Forty minutes on the night, instead of three weeks of lost rankings. This scenario is illustrative, not a customer case study.
08Who it's for
Built for whoever is holding the rollback plan.
Dev teams →
A verification step that runs against production, after the change.
Agencies →
Migrate a client site and hand over evidence that it landed cleanly.
Freelancers →
Move a site on a Friday without spending the weekend refreshing it.
Store owners →
A migration that breaks checkout is the most expensive kind.
09Everything we detect
What Sitewatch catches during a migration
Redirects and routing
- Redirects that send visitors in circles
- Redirect chains longer than intended, which cost you speed and link equity
- Redirects that end on a page that is not there
- Redirects that hand visitors to a domain you did not intend
- Paths that used to resolve and no longer do
Host, files and content
- Pages still being answered by the old host after cutover
- Scripts, stylesheets and images that do not load on the new host
- Files served as the wrong kind of file after a CDN change
- Pages returning something other than a web page
- Content that differs from the pre-migration baseline
- Certificate problems on the new infrastructure
10vs. checking it yourself
Manual migration QA vs Sitewatch
| Scenario | Manual QA | Sitewatch |
|---|---|---|
| Redirect checking | Spot-check a handful of URLs by hand | Every monitored path followed and verified |
| Did it actually move? | Check from one network and hope it is consistent | Pages still on the old host are flagged |
| Files on the new host | Open a few pages and look around | Everything each page loads is fetched and verified |
| When you find out | Hours to weeks — usually from rankings | Minutes, on a schedule and on demand |
| Coverage | Key pages, maybe | Every monitored page and everything it loads |
| Delayed failures | Nobody is still watching | Checks keep running after the migration |
| Evidence | Screenshots in a document | Incidents with the page, the problem and the before-state |
Redirect checking
- Manual QA:
- Spot-check a handful of URLs by hand
- Sitewatch:
- Every monitored path followed and verified
Did it actually move?
- Manual QA:
- Check from one network and hope it is consistent
- Sitewatch:
- Pages still on the old host are flagged
Files on the new host
- Manual QA:
- Open a few pages and look around
- Sitewatch:
- Everything each page loads is fetched and verified
When you find out
- Manual QA:
- Hours to weeks — usually from rankings
- Sitewatch:
- Minutes, on a schedule and on demand
Coverage
- Manual QA:
- Key pages, maybe
- Sitewatch:
- Every monitored page and everything it loads
Delayed failures
- Manual QA:
- Nobody is still watching
- Sitewatch:
- Checks keep running after the migration
Evidence
- Manual QA:
- Screenshots in a document
- Sitewatch:
- Incidents with the page, the problem and the before-state
5 min
Fastest check interval
On demand
Run a check mid-cutover
6
Alert channels
Your next migration, without the panic
Add your URLs and baseline the site before the migration starts. Free plan, no credit card.
11Questions
Migration monitoring questions, answered
At least 48 hours before cutover. That gives Sitewatch time to record what the site currently returns, loads and redirects to — so after the move you are comparing against a real baseline instead of trying to remember how it used to behave.
Yes, and it is the failure this page exists for. Sitewatch examines what answers each request, so when a section is still being served by the old server — which is usually still running, and still answering perfectly — it is flagged rather than passing as healthy.
Sitewatch follows every hop of each monitored path and checks the whole chain: no loops, no more hops than intended, and the right destination at the end. Each path is logged, so you can see exactly where a rule goes wrong instead of guessing.
Every issue is confirmed with a retry before you are alerted, which filters out most of the transient noise DNS propagation produces. During the window itself, most teams lean on on-demand checks and let the scheduled ones confirm things once the dust settles.
Yes. Moving from WordPress to a headless CMS, changing hosts, consolidating domains, or replatforming a store — the fundamentals are the same, and so are the ways they break: redirects, files, availability and content.
Those are the ones that hurt, because everybody has stopped watching. Sitewatch keeps checking on its normal schedule after cutover, so a misconfiguration that only surfaces once a cache expires or DNS fully propagates is caught the same way as one on the night.
12Explore more