Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.obvlo.com/llms.txt

Use this file to discover all available pages before exploring further.

This guide is provided for informational purposes only and is intended for qualified IT professionals with a thorough understanding of DNS, SSL/TLS, and domain management. Obvlo accepts no responsibility for any downtime, data loss, or service disruption that may result from following these steps. Always test in a non-production environment first and ensure you have a verified rollback plan.
This document outlines the professional, industry-standard workflow for migrating a live production domain from any DNS provider to Cloudflare. Following this “Staging-to-Proxy” approach ensures that website traffic, email services, and app subdomains remain online throughout the entire transition.

​
Prerequisites and verification tools

Before starting, ensure you have administrative access to both your Domain Registrar (where you pay for the domain) and your current DNS Host.
ToolPurpose
DNSViz.netVerifying DNSSEC status
WhatsMyDNS.netReal-time monitoring of global nameserver propagation
Google Dig (Admin Toolbox)Verifying individual record resolution
AI AssistantSanitizing and reformatting non-standard DNS exports into BIND format

​
Phase 1: Pre-migration security (24–48 hours prior)

The most common cause of migration failure is DNSSEC. If nameservers are changed while the Top-Level Domain (TLD) registry still expects cryptographic signatures from the old provider, the domain will go offline globally.

​
Checklist

1

Identify DNSSEC status

Check your current registrar dashboard for DNSSEC/DS records.
2

Disable DNSSEC

Toggle DNSSEC to OFF in your registrar’s security settings.
3

Verify deletion

Enter the domain at DNSViz.net.
The graph must show an “Insecure” status (blue/gray boxes) with an NSEC3 proof from the registry. Do not proceed if any “Secure” (green) or “Broken” (red) paths remain.
4

Lower TTLs

Set all critical A, CNAME, and MX records to 300 seconds (5 minutes).
This ensures that if a rollback is required, the change propagates in minutes rather than hours.

​
Phase 2: The deep data audit (AI-assisted)

Cloudflare’s automatic scan frequently misses complex TXT records (DKIM, SPF), deeply nested subdomains, or service-specific verifications. A manual import is mandatory for production environments.

​
Checklist

1

Extract zone file

Export your current DNS records as a .csv, .txt, or .bind file from your existing provider.
2

Sanitize via AI

Upload the raw export to an AI Assistant with the following prompt to ensure 100% compatibility:
Convert these DNS records into a standard BIND zone file for Cloudflare import.
Use the format: [Name] [TTL] [Class] [Type] [Content].
Wrap all TXT values in double quotes.
For Webflow/Shopify/HubSpot CNAMEs, ensure trailing dots are included (e.g., cdn.webflow.com.).
Convert Root A-records to CNAMEs for '@' to enable Cloudflare CNAME Flattening.
3

Audit MX records

Manually cross-check that all Google Workspace (or other provider) MX records are present in the sanitized file.
4

Initial import

In Cloudflare DNS > Records > Import, upload the sanitized file.
5

Enforce Grey Cloud policy

Ensure every record is set to DNS Only (Grey Cloud).
This allows you to move DNS management without changing the underlying traffic routing or SSL handshake logic yet.

​
Phase 3: The nameserver handover

In this phase, you officially transfer “steering” control to Cloudflare.

​
Checklist

1

Set SSL mode

Navigate to Cloudflare SSL/TLS > Overview. Set the mode to Full (Strict).
Production origins (like Webflow) already have SSL. “Full (Strict)” ensures an end-to-end encrypted tunnel.
2

Update nameservers

In your Registrar (Squarespace/GoDaddy/etc.), replace the current nameservers with the two provided by Cloudflare.
3

Monitor propagation

Open WhatsMyDNS.net and check the NS record.
You should see a majority of global nodes returning the Cloudflare nameservers.
4

Await edge certificate

In Cloudflare SSL/TLS > Edge Certificates, wait until the status for your domain is Active.
Do not enable proxying until this certificate is issued.

​
Phase 4: Activation and proxying

Now that Cloudflare owns the DNS and has a valid SSL certificate ready, you can activate the Web Application Firewall (WAF) and Workers.
For detailed reverse proxy configuration (Cloudflare Workers, NGINX, Apache, IIS, and Caddy), see the Reverse proxy guide.

​
Checklist

1

Enable proxy (Orange Cloud)

Toggle the main @ and www records to Proxied.
2

Verify header flow

Load the website and inspect the Network tab.
Response headers must contain server: cloudflare and a cf-ray ID.
3

Deploy Workers

Bind your Workers to specific routes (e.g. example.com/blog/*).
4

SEO verification

Verify that subdirectories (like /blog) are rendering correctly and that canonical tags point to the proxied URL.

​
Phase 5: Post-migration optimization

1

Purge cache

Perform a Purge Everything in Cloudflare to ensure Worker logic is applied to all cached assets.
2

Enable DNSSEC (final step)

After 24 hours of stability, enable DNSSEC in Cloudflare.
3

Registry update

Copy the new DS Records from Cloudflare and paste them back into your Registrar’s security settings to re-establish the Chain of Trust.

​
Incident response and rollback procedures

​
Tier 1: Record-level rollback

If a specific subdomain breaks, toggle that specific record back to Grey Cloud (DNS Only). This instantly bypasses Cloudflare for that route.

​
Tier 2: The “kill switch”

If the entire site behaves unexpectedly, go to the Cloudflare Overview page and select Pause Cloudflare on Site. This maintains your DNS nameservers but stops all proxying, WAF, and Worker logic.

​
Tier 3: Nameserver reversal

If DNS resolution fails entirely, revert the nameservers at your registrar back to the original provider’s settings.
This is a “hard” rollback and may take several hours to propagate.