Edge Architecture
Cloudflare & Edge Migration
Move an origin-bound application onto Cloudflare Workers and edge delivery — for latency, resilience, and a hosting bill that stops scaling with traffic.
Written scope and a fixed-scope proposal. No sales calls.
Who this is for
The buyer this is written for
- Role
- Engineering lead or founder responsible for both the performance budget and the infrastructure bill
- Organisation
- A product or content platform still served from a single origin — VPS, managed hosting, or a single-region cloud instance behind a CDN that only caches static assets
- What triggers the search
- Slow pages for users far from the origin, traffic spikes that degrade the whole service, rising hosting costs, or a security requirement the current setup cannot meet.
The problem
What is actually going wrong
Everything routes back to one origin
Distant users pay the round trip on every request. The CDN in front of the application only helps with static assets because everything dynamic is uncached and origin-bound.
Traffic spikes degrade the entire service
Concurrency that should be routine saturates the web server or database connection pool, and a busy hour becomes an outage. Scaling up means paying for peak capacity permanently.
Infrastructure cost scales with traffic, not with revenue
Bandwidth, always-on compute, and standby capacity are billed whether or not they are being used, and the trend line only points one way.
Edge migration is easy to get half-right
Moving to Workers without addressing session handling, caching boundaries, and the data tier produces a faster front-end in front of the same bottleneck — plus a new class of failure to debug.
What you get
Delivered in the engagement
- An architecture assessment of what can move to the edge, what must stay at origin, and why
- A caching and invalidation model defined per route, not applied globally and hoped for
- The migration to Cloudflare Workers or Pages, with the application boundary reworked where the edge requires it
- A security gateway at the edge — request authentication, rate limiting, and fail-closed defaults
- Deployment and rollback wired into CI, with automated validation on every change
- Before/after latency measurement against the routes that matter to the business
How it runs
The sequence
- 01
Measure the current path
Establish where time is actually spent — origin round trip, server processing, database queries, or uncached dynamic responses. The migration plan follows the measurement.
- 02
Draw the edge boundary
Decide explicitly what runs at the edge, what stays at origin, and what state has to be reachable from both. This boundary is the whole design; getting it wrong is what makes edge migrations fail.
- 03
Rework state and sessions
Origin-bound session handling and connection-per-request data access do not survive a move to the edge. They are addressed before the cutover, not discovered during it.
- 04
Harden at the perimeter
Authentication, rate limiting, and abuse protection move to the edge where they belong — configured to fail closed, so a missing secret denies access rather than granting it.
- 05
Cut over and verify
Traffic moves once the new path is proven against the old one, with latency measured on real routes and a documented rollback available throughout.
Evidence
Engagements that prove this
Every claim below is drawn from a recorded engagement. Each links to its full case study, including the trade-offs that were accepted.
Primary evidenceLegacy Modernization • Jul 2026 • Astro, Cloudflare, PHP, PostgreSQL, TypeScript
A full origin-to-edge migration: PHP monolith to a decoupled frontend on Cloudflare Pages and Workers, executed in a fixed 14-day window.
- Monolithic PHP origin decoupled into an Astro frontend on Cloudflare Pages and Workers, inside a fixed 14-day window
- 62% reduction in page load latency — 1.8s down to 680ms
- Zero downtime cutover with 100% data integrity
- Fail-closed WebCrypto HMAC security gateway and API rate limiting delivered as part of the migration
- 100% automated CI build and test validation
Read the full case study →Marketing and Advertising • Jun 2025 • CSS, JavaScript, Laravel, MySQL, Nginx, PHP
A high-write advertising platform where the bottleneck was the request path itself — the same class of problem an edge migration has to solve rather than relocate.
- Synchronous third-party API calls inside the request cycle were starving web server threads; decoupling ingestion to queue workers resolved it
- Campaign metrics normalised within 15-minute windows without breaching third-party API rate limits
- Composite MySQL indexes on campaign_id and timestamp to sustain time-series reads under concurrent automation
- Relational ACID storage deliberately retained over NoSQL because budget rules cannot tolerate lost writes
Read the full case study →Transportation Industry • Feb 2018 • JavaScript, MySQL, PHP, WordPress
The caching and asset-offload half of an edge migration, applied to a platform serving 100MB+ documents from a single origin.
- Decoupling asset delivery to object storage with CDN caching reduced server memory usage by 75%
- Concurrent large-file downloads no longer spike origin CPU
- Sync risk introduced by decoupling was covered by an automated nightly consistency checker
Read the full case study →Wider evidence: Platform Hardening draws on 105 recorded engagements, from a corpus of 106 documented projects.
Questions
Answered directly
Can an existing PHP or WordPress application move to Cloudflare?
The application boundary usually has to change — origin-bound sessions and connection-per-request data access do not survive the move unaltered. The reference engagement decoupled a PHP monolith into an edge-served frontend on Pages and Workers, which is what made the 62% latency reduction possible.
Will this actually reduce cost?
It reduces the cost that scales with traffic — bandwidth and always-on compute — provided the caching boundary is drawn properly. That assessment comes first, before any migration is proposed, because the answer depends on how much of your traffic is genuinely dynamic.
What about security at the edge?
Authentication, rate limiting, and abuse protection move to the perimeter as part of the migration, configured to fail closed. On the reference engagement that meant a WebCrypto HMAC gateway and API rate limiting delivered alongside the migration itself.
How is the result verified?
Latency is measured on real routes before and after, and build and test validation runs automatically on every change. The reference engagement shipped with 100% automated CI validation and a zero-downtime cutover.
This page answers
- How do I migrate an existing application to Cloudflare Workers?
- Is moving to the edge worth it for a PHP or WordPress site?
- How do you reduce page latency for users far from the origin server?
- What breaks when you move a session-based application to Cloudflare Workers?
- Who can migrate a single-origin app to edge hosting without downtime?
Start a written project inquiry
Describe the current stack and hosting, where users experience latency, your traffic pattern, and what the migration has to avoid breaking.
Describe your current hostingYou describe the problem in writing. You receive a written scope, an approach, and a fixed-scope proposal.
