TL;DR

If you’re migrating between hosting services that both use Cloudflare then don’t be surprised when you see the old site after cutting over DNS to the new provider. Your request is going into the new IP, but being served from the old cache. The old provider needs to be de-provisioned so that Cloudflare can pick up the new content.

Background

My Atsign colleagues have spent the last few months working on a new atsign.com website, and yesterday was go live day. I was drafted in to take care of the DNS cutover.

We’d previously used Kinsta for hosting, but the new site has been built on Webflow. I knew that Kinsta used Cloudflare as its CDN. Webflow was new to me, and I wasn’t aware of its operational details.

Prepping the cutover

I was given 4 DNS records to implement:

1. An apex A record for atsign.com pointing to 198.202.211.1
2. A CNAME for http://www.atsign.com pointing to cdn.webflow.com
3. A verification TXT record for atsign.com
4. A verification TXT record for http://www.atsign.com

I did the verification TXT records hours ahead of the agreed cutover time as there was no reason to wait. I also added the apex A record IP to my /etc/hosts to see if I could already see the new site; but my browser was showing the old site. This was my first clue that something was funky.

The moment arrives

The website team and I got onto a Zoom call and I stepped through the process to update records:

1. Create apex A record
2. Remove previous apex CNAME
3. Modify www CNAME

Webflow quickly showed that the DNS changes were complete as expected, and began the process of generating TLS certificates. The www cert took a few minutes, and we were then able to publish the new site. Various folk on the call were able to confirm they were seeing the new site – hooray :)

Apex stuck

www might be working as hoped, but the apex site wasn’t. We were still seeing the old site. Also the TLS certificate was taking ages to provision.

We checked that the new IP had propagated. It had. Online tools showed it was out there, and everybody on the call was seeing the new IP on their laptops etc.

But we were still seeing the old site. How could that be? That site content had never been on Webflow, so how were we seeing a site published on Kinsta with an IP that belonged to Webflow?

Both on Cloudflare

It was then that I asked ‘does Webflow use Cloudflare?’, and it turns out that they do.

The issue was then obvious – we might be hitting a ‘Webflow’ IP, but we were getting ‘Kinsta’ content, because both use the same content delivery network (CDN). Our test browsers were asking for atsign.com, getting sent to the ‘Webflow’ IP, which is an entry point to the Cloudflare CDN, and then being shown the atsign.com content that Cloudflare had cached for Kinsta.

I asked Gemini “if I’m migrating a web site from kinsta to webflow how do I evict the old site from the cloudflare caches?” and got:

Migrating from Kinsta to Webflow involves a transition between two host platforms that both run Cloudflare under the hood (known as an “Orange-to-Orange” or O2O environment).

Because both hosts use Cloudflare, “purging cache” alone isn’t always enough—you must cleanly disassociate the domain from Kinsta so that Cloudflare’s global edge stops routing traffic to Kinsta’s edge zone and sends it to Webflow instead.

Pulling the plug

The website lead then jumped onto the MyKinsta portal and set about removing the old atsign.com domain (first we had to demote it from being the primary domain).

Moments later the TLS certificate provisioning for atsign.com completed in the Webflow console. I’m pretty sure that it hadn’t been able to complete the ACME process because the verification page wasn’t being served. But with Kinsta removed Cloudflare was now serving Webflow content and everything snapped into place :)

Conclusion

This was a bit of a headscratcher. How could the new hosting provider be serving the old site? But it all made sense once we realised that they both use Cloudflare. The new provider was an entry point to Cloudflare, and until we removed the old site the CDN was serving the old content.