Introduction

An origin migration can move the application successfully while a Cloudflare Worker still calls the old backend. Dashboard-level origin settings may already point to the new server, but edge code continues sending requests to a hardcoded URL, old binding, or previous backend hostname that survived the migration.

Treat this as an edge-code backend-target problem instead of a general origin-routing failure. Start by checking the actual fetch target used inside the Worker, because post-migration traffic can still reach legacy infrastructure when the edge application keeps its own backend reference separate from dashboard routing.

Symptoms

  • A Cloudflare Worker still calls the old backend after origin migration
  • Requests through the Worker hit legacy infrastructure even though main origin settings are updated
  • The new backend works directly, but Worker-mediated traffic still returns old behavior or old data
  • Only routes handled by the Worker show the old backend symptoms
  • Logs reveal requests from the Worker still target the previous hostname or service
  • The issue started after origin migration, backend replacement, or partial Cloudflare app cleanup

Common Causes

  • The Worker code still contains a hardcoded old backend URL
  • Environment variables or bindings still reference the previous backend target
  • A migration updated origin rules or DNS but did not update the Worker fetch path
  • Different environments exist, and production still uses an old Worker configuration
  • Teams validated direct origin traffic but skipped edge code paths during cutover
  • A helper module or service binding inside the Worker still resolves to legacy infrastructure

Step-by-Step Fix

  1. Reproduce the failing request through the Worker and confirm it differs from direct access to the new backend, because you need proof that the edge code path is the source of the stale target.
  2. Check the Worker code and runtime configuration for the exact backend URL, hostname, binding, or fetch target it uses, because Cloudflare edge code can preserve its own origin reference independently of dashboard settings.
  3. Compare the Worker target with the intended post-migration backend endpoint, because a hardcoded or environment-scoped value often survives after the rest of the cutover is complete.
  4. Review deployment environments and active production bindings, because staging and production Worker settings frequently drift during backend migrations.
  5. Update the real backend reference used by the Worker only after confirming the destination service is ready, because changing the wrong environment or binding can create a second outage.
  6. Redeploy or publish the Worker configuration change and verify the live edge path now targets the intended backend, because editing code without activating it will not change production behavior.
  7. Retest the same route through Cloudflare and compare the result with direct backend access, because both paths should now align on the migrated service.
  8. Review related Workers, routes, or helper modules that call backend services in the same stack, because legacy backend references often appear in more than one edge path.
  9. Document the final backend target and deployment path for each Worker after recovery, because edge-side origin references are easy to miss during future migrations.