Migrating from WP Engine to Pantheon: Resolving Cloudflare Domain Conflicts

Made on

Cloudflare to Cloudflare WordPress migration issues.
“Thunderclouds” by GlacierNPS is marked with Public Domain Mark 1.0 .

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:

RecordHostnameDestination
CNAME@Pantheon Global CDN
CNAMEwwwPantheon 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:

TypeNameValue
TXTcf-removal-verificationCloudflare-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:

TypeNameDestinationProxy
CNAME_acme-challengePantheon-provided DCV hostnameDNS Only
CNAME_acme-challenge.wwwPantheon-provided DCV hostnameDNS 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

Pantheon: Orange-to-Orange

Cloudflare: Cloudflare for SaaS

Cloudflare: Custom Hostname Validation

Cloudflare: Error 1001

Cloudflare: DNS Records