Migrating a WordPress website between hosting providers usually involves moving the application, transferring the database, testing the new environment, and updating DNS. The DNS change can be the simplest part of the process or it can be a huge undertaking!
If hosting providers use Cloudflare infrastructure, it introduces a complication when transferring the production domain. Although the DNS configuration appears correct, in this case Pantheon couldn’t complete domain ownership verification due to an existing Cloudflare hostname association with the previous hosting provider.
Resolving a conflict requires coordination with Pantheon support, changes to DNS validation records, and a Cloudflare-specific ownership verification process.
Why Cloudflare Complicates Some Hosting Migrations
Cloudflare is widely used by managed WordPress hosting providers. WP Engine uses Cloudflare infrastructure for services including its CDN and security capabilities. Pantheon’s next-generation Global CDN also operates on Cloudflare. This creates an interesting situation when migrating between the two providers.
The original hosting environment may have a Cloudflare configuration associated with the production hostname. The destination hosting provider needs to establish its own configuration for that same hostname. In some circumstances, the existing association can prevent the destination provider from completing hostname validation or activation.
The issue can persist even when the DNS records have been updated correctly.
DNS Ownership and Cloudflare Hostname Ownership Are Different
DNS determines how a hostname resolves. For example:
www.example.com → fe.cfp2c.edge.pantheon.io
This tells DNS resolvers where the hostname should direct traffic. However, Cloudflare also maintains internal configurations that determine which accounts and services are authorized to handle particular hostnames.
These configurations are not necessarily visible through ordinary DNS lookups. mA hostname may therefore have the correct DNS destination while still encountering problems with Cloudflare’s domain validation or routing. This distinction is important when troubleshooting migrations between providers that both use Cloudflare.
The Migration Scenario
Recently we were migrating an existing WordPress website from WP Engine to Pantheon.
The application had been prepared in Pantheon’s environment, and the production domain needed to be activated. Pantheon’s next-generation Global CDN provided the destination hostname and our expected DNS configuration was straightforward:
| Record | Hostname | Destination |
|---|---|---|
| CNAME | @ | Pantheon Global CDN |
| CNAME | www | Pantheon Global CDN |
The specific CNAME destination was supplied by Pantheon, however, the domain verification process didn’t complete successfully. Pantheon support identified an existing Cloudflare association that needed to be addressed before the destination configuration could be completed. This was separate from the WordPress migration itself. Frustrating!!!
Understanding Cloudflare Hostname Conflicts
Cloudflare supports configurations where hosting providers manage customer domains through their own Cloudflare infrastructure. Cloudflare for SaaS is one mechanism that allows a provider to serve customer-owned hostnames through its Cloudflare account.
For example, a hosting provider may configure www.example.com as a custom hostname within its Cloudflare environment. When the website moves to another provider using Cloudflare, the destination provider may need to establish a new association for the same hostname.
Depending on the existing configuration and Cloudflare’s validation requirements, this can create a conflict.
Why Updating DNS May Not Resolve the Problem
Changing a CNAME updates the public DNS destination. It does not necessarily remove a hostname configuration maintained by another Cloudflare account. Consequently, the destination hosting provider may continue encountering ownership verification problems after DNS propagation has completed. This is why repeatedly changing DNS records may not help.
The problem exists at a different layer of the infrastructure.
Identifying the Domain Verification Failure
During our migration, Pantheon couldn’t complete the domain ownership verification process. This was an important distinction from a normal DNS propagation delay. A propagation delay generally resolves as recursive DNS caches expire and begin returning the updated records.
A Cloudflare hostname ownership conflict may require an explicit verification or removal process.
What to Check First
Before assuming a hostname conflict, verify the DNS configuration.
Use:
dig example.com A +short
And:
dig www.example.com CNAME +short
If Cloudflare proxying is enabled, public DNS may return Cloudflare IP addresses rather than exposing the underlying CNAME.
Also check the current HTTPS response:
curl -I https://www.example.com/
These commands establish how the domain resolves and whether the website responds. They do not reveal every hostname association maintained within Cloudflare. If the DNS configuration is correct but Pantheon cannot complete domain activation, the next step is to investigate the validation failure with Pantheon support.
Resolving the Conflict with Cloudflare Removal Verification
Pantheon support provided a specific DNS verification record to authorize removal of the existing Cloudflare hostname association. The record used the following name:
cf-removal-verification
This is a Cloudflare ownership verification mechanism. The TXT record provides evidence that the party requesting the change controls the domain.
Example TXT Record
The configuration follows this general structure:
| Type | Name | Value |
|---|---|---|
| TXT | cf-removal-verification | Cloudflare-provided authorization token |
The actual value is unique to the verification request.It may resemble:
i-authorize-cloudflare-x-removal-EXAMPLE-TOKEN
Do not reuse an authorization token from another domain or migration.
The correct value must be supplied by Pantheon support or the appropriate Cloudflare verification process.
Why the TXT Record Is Necessary
The verification record establishes authorization to remove or change an existing Cloudflare hostname association. It does not directly change the website’s DNS destination.
Instead, it supports the administrative process needed to resolve the conflicting hostname configuration. Once the TXT record is publicly available, Pantheon support can continue the appropriate verification or removal procedure.
Verify the TXT Record
After adding the record, check that it resolves:
dig TXT cf-removal-verification.example.com +short
The response should contain the exact authorization token. If the record doesn’t appear, verify the hostname, value, and authoritative DNS provider. Remember that the DNS record must be created in the zone currently authoritative for the domain. Adding the record to an inactive DNS provider won’t satisfy validation.
Updating ACME Certificate Validation Records
The Cloudflare hostname verification process was only part of the migration. Pantheon also required DNS records for HTTPS certificate validation. These records were associated with the ACME protocol.
ACME allows certificate authorities and hosting platforms to validate domain control before issuing certificates. In our case, the configuration involved two hostnames:
_acme-challenge and _acme-challenge.www
Remove Conflicting TXT Records
The existing DNS configuration included TXT records associated with ACME validation. Pantheon support instructed us to remove the conflicting TXT records before adding the new validation CNAMEs.
This distinction matters because a CNAME cannot coexist with other DNS record types at the same hostname. For example, the following configuration is invalid:
_acme-challenge.example.com TXT "existing-token"
_acme-challenge.example.com CNAME validation.example.net
The TXT record must be removed before the CNAME can be created.
Add the Pantheon Validation CNAMEs
Pantheon provided domain-specific CNAME destinations for certificate validation. The configuration followed this structure:
| Type | Name | Destination | Proxy |
|---|---|---|---|
| CNAME | _acme-challenge | Pantheon-provided DCV hostname | DNS Only |
| CNAME | _acme-challenge.www | Pantheon-provided DCV hostname | DNS Only |
The destinations were Cloudflare-managed domain control validation hostnames. Use the exact values supplied by Pantheon.
Why DNS Only?
These records are used for DNS validation. They are not application hostnames and should not be proxied through Cloudflare. Keep both records set to DNS Only (gray not orange!)
Once configured, verify them:
dig _acme-challenge.example.com CNAME +short
dig _acme-challenge.www.example.com CNAME +short
Compare the results against the values supplied by Pantheon support. Correct validation records allow the certificate provisioning process to proceed once the other domain ownership requirements have been satisfied.
Avoiding Downtime During the Cutover
The most important operational consideration is sequencing. A WordPress website can be fully migrated and tested while its production hostname remains dependent on the previous hosting provider.
Changing that dependency before the destination environment is ready can create an outage. For migrations involving Cloudflare on both sides, we recommend the following approach.
1. Complete the WordPress Migration
Move the application, database, and required assets to Pantheon. Test the website using the Pantheon environment URL or another supported testing method. Verify application functionality before changing production DNS.
2. Add the Production Domain to Pantheon
Configure the required hostnames in Pantheon. Review the DNS instructions and certificate validation requirements. If Pantheon reports a hostname ownership conflict, investigate it before proceeding with the production cutover.
3. Complete Ownership Verification
Work with Pantheon support to obtain the required Cloudflare verification token. Publish the cf-removal-verification TXT record. Confirm that it resolves publicly. Allow Pantheon support to complete the appropriate Cloudflare-side process.
4. Configure Certificate Validation
Remove conflicting ACME TXT records when instructed. Add the required validation CNAMEs. Keep them set to DNS only. Verify that the records resolve correctly.
5. Coordinate the Production DNS Change
Once the destination environment is ready, update the production DNS records according to Pantheon’s instructions. Avoid removing the previous hosting configuration prematurely.
The exact sequence may depend on the existing Cloudflare association and the requirements supplied by Pantheon support.
6. Verify the Production Website
After the cutover, check the production hostname.
Use:
curl -IL https://www.example.com/
Confirm that the expected application responds. Review HTTPS certificate status, redirects, and WordPress functionality. Also verify that administrative access, forms, integrations, and other application features continue working.
What About Cloudflare Orange-to-Orange?
There is another Cloudflare configuration that can complicate Pantheon deployments.
An organization may already use its own Cloudflare account to proxy traffic before it reaches Pantheon’s Cloudflare-powered CDN.
This is known as Cloudflare Orange-to-Orange (O2O). More about that here…
Lessons from the Migration
Several details from this migration are worth considering before moving a WordPress website between Cloudflare-backed hosting providers.
DNS Changes Don’t Remove Existing Cloudflare Associations
A correct CNAME doesn’t guarantee that the destination provider can activate the hostname. Cloudflare may maintain an existing association that requires additional verification.
Certificate Validation Is a Separate Process
Resolving a hostname ownership conflict doesn’t automatically complete HTTPS certificate provisioning. ACME records must still be configured correctly.
Provider Coordination Matters
Some migration issues cannot be resolved entirely through the DNS dashboard.
The hosting provider may need to coordinate with Cloudflare to release or reassign a hostname.
Avoid Premature Hostname Removal
Removing an existing hostname configuration before the replacement is ready can interrupt production traffic. This is particularly important when both hosting providers use Cloudflare.
Verify Each Infrastructure Layer
DNS resolution, Cloudflare hostname ownership, TLS certificates, HTTP routing, and WordPress application behavior are separate components. A successful check at one layer doesn’t establish that the others are configured correctly.
Planning a WP Engine to Pantheon Migration?
We work with organizations migrating WordPress websites to Pantheon, including projects involving complex DNS configurations, Cloudflare integrations, CDN changes, and infrastructure troubleshooting.
Our team handles application migrations as well as the technical details surrounding them, including domain validation, SSL certificates, caching, security configurations, and production cutovers.
If you’re planning a migration from WP Engine to Pantheon or need assistance resolving a Cloudflare domain conflict, contact Knihter.
Technical References
Pantheon: Next-Generation Global CDN
Cloudflare: Cloudflare for SaaS
