Summary

  • Cloudflare describes old-provider content remaining after a CNAME update when the departing SaaS supplier configured an exact hostname and the incoming supplier configured a wildcard.
  • The new supplier can provision the specific hostname. Handover needs prepared hostname and certificate validation, a DNS switch, confirmation of traffic at the new destination and then retirement of the old configuration.

The completion email arrived before the customer

Imagine a shop changing its website provider. Procurement has the signed contract. Engineering has the DNS change. The project manager has sent the completion email. A customer opens the familiar address and finds the old shop. The encrypted connection works too. Three teams have receipts for their work; the visitor has reached the wrong counter.

Cloudflare’s SaaS troubleshooting documentation describes a configuration that can produce this result. An older supplier’s specific custom hostname can take precedence over a new supplier’s wildcard custom hostname, leaving the old content in place after a CNAME update.

The ranking does not consult the date on the new contract. The specificity of the record matters. The customer’s purchasing decision still needs to become a completed delivery instruction.

One precise door beats a broad invitation

An entry for mystore.example.com identifies a particular address. A wildcard covers a group of names and reduces configuration work. During a move, that broad rule can encounter an older entry naming the requested door exactly.

Cloudflare’s hostname-priority rules describe multiple proxied records for one hostname across several zones. Only one record controls the zone settings and associated origin server. Under those conditions, an exact match precedes a wildcard match. A documented example puts an old exact hostname ahead of a newly configured wildcard.

The incoming supplier needs to know what it is replacing. A convenient arrangement for onboarding many customers can be too broad to take over this address. The efficiency of group administration leaves an individual checking job at the handover.

For the shop, the effect is concrete: it has selected another service while its requests can remain governed by the earlier configuration. The person editing DNS and the person preparing the new platform must compare their results at the address customers actually use.

The incoming supplier has a job it can do

Cloudflare recommends asking the new SaaS provider to provision the specific hostname instead of the wildcard. The alternative described is for the account’s Super Administrator to contact Cloudflare Support for an update to the SaaS configuration.

The handover meeting therefore has an answerable question: has the incoming supplier registered this exact name? Assuming that the old supplier is deliberately holding the customer would overlook the documented remedy on the new supplier’s side. The public sources contain no particular customer’s configuration inventory, migration logs or interruption costs; those records would establish the impact of that customer’s move.

The new application can be installed and the new contract paid. Until it receives the visitors, an essential part of the purchased service is awaiting delivery. Notices saying that something was created or edited need to culminate in evidence of receipt.

Successful encryption can belong to another preparation

The configuration guide separates hostname activation from certificate issuance and deployment. Production readiness requires both states to be active and DNS to point to the intended SaaS target.

A TLS handshake can succeed before the new certificate becomes active because Cloudflare can present another matching certificate. A working encrypted connection therefore leaves the newly prepared certificate’s own state to be checked. It is an observation about a connection, with a narrower meaning than a full onboarding acceptance.

An active fallback origin has a defined scope as well. The guide says Cloudflare is ready to send traffic to the designated DNS record; the customer must still ensure that record points to the correct origin location. A green status can confirm readiness to dispatch before anyone has checked the recipient.

Commercial acceptance can ask for four connected results: the exact hostname activated, its certificate ready, the DNS target correct and a request actually processed by the new zone and expected application. Filling a contract with every technical field would add less than showing that those results refer to the same delivery.

Prepare both entrances before handing over

The hostname-validation and migration guidance allows multiple SaaS providers to hold an active custom hostname for the same domain simultaneously. Pre-validating a hostname already on Cloudflare does not, by itself, move its traffic.

The recommended ordinary migration prepares the hostname and its pre-validation on the new zone, then gets the certificate ready using TXT or Delegated DCV. The customer changes the CNAME, the traffic switch to the new zone is confirmed, and the previous provider can then delete its custom hostname. That sequence needs to be read alongside the exact-versus-wildcard priority check.

Overlapping preparation has value. The old service can retain its place while the new service finishes arranging reception. By contrast, real-time hostname validation or automatic HTTP certificate validation after the DNS change can leave a short interruption while activation completes, as the configuration guide explains.

Retiring the old entry belongs after the arrival evidence. Removing it too early can throw away preparation that still has a job. Leaving everything indefinitely adds more historical configuration for the next investigation to understand. Preparation, switching and cleanup deserve separate records.

Keeping the public address while choosing another supplier is valuable to the shop. Behind that address, the chosen supplier must actually start receiving the visits. Customers are unlikely to study the migration plan to discover whose task finished prematurely.