Introduction

A Cloudflare Pages migration can deploy the new project successfully while the custom domain still serves the old one. The DNS may look correct and the new pages.dev URL may work, but Cloudflare Pages can keep the production hostname attached to the previous project until that binding is moved cleanly.

Treat this as a Pages project-association problem instead of a generic DNS cutover issue. Start by checking which Pages project currently owns the custom domain, because the hostname can remain attached to the old project even when the new build and repository migration are already complete.

Symptoms

  • The custom domain still serves the old Cloudflare Pages project after migration
  • The new project works on its pages.dev address but not on the production domain
  • Adding the custom domain to the new Pages project fails or shows that the domain is already in use
  • DNS records appear correct, but live traffic still shows the old deployment or old project content
  • SSL or domain verification status stays pending after moving the project
  • The issue started after recreating a Pages project, moving repositories, or changing build ownership

Common Causes

  • The custom domain is still attached to the old Cloudflare Pages project
  • The old Pages project was left active and still claims the production hostname
  • DNS was updated, but the Pages domain binding itself was never moved
  • A wildcard, alias, or secondary domain binding in the old project still matches the hostname
  • Validation checked the new pages.dev deployment but did not confirm the custom-domain association
  • One hostname such as www or the apex domain moved while another stayed attached to the previous project

Step-by-Step Fix

  1. Identify the exact custom domain that is serving the wrong project and confirm which new Pages project is supposed to own it, because you need a clear source and destination before changing any bindings.
  2. Review the custom-domain list on both the old and new Cloudflare Pages projects, because the hostname may still be explicitly attached to the previous project even if DNS already points through Cloudflare.
  3. Check for wildcard, alias, or redirect-style bindings on the old project that could still claim the hostname, because a broader rule can keep the domain attached even when the obvious entry looks removed.
  4. Remove the custom domain from the old Pages project only after confirming the new project is ready to receive it, because production traffic needs a valid target when the association changes.
  5. Add the custom domain to the new Pages project and complete any required verification step, because the domain must be reassigned at the project level rather than only at the DNS layer.
  6. Verify that the DNS records for the hostname match Cloudflare Pages guidance for the new project, because the Pages binding and the live DNS target both need to agree.
  7. Wait for the domain and SSL status to become active, then retest the exact hostname that previously served the old project, because pending validation can temporarily mask whether the reassignment succeeded.
  8. Compare the live custom domain response with the intended new deployment to confirm the old project no longer serves production traffic, because the pages.dev URL alone does not prove the migration is complete.
  9. Document which Cloudflare Pages project owns each production domain after recovery, because project-level domain bindings are easy to overlook during future Pages migrations.