Von Netlify zu Cloudflare Pages: Was der Wechsel wirklich bedeutet

Netlify ist eine solide Plattform. Deployments laufen sauber, die Entwicklererfahrung ist gut, und für einfache statische Sites bleibt sie im Hintergrund. Sobald man aber ohnehin Cloudflare für DNS und CDN nutzt — was bei den meisten der Fall ist — entsteht durch Netlify ein zusätzlicher Vendor, zusätzliche Latenz und bei steigendem Traffic zusätzliche Kosten.

Wir haben mehrere Astro-Sites zu Cloudflare Pages migriert. Die Hauptgründe: Cloudflare Functions haben durchschnittlich 1–10ms Cold Starts gegenüber ca. 200ms bei Netlify Functions, das Free-Tier beinhaltet unbegrenzte Bandbreite, und die Konsolidierung auf eine Plattform vereinfacht alles — von DNS-Verwaltung bis zum Rotieren von Secrets.

Hier ist, was die Migration wirklich erfordert — inklusive der nicht offensichtlichen Teile.

Die richtige Reihenfolge bei mehreren Sites

Wer mehrere Sites migriert, sollte das nicht gleichzeitig tun. Die Reihenfolge, die funktioniert:

Zuerst die einfachste statische Site — keine Functions, reines HTML. Das validiert das Cloudflare-Pages-Setup.
Danach Sites mit einer Function.
Zuletzt die komplexeste Site — mehrere Functions, Payment-Flows, externe Integrationen.

Jede Site gründlich testen, bevor die nächste angegangen wird. Rollback ist einfach (DNS-Record ändern), aber zwei gleichzeitige Migrationen zu debuggen ist es nicht.

E-Mail-Infrastruktur: Als Erstes erledigen

Das ist der Teil, den Netlify-Nutzer am häufigsten übersehen. Netlify Functions können SMTP direkt verwenden — nodemailer, jeder SMTP-Host. Cloudflare Workers können das nicht. Die Workers-Runtime unterstützt keine TCP-Verbindungen, was SMTP voraussetzt.

Vor der Migration muss auf eine HTTP-basierte E-Mail-API gewechselt werden. MailChannels ist für Sendungen aus Cloudflare Workers kostenlos. Maileroo, Resend und Postmark funktionieren ebenfalls.

Die Code-Änderung ist überschaubar:

// Netlify (nodemailer)
const transporter = nodemailer.createTransport({ host: 'smtp.example.com', ... });

// Cloudflare (HTTP-API)
await fetch('https://smtp.maileroo.com/send', {
  method: 'POST',
  headers: { 'X-API-Key': env.MAILEROO_API_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({ from: '...', to: '...', subject: '...', html: '...' }),
});

Bei MailChannels müssen diese DNS-Records zur Domain hinzugefügt werden:

# SPF — zum bestehenden Record hinzufügen
v=spf1 include:_spf.mx.cloudflare.net include:BISHERIGER_PROVIDER ~all

# Domain Lockdown (verhindert Spoofing)
Typ: TXT  |  Name: _mailchannels  |  Inhalt: v=mc1; cfp=2

5–10 Minuten für DNS-Propagation einplanen, bevor der erste Test-Versand ausgeführt wird.

Dateistruktur und Handler-Syntax

Netlify Functions liegen in netlify/functions/. Cloudflare Functions liegen in functions/ im Projekt-Root. Die URL-Pfade bleiben gleich, der Frontend-Code muss also nicht angepasst werden — nur die Function-Dateien verschieben sich und die Handler-Syntax ändert sich.

# Netlify
netlify/functions/contact-form.js   →   erreichbar unter /api/contact-form

# Cloudflare
functions/api/contact-form.js       →   erreichbar unter /api/contact-form

Der Handler selbst unterscheidet sich:

// Netlify
exports.handler = async (event, context) => {
  return { statusCode: 200, body: JSON.stringify({ ok: true }) };
};

// Cloudflare
export async function onRequestPost(context) {
  const { request, env } = context;
  return new Response(JSON.stringify({ ok: true }), {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
  });
}

Umgebungsvariablen funktionieren anders: process.env.MY_VAR wird zu context.env.MY_VAR. Öffentliche Astro-Variablen (import.meta.env.PUBLIC_VAR) funktionieren auf beiden Plattformen gleich.

Stripe-Webhooks brauchen eine URL-Aktualisierung

Wer Stripe-Payments betreibt, muss nach der Migration die Webhook-URL im Stripe-Dashboard aktualisieren:

Alt: https://yourdomain.com/.netlify/functions/stripe-webhook
Neu: https://yourdomain.com/api/stripe-webhook

Stripe → Developers → Webhooks, Endpoint-URL bearbeiten und prüfen, ob das Webhook-Secret noch mit der STRIPE_WEBHOOK_SECRET-Umgebungsvariable übereinstimmt. Vor dem Go-Live mit Stripes eigenem Webhook-Test-Tool prüfen.

Rollback-Plan

Netlify-Sites 7–14 Tage nach der Migration aktiv halten. Für einen Rollback: CNAME in Cloudflare DNS zurück auf xxx.netlify.app setzen, und bei Stripe-Webhooks die URL ebenfalls zurücksetzen. Das war’s — 2-Minuten-Rollback.

Darum migriert man eine Site nach der anderen. Hat die komplexeste Site ein Problem, sind die anderen bereits stabil auf Cloudflare und es gibt nur eine Baustelle.

Nach 14 Tagen stabilem Betrieb

Sobald alles bestätigt funktioniert:

Netlify-Sites aus dem Dashboard löschen
netlify/-Verzeichnisse aus Repositories entfernen
netlify.toml-Dateien entfernen
netlify-cli aus Dev-Dependencies entfernen

Der Wechsel lohnt sich. Cloudflares Edge-Netzwerk ist schneller, das Preismodell ist einfacher, und DNS, CDN und Deployment auf einer Plattform zu haben reduziert die Anzahl der Dashboards, die man bei einem Ausfall prüfen muss.