Webflow zu Astro migrieren – wenn Sie der Plattform entwachsen sind.

Sehr oft: ja. Zufriedenheit ist bei einer Website-Plattform ein hartes Argument – sie bedeutet meistens, dass Ihr Team ohne Reibung arbeitet. Ein Wechsel lohnt sich erst, wenn ein konkreter Engpass benennbar ist: Mengengrenzen im CMS, Hosting über viele Sites, teure Lokalisierung, fehlendes Code-Review, nicht erreichbare Integrationen. Ohne einen solchen Engpass bauen wir Ihnen lieber weiter in Webflow – für uns ist das dieselbe Rechnung.

Nein, und wir würden einem solchen Tool auch nicht trauen. Astro pflegt offizielle Migrationsleitfäden für eine Reihe von Quellsystemen – unter anderem Next.js, Gatsby und WordPress – für Webflow gibt es keinen. Der reale Weg ist: statische Ausgabe exportieren oder das Design sauber nachbauen, und das Inhaltsmodell in Astro neu aufsetzen. Das Ergebnis sieht aus wie vorher, die Technik darunter ist neu.

Teilweise. Der Export liefert die statische Ausgabe – HTML, CSS, JavaScript und Assets – und ist als Referenz für das Design wertvoll. Was er nicht liefert: Ihre CMS-Inhalte als saubere Daten, den Formularempfang und alles, was auf der Plattform serverseitig läuft. Ob der Export in Ihrem Tarif verfügbar ist, prüfen wir zu Projektbeginn. Wir behandeln ihn als Vorlage, nicht als Fundament: Der erzeugte Code bringt die Klassenlogik des Baukastens mit, und die wollen wir nicht dauerhaft in Ihrem Repository haben.

Eine fokussierte Marketing-Site mit wenigen Seitentypen: 3 bis 5 Wochen. Eine Site mit Blog, mehreren Collections und einem Redaktionsteam: 6 bis 10 Wochen. Mehrsprachig oder mit Anbindung an ERP, PIM oder eine Suchlösung: ab 12 Wochen. Die Spanne bewegen vor allem die Anzahl wirklich unterschiedlicher Templates, die Inhaltsmenge, ob Inhalte übernommen oder neu geschrieben werden – und die Freigabezyklen bei Ihnen. Die Aufschlüsselung steht oben unter „Zeitrahmen“.

Ihre alte Site bleibt online, bis die neue steht. Wir bauen parallel auf einer Staging-Adresse, migrieren die Beiträge dorthin und prüfen sie automatisiert und stichprobenartig. Umgeschaltet wird über DNS beziehungsweise Hosting – ein Vorgang von Minuten, nicht von Tagen. Ein Fenster gibt es trotzdem: den Redaktionsstopp von zwei bis fünf Tagen vor dem Wechsel, damit neue Beiträge nicht nur im alten System landen. Eine Garantie auf null Ausfall geben wir nicht; wir legen den Wechsel in eine verkehrsarme Zeit und halten den alten Stand als Rückfallebene bereit.

Nicht, wenn die Migration geplant wird. Rankings gehen bei solchen Projekten durch fehlende Weiterleitungen, verlorene Metadaten und vergessene strukturierte Daten verloren – nicht durch das Framework. Wir übernehmen entweder die bestehende URL-Struktur oder legen eine vollständige Redirect-Karte an, übertragen Metadaten und Schema, reichen die Sitemap neu ein und messen Sichtbarkeit und Core Web Vitals vor und nach dem Wechsel in Ihrem eigenen Projekt.

Es ist der häufigste – aber prüfen Sie zuerst den einfacheren Weg. Die konkreten Grenzen hängen bei Webflow am Tarif und ändern sich, deshalb zitieren wir hier keine Zahlen, sondern sehen sie uns in Ihrem Workspace an. Manchmal löst ein Tarifwechsel oder ein aufgeräumtes Datenmodell das Problem für zwei weitere Jahre. Reicht auch das absehbar nicht, ist Astro die strukturell andere Antwort: Content Collections lesen Inhalte zur Build-Zeit ein und sind ausdrücklich für tausende Einträge ausgelegt.

