The cutover, hour by hour
The scary part of leaving a hosted platform is not the rewrite. It is the ninety minutes where both systems are half true and nobody knows which one holds the real order. Teams postpone migrations they have already justified on every other axis because that window feels unbounded. It is not. You can shrink it to a handful of minutes, and almost all of that shrinking happens in the week before, not on the day.
The clock starts when you lower the TTL
DNS decides how long your old system keeps receiving traffic after you think you switched. On Cloudflare, an unproxied record can go down to 60 seconds on non-Enterprise plans and 30 seconds on Enterprise, while the Auto setting is 300 seconds. Proxied records sit at a fixed 300 seconds you cannot edit. So the honest question is not when you flip the record. It is what your TTL was 24 hours earlier.
Drop it to 60 a full day ahead. Resolvers that cached the old value at 3600 need that long to age out, and the ones that ignore your TTL entirely will ignore it whatever you set. Check the record from outside your own network too, because your laptop resolver is the least representative one you own.
Do this and the DNS portion of the cutover stops being a variable. The old host still answers for a minute or two after the switch, which is exactly why the next part matters.
Dual writes, then a read-only window you can time
The pattern that removes the fear is boring. Run both systems, write to both, read from one. PostgreSQL logical replication fits the shape of this problem. It takes a snapshot of the publisher, copies it to the subscriber, then streams later changes in publisher order, so transactional consistency holds within a subscription. It also replicates across different major versions, which matters when the platform you are leaving runs something older than where you are going.
On Stay World Class we moved Webflow plus Xano onto Next.js, NestJS and Supabase, and the thing that kept the cutover short was a four stage ETL that mapped every legacy ID onto a PostgreSQL UUID and kept the mapping. Rerun the last stage against a delta and you get the tail of changed rows in minutes instead of reimporting everything. The site landed at Lighthouse 91 against 55.91 before, with LCP 77 percent faster. None of that would have counted for much if the switch had cost a day of orders.
Then you take the read-only window. Freeze writes on the old system, drain the replication lag to zero, verify row counts on the tables that carry money, flip DNS, unfreeze. If the ETL delta runs in four minutes, your window is four minutes plus the checks. Publish that number to whoever owns the revenue before the weekend. A stakeholder who was told ten minutes and got twelve stays calm. One who was told nothing does not.
The rollback you build and hope to skip
A rollback is not the same as putting the DNS record back. Anything written to the new system during the window has to survive the trip home, so either you reverse the replication direction before you cut over, or you accept that rolling back discards those writes. Decide which one you are doing while nobody is shouting.
Old URLs break quietly. If the platform's URL shapes do not survive the rewrite, the redirects need to exist at the switch, not the following week. Cloudflare Bulk Redirects covers 10,000 URL redirects across lists on Free and 25,000 on Pro, and Single Redirects allows 10 rules on Free and 25 on Pro, with wildcard support on every plan and regex only from Business up. That tells you whether your legacy URL map fits in rules or needs a list, and it is cheaper to learn on a Tuesday.
Set a decision deadline as well. Something like: if we are not green by 02:00 we roll back and try again next week. The failure I have watched most often is not a broken migration. It is a team still debugging at 04:00 because nobody agreed in advance what giving up looks like.
When you should not do this yet
If the platform is holding fine, none of this is urgent. A Webflow marketing site that ranks, loads fast and changes twice a month has no cutover to plan. Neither does a Bubble internal tool used by nine people. The platform has to be costing you something real before a migration weekend is worth paying for.
Skip it too if you cannot get a read-only window at all. Some businesses take orders every minute of every day, and those need a long dual-write period with traffic shifted gradually rather than one switch, which is a different and more expensive project. And if you have no staging copy of production data to rehearse against, build that first. A cutover you have already run end to end on a quiet Tuesday is a different animal from one you are performing for the first time with customers watching.
