What I Learned Migrating Twelve Client Sites to Webflow's New DNS in One Week

With the June 1, 2026 hard deadline approaching for Webflow's Cloudflare DNS migration, I spent the last week of April moving twelve client sites onto the new infrastructure. Some clients were calm. Two were not. One had a CAA record nobody had documented in 2022 and it took an evening to figure out why SSL would not issue. This is a first person field note about what actually happens when a Bengaluru-based partner runs a real migration sprint, the small mistakes that cost time, and the playbook I will run for the next batch.

Why Did I Batch Twelve Migrations Into One Week?

Three reasons. The June 1 deadline is real and Webflow has confirmed that sites created before April 21, 2025 will go offline if DNS is not migrated. Spreading the work across multiple months would leave some sites perilously close to the deadline if anything went wrong. And batching the work meant building muscle memory across twelve repetitions in seven days, which is the fastest way to internalize a new procedure.

The fourth reason was honest pricing. Quoting twelve separate migration projects across different months produces twelve separate scope conversations and twelve separate invoices. Quoting them as a single sprint with bulk pricing made the economics work for both me and the clients. The clients got a better rate. I got concentrated work without context switching. The math favored the sprint, which is a pattern I expect to repeat for similar deadline-driven work in the future.

How Did I Sequence the Sites From Lowest Risk to Highest?

I sorted the twelve sites by complexity. Simple marketing sites with one domain and standard email setup went first. Sites with subdomains, custom email routing, or third-party integrations like Mailchimp or HubSpot went in the middle. Sites with bespoke setups including custom WAF layers or non-standard DNS configurations went last. The sequencing meant my mistakes happened on simpler sites where the impact was easier to recover from.

The first three migrations took the longest because I was learning the procedure. By the fifth migration, the pattern was muscle memory and each one took about thirty minutes. By the tenth, I was running two in parallel by alternating attention as each one waited for DNS propagation. The compounding pace is the reason batching works. Trying to migrate three sites a month would never produce the same fluency. The concentrated practice is what made the work fast.

What Did I Tell the Two Clients I Knew Would Push Back?

The two harder clients were both founders who had been burned by previous infrastructure changes elsewhere. I led with the deadline and the platform mandate, framing the migration as required maintenance rather than discretionary work. I included specific dates, named what would break if we did not migrate, and offered to schedule the migration during a low-traffic window of their choosing.

The framing that landed was that the work is not optional and the question is only when it happens. Both clients agreed once the conversation focused on logistics rather than on whether the work was needed. The lesson generalized across other deadline-driven work too. When the deadline is real and external, leading with the deadline shortens the negotiation. When the deadline is invented to create urgency, clients see through it. The honest framing is what works. I covered related client communication discipline in my Webflow project proposal that wins clients piece.

Which Step in the Webflow Migration Guide Tripped Me Up the Most?

The Orange-to-Orange Cloudflare setup. For clients who already use Cloudflare in front of Webflow with their own WAF rules and DNS configuration, the migration involves an extra step where you have to release a Cloudflare Zone Hold during the initial migration so the SSL certificate can issue cleanly. The Webflow Help Center documents this but the documentation is buried, and missing the step produces SSL errors that look like network problems but are actually Cloudflare configuration.

The fix took me an hour the first time and three minutes every subsequent time. The pattern is to read the migration guide thoroughly before starting, including the conditional sections that only apply to specific configurations. The five minutes of reading saves the hour of debugging. The discipline is undramatic. Skipping it cost me an evening that I will not get back, which is the kind of lesson you only learn once.

What Happened With the CAA Record Nobody Had Documented?

Site number nine had a CAA record from 2022 that restricted certificate issuance to a specific certificate authority. The original developer had set it up for a security audit and never removed it. When the Webflow migration tried to issue a new certificate from a different CA, the CAA record blocked the issuance. The site stayed in a half-migrated state with no SSL for about three hours while I figured out what was happening.

The diagnostic technique that finally worked was checking the DNS records exhaustively at the registrar level rather than only at Cloudflare. The CAA record was set at the registrar and not visible in the Cloudflare dashboard, which is why I missed it on the first pass. Removing the CAA record, waiting for propagation, and re-running the migration fixed the issue cleanly. The lesson learned is to audit DNS records at the registrar, not only at the proxy layer, which I now do as a standard pre-migration step.

How Long Did Each Migration Actually Take From Start to Publish?

The first three migrations took ninety minutes each because I was learning. The middle six took thirty to forty-five minutes each. The last three took twenty to thirty minutes. Total time across the twelve was about ten hours of focused work, spread across seven days because I waited for DNS propagation between sites and used the gaps for other client work.

