Moving from Cloudflare
Build a Cloudflare-hosted frontend in Fortly and identify the backend routes, bindings and data that need a separate migration.
An ordinary supported application should install dependencies and build from its source. Fortly handles public downloads used by build scripts, including Google Fonts and OCR assets, through its controlled build proxy. You do not need to edit an application just to replace those normal downloads with local files.
Cloudflare Pages can also host backend routes and connect them to other Cloudflare services. Those are separate from the frontend's compiled files. Cloudflare's binding documentation describes that relationship.
Check what your project uses
| Part | Fortly behavior |
|---|---|
Static frontend, including Next.js output: "export" | Builds and publishes the exported files. |
| Supported server-rendered framework | Builds using Fortly's server adapter. See Builds. |
| npm dependencies and public build-time assets | Package mirrors plus controlled HTTP/HTTPS downloads. |
Pages Functions under functions/ | Identified as backend code requiring migration; they are not silently discarded. |
| D1 bindings | No automatic D1 provisioning or data import. Fortly's managed database is PostgreSQL; the D1 binding API and SQLite-specific SQL need adaptation. |
| R2 bindings | No automatic bucket binding or object migration. Storage APIs and object access rules must be reviewed separately. |
| KV and Durable Object bindings | No automatic compatibility binding or state migration. |
During source builds, Fortly checks Wrangler TOML, JSON and JSONC, including bindings declared in named environments. Pages-style route handlers are also identified when no Wrangler file is present. A detected backend requirement prevents release certification. This keeps an incomplete application from being presented as live and working.
Understand the deployment result
Open the release in Deployments and choose Build & deploy output. A frontend can show Compiled successfully and generated pages, followed by Cloudflare backend requires migration. These describe two different stages: compilation worked; the application still needs its backend services.
The console explains that result as Cloudflare backend needs migration. Review the named services and the application routes that use them before trying again. Your earlier live release keeps serving.
Plan the backend migration
Inventory the Pages routes, binding names, environment variables and existing data. Decide which services you will retain externally and which you will adapt to Fortly. Port backend routes into a supported application runtime, update database/storage access, and configure the required environment values.
Keep private objects private throughout the move. A storage API that returns public file URLs is not a substitute for an authenticated route serving protected R2 objects. Exporting a D1 database likewise does not convert its SQLite schema and queries to PostgreSQL. Cloudflare documents D1 export; review schema and access rules before using Fortly's import tools.
Test sign-in, protected data, uploads, backend routes and background work before changing your production hostname. Deploying source to Fortly does not move Cloudflare data, credentials or bindings automatically.