Der Formularempfang der Plattform entfällt mit dem Umzug – das ist der Punkt, den Teams am häufigsten unterschätzen. Wir schreiben deshalb vorher auf, was ein Absenden heute tatsächlich auslöst: Bestätigungsmail, interne Benachrichtigung, Eintrag im CRM, bedingte Empfänger, Verzweigungen, Weiterleitung auf eine Danke-Seite. Das bauen wir neu – als serverseitig gerenderte Route, über einen Formulardienst oder direkt in Ihrem CRM beziehungsweise Automatisierungswerkzeug, inklusive Spam-Schutz und DSGVO-konformer Verarbeitung. Bestehende Einsendungen exportieren wir vor der Abschaltung.

Sie werden nachgebaut, nicht übernommen. Diese Interaktionen hängen an der Laufzeitbibliothek der Plattform; ohne sie laufen sie nicht. Wir gehen sie deshalb einzeln durch: Scroll-Effekte, Hover-Zustände, Ein- und Ausblendungen und Übergänge lassen sich in aller Regel eins zu eins mit CSS und kleinen Skripten erreichen. Aufwendige Timeline-Animationen entstehen als Insel mit einer Komponente aus React, Svelte, Vue oder Alpine – geladen erst, wenn sie in den Viewport kommt. Sehr komplexe Sequenzen sind ein eigener Posten im Angebot, kein Beiwerk.

Ja. Lottie-Dateien sind JSON und plattformunabhängig – sie kommen unverändert mit. Abgespielt werden sie danach über einen Player, den wir gezielt als Insel einbinden: nur auf den Seiten, auf denen die Animation wirklich vorkommt, und geladen erst beim Eintritt in den Viewport. Das ist einer der wenigen Punkte, an denen der Umzug den Auftritt meist spürbar leichter macht, weil der Player nicht mehr auf jeder Seite mitgeliefert wird.

Bitte nicht. Das Abo läuft weiter, bis die neue Seite live ist und geprüft wurde – bis dahin ist die alte Site Ihre Rückfallebene. Vor der Kündigung legen wir ein vollständiges Archiv an: CSV-Export aller Collections, ein Abzug über die API, der statische Export und der komplette Bildbestand. Danach können Sie Site-Plan und gegebenenfalls Workspace kündigen; achten Sie dabei auf Ihren Abrechnungszeitraum, weil Jahrespläne bis zum Periodenende laufen. Erst kündigen und dann feststellen, dass ein Feld fehlt, ist der teuerste aller Abläufe.

Nicht als Ganzes – und hier raten wir besonders oft zum Bleiben. Astro ist ein Framework für die Präsentationsschicht, kein Shop-System: Warenkorb, Checkout, Zahlung, Steuern und Bestellverwaltung müssten aus einem Commerce-Backend kommen, das Sie dann zusätzlich betreiben. Das ist ein eigenes Projekt und kein Anhängsel der Migration. Sinnvoll wird es erst, wenn Katalog oder Prozesse ohnehin über die Plattform hinausgewachsen sind – und das klärt eine E-Commerce-Prozessberatung schneller und billiger als ein Migrationsangebot.

Den Rahmen bestimmen drei Dinge: die Anzahl wirklich unterschiedlicher Seitentypen – nicht die Seitenzahl –, die Tiefe des Inhaltsmodells und die Integrationen wie CMS, Formulare, CRM oder Warenwirtschaft. Eine fokussierte Marketing-Site mit einem Blog liegt deutlich unter einem mehrsprachigen Auftritt mit Datenübernahme. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit offengelegten Annahmen; die Kostenfaktoren haben wir unter Astro-Kosten aufgeschlüsselt.

Über einen von drei Wegen, die sich kombinieren lassen. Erstens: Inhalte als Markdown im Repository, typsicher eingelesen über Content Collections – gut für technikaffine Teams. Zweitens: ein Headless CMS mit Redaktionsoberfläche, Vorschau und Rechten – das kommt dem gewohnten Editor am nächsten. Drittens: die Pflege per Chat über einen Bot – für Textänderungen, neue Beiträge, Bildtausch und Preiskorrekturen realistisch auch ohne technisches Team, weil das Schema die Leitplanke ist und jede Änderung als Commit mit Historie landet. Layout, neue Seitentypen und mehrstufige Freigaben bleiben davon ausgenommen. Welcher Weg passt, entscheiden wir nach Ihrem Redaktionsalltag, nicht nach Technikvorliebe.