The breakdown that mattered is that the manual work itself was always quick. Most of the time was spent waiting for DNS to propagate, SSL to issue, and the new configuration to verify. Running multiple migrations in parallel by alternating attention meant the wait times overlapped, which is what compressed the sprint into a week instead of two. The wait time is the constraint. The active work is small. Knowing that math up front would have shaped how I scheduled the sprint, which is the lesson I will use next time.

How Do I Handle Cloudflare Orange to Orange Clients Who Layer Their Own WAF?

The procedure has to preserve the client's existing WAF rules through the migration. The pattern that worked is to document every WAF rule before starting, run the migration, and then re-apply the WAF rules to the new configuration. Webflow's Cloudflare layer and the client's Cloudflare layer can both run simultaneously, but the rule order and the cache settings need careful attention to avoid conflicts.

The conversation with the client at the start needs to explicitly cover what happens to the WAF during the migration. Most clients with WAF rules have specific compliance reasons for them, and they want to know that nothing changes. Documenting the rules in writing, sending the documentation to the client before the migration, and confirming after the migration that the rules still apply is what builds the trust that makes future deadline-driven work go smoothly. The discipline takes thirty minutes per client and pays back across the relationship.

What Did I Miss the First Time That I Caught Only on the Third Site?

I missed checking the email DNS records on the first two sites. Both clients used Google Workspace for email, and I assumed the migration would not touch email DNS. It did not directly, but the migration process Webflow walks through asks you to confirm that all existing DNS records are accounted for, and skipping the email records meant I could not certify the migration cleanly. The third site is where I caught the gap because that client used a different email provider that surfaced the issue more obviously.

The fix was to add MX, SPF, DKIM, and DMARC verification to my pre-migration checklist for every site. Confirming email is intact before changing DNS is fifteen minutes of work that prevents the worst-case scenario, which is breaking client email mid-migration. The cost of a broken email setup is significantly larger than the cost of broken site hosting, because clients can survive a few hours of site downtime but they cannot survive losing access to their inbox. The checklist is now standard.

How Did I Price This Migration Work Without Padding the Invoice?

I quoted a flat rate per site that reflected the actual time the work took plus a reasonable margin for the surprises that show up across twelve migrations. Pricing per hour would have been awkward because the per-site time varied so much. Pricing too low would have been a giveaway. Pricing too high would have made the deadline feel exploitative.

The flat rate landed in a range the clients accepted without negotiation, partly because the deadline framing made the work feel like maintenance rather than discretionary, and partly because the rate was honest. The lesson is that flat-rate pricing on deadline-driven maintenance work earns more trust than hourly pricing, which is the same pattern I run on retainers. I covered the broader pricing discipline in my retainer pricing surprises piece.

What Does My Checklist Look Like Now That the Week Is Over?

The checklist has eleven items I run for every migration. Audit DNS records at the registrar level, including CAA records. Confirm email DNS records (MX, SPF, DKIM, DMARC) are documented. Verify Cloudflare Zone Hold is released for Orange-to-Orange clients. Document any existing WAF rules. Schedule the migration during low-traffic hours. Run the Webflow migration steps in the documented order. Wait for full DNS propagation before validating. Confirm SSL certificate has issued cleanly. Spot check three high-traffic URLs. Update the client with confirmation and any changes they should know about. Archive the documentation in a project folder for future reference.

The checklist is the artifact that makes the next sprint significantly faster. Anyone on the team can run it without needing me to walk through it personally. The checklist also surfaces gaps over time as new edge cases emerge, which is how it stays current rather than going stale. I covered related daily practice habits in my three daily habits piece. The checklist is the operational moat that small studios build deliberately. Without it, every migration feels like a new project. With it, every migration is a known procedure with predictable outcomes.

What Would I Do Differently if I Had to Migrate Twelve More Next Month?

Three things. Run the email DNS audit upfront on every site before scheduling the migration, which would have saved the first two surprises. Include the CAA check in the standard pre-migration audit so a 2022 leftover does not eat an evening. And quote the work as a defined sprint package from the start rather than per-site, which would have made the client conversations even simpler.

The fourth thing I would do is build a simple internal tool that automates the pre-migration audit. The tool would query DNS records at the registrar, check for CAA configurations, validate email setup, and produce a report I could send to the client before the migration as part of confirming readiness. Building the tool would take a day. The compounding savings across the next ten or twenty migrations would justify the build easily. The same pattern applies to most repetitive work. Build the tool once. Run the tool many times. The leverage is real and most studios undervalue it because the upfront investment feels disproportionate to a single project. Across many projects, the math is obvious.

If you are running a Webflow practice and have client sites that still need to migrate before June 1, drop me a line and tell me how many sites are in scope. Let's chat.