Changing the hosting origin behind an existing Cloudflare proxy

Migrate files and databases consistently, install a valid origin certificate and test the new server using a hostname-aware method. Coordinate final writes for stores, forms or membership sites so data is not split across two active origins.

1. Export the DNS zone and record the existing origin value. Identify all relevant A, AAAA and CNAME records, including www.
2. Verify the new origin accepts the public hostname and Cloudflare’s connections under the current TLS mode.
3. Edit the relevant record’s Content value to the confirmed new origin while retaining the intended proxy status. Review any separate Origin Rules or load-balancer configuration that could override it.
4. Test dynamic pages, login, uploads and transactions through the public domain. Check the new origin’s logs to confirm requests arrive there.
5. Purge only content that became stale during the migration, monitor errors and keep the old origin available for a controlled rollback until the move is stable.

Cloudflare should serve the new origin’s application and current data. Cached static content may temporarily hide the origin change, so verify a safe uncached request and server logs.

If only some requests fail, inspect stale AAAA records, hostname mappings, origin certificates and firewall permissions. A DNS change does not synchronise later database writes back to the old server, so rollback requires a data decision as well as restoring the old IP.

Usually not when Cloudflare remains authoritative. You change the origin destination inside the existing zone, while checking any other routing products involved.

• Moving a Cloudflare site to Full strict TLS safely
• Purging one changed asset from Cloudflare cache
• Diagnosing Cloudflare error 521 when the origin refuses connections
• Keeping mail and FTP hostnames outside Cloudflare’s web proxy

• Cloudflare: Create DNS Records
• Cloudflare: Origin Rules