Moving a Domain Between Cloudflare Accounts: Lessons From a Terraform-Managed Migration

Category:Infrastructure

2026-08-26

Moving a Domain Between Cloudflare Accounts

A practical walkthrough from Don Kidd

Moving a domain between Cloudflare accounts sounds simple: add the domain to the new account, recreate the DNS records, and remove it from the old one.

In practice, DNS records are only part of the migration. The destination Cloudflare account receives its own authoritative nameserver pair, and an externally registered domain may remain in a Pending state until its registrar delegates the domain to those nameservers.

I recently worked through this while moving donkidd.us from one Cloudflare account to another. The DNS was managed with Terraform, the domain registration remained at an external registrar, and the goal was to make the move without interrupting the website, HTTPS, or email.

This is the process and checklist I would use again.

The Important Distinction

There are two related, but separate, parts of this type of migration:

  • Domain registration is where the domain is registered, renewed, and where authoritative nameservers are configured.
  • Cloudflare zone management is the Cloudflare account that owns the DNS zone and provides features such as proxying, SSL/TLS settings, redirects, security controls, Workers, and other services.

Moving a site’s DNS zone to a different Cloudflare account does not necessarily mean transferring its registration to a different registrar.

For an externally registered domain, Cloudflare assigned a new nameserver pair when I added the site to the destination account. The target zone did not become active until I updated the nameservers at the registrar to match that new pair.

The Starting Point

The migration involved:

  • donkidd.us in an existing Cloudflare account
  • A new Cloudflare account to become the zone owner
  • Terraform-managed DNS records
  • An external domain registrar
  • A requirement to avoid downtime
  • A desire to keep the DNS configuration reproducible and version-controlled

My initial mental model was straightforward:

  1. Add the domain to the new Cloudflare account
  2. Recreate the records with Terraform
  3. Remove the old zone
  4. Let Cloudflare activate the new zone

That approach was incomplete.

The destination Cloudflare zone received its own nameservers. Until the registrar delegated donkidd.us to those nameservers, the zone remained pending—even after the DNS records had been created successfully.

What I Learned

The main lesson is simple:

A Cloudflare account migration is not only a DNS-record migration. It is also a nameserver-delegation migration.

For a domain registered outside Cloudflare, plan to update nameservers at the registrar when the target Cloudflare account assigns a new pair.

That means a safe migration plan should include:

  • An inventory of the existing DNS zone
  • Recreation of records and relevant Cloudflare configuration in the destination account
  • Verification of the target configuration before changing delegation
  • A nameserver change at the registrar
  • Post-cutover testing of every service that depends on the domain

Migration Workflow

1. Inventory the Existing Setup

Before changing anything, document what exists in the old Cloudflare account.

At a minimum, capture:

  • A, AAAA, CNAME, MX, TXT, CAA, and SRV records
  • DNS record proxy status: proxied or DNS-only
  • TTL values where relevant
  • SPF, DKIM, DMARC, and mail-provider verification records
  • SSL/TLS encryption mode and origin-certificate details
  • Redirect rules and page rules
  • WAF and custom firewall rules
  • Workers, Pages, Access, Turnstile, Email Routing, and other Cloudflare products in use
  • DNSSEC configuration
  • Third-party validation records for services such as Google Workspace, Microsoft 365, GitHub, payment providers, or monitoring tools

DNS is easy to copy. The configuration around DNS is what is easy to miss.

2. Add the Domain to the Destination Account

Add the domain as a new zone in the destination Cloudflare account.

Cloudflare will scan for common DNS records and assign a nameserver pair for the new zone. Record those nameservers, but do not change them at the registrar yet.

At this point, the new zone will normally remain pending because the registrar is still delegating the domain to the nameservers associated with the old account.

3. Recreate DNS With Terraform

Terraform made this step predictable and repeatable.

Create the target zone resources in the destination account, then apply the DNS configuration there. Confirm that the Terraform provider is authenticated to the correct Cloudflare account and that every resource uses the new zone ID.

Terraform import is useful for bringing existing resources under management, but it does not move a DNS record from one zone into another. A DNS record belongs to a specific zone, so the target account needs its own resources created for the new zone.

Before proceeding, run:

terraform plan
terraform apply

Then compare the target DNS records against your original inventory.

4. Check DNSSEC Before Cutover

DNSSEC deserves its own checkpoint.

If DNSSEC is enabled, confirm the correct procedure with both the registrar and Cloudflare before changing nameservers. A mismatched or stale DS record can prevent successful resolution after the delegation change.

Do not treat DNSSEC as an afterthought. Include it in the cutover plan and rollback plan.

5. Update Nameservers at the Registrar

Once the destination zone has the required DNS records and configuration, update the domain’s nameservers at the registrar.

For this migration, that meant replacing the old Cloudflare nameserver pair at Dynadot with the pair Cloudflare assigned to the destination account.

After saving the registrar change:

  1. Return to the target Cloudflare zone.
  2. Use the dashboard option to re-check nameservers if needed.
  3. Wait for delegation and activation.
  4. Confirm that the target zone becomes active.

Activation timing can vary based on registrar updates and DNS propagation, so verify the actual delegation rather than relying only on a clock.

6. Validate the Cutover

Once the new zone is active, test every service that relies on the domain.

My post-cutover checklist includes:

  • The apex domain loads over HTTPS
  • www and any required subdomains resolve correctly
  • HTTP-to-HTTPS redirects work
  • Cloudflare proxying is enabled only where intended
  • SSL/TLS is valid at the edge and at the origin
  • Inbound email continues to arrive
  • Outbound email passes SPF, DKIM, and DMARC checks
  • Third-party services still validate their required TXT or CNAME records
  • Application redirects, webhooks, APIs, and monitoring endpoints work
  • Terraform reports the expected state after the migration

Only after those checks pass should the old zone and its related configuration be retired.

Terraform Lessons

This migration reinforced a few useful Terraform practices:

  • Keep Cloudflare account credentials and account IDs clearly separated by environment.
  • Treat the zone ID as account-specific infrastructure state.
  • Review terraform plan carefully before applying changes to DNS.
  • Keep DNS records in version control so the target zone can be recreated consistently.
  • Use separate provider aliases when managing more than one Cloudflare account.
  • Do not assume that successfully applying DNS records means the domain is already delegated to that zone.

Cloudflare provides import and configuration-generation tooling that can help bring existing resources into Terraform, but a cross-account move still needs a deliberate target-zone migration plan. [17][18]

Practical Takeaway

The migration was safe because the target configuration was built before nameservers changed.

The sequence to remember is:

  1. Inventory the source account.
  2. Create and configure the destination zone.
  3. Validate DNS and account-level Cloudflare settings.
  4. Plan for DNSSEC.
  5. Change nameservers at the registrar.
  6. Confirm activation.
  7. Test website, HTTPS, email, and integrations.
  8. Retire the old configuration only after validation.

If you manage domains for clients, nonprofits, or multiple personal projects, write down the migration plan before touching nameservers. The domain may be only one part of a larger system involving hosting, email, SSL, security settings, and third-party services.

Future posts in this series:

  • DNS Migration Checklist
  • Cloudflare Terraform Patterns for Multiple Accounts
  • Email DNS Records: SPF, DKIM, and DMARC During a Migration
  • Planning DNSSEC Changes During a Domain Move