Weniger, als die Frage vermuten lässt – berechtigt ist sie trotzdem. Eine Astro-Komponente besteht im Kern aus HTML, CSS und JavaScript beziehungsweise TypeScript; wer Webentwicklung kann, ist in wenigen Tagen produktiv. Dazu gibt es offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js, sodass vorhandene Komponenten und vorhandenes Team-Wissen weiterverwendbar bleiben. Astro steht unter MIT-Lizenz, es gibt also kein Lizenztor. Fairerweise gilt umgekehrt dasselbe: Wirklich gute Webflow-Umsetzung ist ebenfalls Spezialwissen.

Ja, das ist ausdrücklich vorgesehen. Sie bekommen ein gewöhnliches Repository mit Node-Toolchain, dokumentierte Skripte für Entwicklung, Build und Deployment, das Inhaltsschema und eine Übergabe für Ihr Team. Kein proprietärer Baustein von uns liegt dazwischen. Wenn Ihre Entwicklerin morgen übernehmen will, kann sie das – wir übergeben vollständig oder begleiten weiter, je nachdem, was Sie brauchen. Wie laufender Betrieb bei uns aussieht, steht unter Astro Support & Wartung.

Dann läuft Ihre Website weiter. Repository, Hosting-Konto und Domain stehen von Anfang an auf Ihren Namen, nicht auf unseren. Das Framework ist quelloffen unter MIT-Lizenz, die Toolchain ist Standard, das Inhaltsmodell ist dokumentiert, und jede Änderung liegt als Commit in der Historie. Es gibt keinen Schlüssel, den nur wir haben. Genau deshalb achten wir darauf, dass nichts Wichtiges ausschließlich in unseren Köpfen existiert – bei einem kleinen Team ist das keine Floskel, sondern Risikomanagement.

Wir. Vor dem Wechsel halten wir schriftlich fest, was als Mangel gilt: fehlende Weiterleitungen, nicht übertragene Inhalte, Funktionen, die nicht so arbeiten wie vereinbart. Solche Fehler beheben wir im Rahmen der Gewährleistung, ohne gesonderte Rechnung. Davon zu trennen ist der laufende Betrieb – neue Anforderungen, Upgrades, Änderungen am Inhalt; dafür gibt es Wartung. Diese Grenze klären wir im Angebot und nicht erst, wenn etwas hakt.

Wir nennen bewusst keine Prozentzahl, weil solche Zahlen ohne Ihr Projekt nichts aussagen. Was sich sagen lässt: Astro rendert standardmäßig vorab und liefert statisches HTML aus, und es entfernt standardmäßig sämtliches Client-JavaScript aus Komponenten – Interaktivität wird pro Komponente wieder aktiviert. Ob das bei Ihnen einen messbaren Unterschied macht, hängt an Ihrer aktuellen Seite. Deshalb messen wir vor und nach dem Wechsel mit Ihren eigenen Felddaten statt mit fremden Benchmarks.

Ja, und das ist häufiger sinnvoll, als es klingt. Ein verbreitetes Muster: Kampagnen- und Landingpages bleiben im visuellen Werkzeug, damit Marketing weiter ohne Entwickler arbeitet, während Blog, Dokumentation, Standort- oder Produktseiten in Astro entstehen, weil sie aus strukturierten Daten kommen. Zwei Systeme unter einer Domain, klar getrennte Zuständigkeiten. Das erfordert etwas Disziplin im Betrieb und spart oft ein ganzes Migrationsprojekt.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz, es fallen keine Lizenzgebühren an. Geld kosten nur Entwicklung, Hosting und Betrieb – und Hosting ist bei rein statischer Auslieferung in der Regel günstiger als ein Plattform-Abo pro Site.

Standardmäßig nicht. Astro rendert die gesamte Website vorab und liefert statisches HTML aus, das auf gewöhnlichem Hosting oder einem CDN liegen kann. Erst Routen mit On-Demand-Rendering brauchen eine Laufzeitumgebung und einen passenden Adapter, etwa für Node, Vercel oder Cloudflare.

Die technische Grundlage ist gut: Server-First-Rendering, statisches HTML als Standard, eingebaute Bildoptimierung und volle Kontrolle über Metadaten, Sitemap und strukturierte Daten. Rankings entstehen davon allein nicht – die kommen aus Inhalt, Struktur und Verlinkung. Das Framework nimmt Ihnen nur die technischen Ausreden.

Astro ist ein quelloffenes Projekt, das öffentlich auf GitHub entwickelt wird – unter MIT-Lizenz, Copyright 2021 Fred K. Schott. Aktuell ist die Linie Astro 7. Das Projekt folgt Semantic Versioning und liefert Sicherheits-Fixes für genau eine vorherige Major-Version.