The bill is rarely the compute. It is egress, capacity reserved for a peak that never comes, and managed services priced for a scale you are not at. Most of an application moves to Cloudflare cleanly. The work is knowing which parts, and in what order.
A migration is an inventory first. Each workload either has a Cloudflare-native home, needs a bridge, or belongs where it is. Deciding that honestly is what keeps the cutover boring.
API routes, handlers, and the glue between services move to Workers. No instances to size, no idle capacity reserved for a peak that arrives twice a year.
Static sites and SSR frameworks deploy to Pages with the CDN, TLS, and preview environments included rather than assembled from four separate services.
Same S3 API, zero egress. For anything that serves files to users, this line item alone is often the whole business case.
Small relational workloads move to D1. Postgres and MySQL that need to stay put get Hyperdrive in front, so the Worker is not paying a cold connection tax on every request.
Scheduled jobs become Cron Triggers, background work becomes Queues, and the EC2 box whose only job was running crontab is retired.
GPU workloads, long-running stateful services, and anything with a hard-won compliance boundary stay where they are, fronted through Cloudflare so the rest can move.
The legacy cloud bill was designed around instances and regions. Most applications built in the last decade are neither, and pay every month for the mismatch.
What the application looks like once it is there is cloud application development; when the code has to change on the way, it is legacy modernization. For a platform already running on Workers, see the donation platform case study.
Send us a recent invoice and a rough map of what runs where. We will tell you what moves, what stays, and what the bill looks like afterward. Engagements can be structured against the savings we find, so the audit costs nothing if there is nothing to save.