Website- & Anwendungsmigration in Dresden
Ich migriere Websites von WordPress, Joomla, Drupal, Angular, Vue und anderen Technologien zu Astro und Next.js. Jede Migration plane ich so, dass SEO, Inhalte und Funktionen erhalten bleiben, und schalte in einem vereinbarten Zeitfenster um. Ich arbeite allein und habe langjährige Erfahrung mit älteren und modernen Stacks.
- Mein wordpress.org-Konto besteht seit 2006.
- Ich habe zum WordPress-Core in den Versionen 7.0 und 7.1 beigetragen.
- Ich betreue 30 Plugins auf wordpress.org.
- Ich organisiere WordCamps und trete dort als Speaker auf.
- Ich war bei jedem WordCamp Europe von 2017 bis 2026 dabei.
- Lokales WordPress-Meetup: WordPress Meetup Dresden
Sie überlegen, Ihre WordPress-Website in Dresden auf Astro oder Next.js umzustellen, und fragen sich, ob sich das lohnt. Die ehrliche Antwort lautet manchmal nein. Ich bin Mariusz Szatkowski, arbeite allein und schriftlich aus Gdynia, mit WordPress seit 2006 und heute ebenso mit Astro und Next.js. Weil ich alle drei baue, kann ich Ihnen auch zu dem Weg raten, an dem am wenigsten zu tun ist.
Diese Seite behandelt die Frage vor jeder Migration: was zuerst gemessen wird, wann WordPress die bessere Antwort bleibt, wann Astro passt und wann Next.js.
Was messen Sie, bevor über ein Framework gesprochen wird?
Ein Gefühl, die Seite sei langsam, reicht als Grundlage nicht. Am Anfang stehen Felddaten, also Messungen bei echten Besuchern.
Der Chrome UX Report. Google beschreibt den CrUX-Bericht als Datensatz, der zeigt, wie echte Chrome-Nutzer populäre Ziele im Web erleben. Er ist der offizielle Datensatz des Web-Vitals-Programms und enthält alle Core Web Vitals. Laut Dokumentation der CrUX-API sind die Daten ein gleitender Durchschnitt über 28 Tage und werden täglich aktualisiert. Für Sie heißt das: Eine Änderung zeigt sich erst nach und nach, und ein Vergleich vorher und nachher braucht Geduld.
Wo Sie die Werte sehen. PageSpeed Insights zeigt zwei Bereiche. Der erste stammt aus dem CrUX-Bericht und beschreibt die Erfahrung echter Nutzer. Der zweite stammt aus Lighthouse, einem kontrollierten Test im Labor. Für die Entscheidung über eine Migration zählt der erste.
Die Schwellen. Nach web.dev gilt eine Erfahrung als gut bei LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1. Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgerät und Desktop. Eine Seite besteht, wenn alle drei Werte die Schwelle erreichen.
Wenn keine Felddaten erscheinen. Nicht jede Website ist im Datensatz. Laut CrUX-Dokumentation müssen Seiten und Ursprünge öffentlich auffindbar sein und eine Mindestzahl an Besuchern haben. Kleinere B2B-Seiten fallen oft durch dieses Raster. Dann bleiben Labordaten und eine eigene Messung. Web.dev weist darauf hin, dass Lighthouse INP nicht messen kann, weil es keine Nutzereingabe gibt. Total Blocking Time dient dort als Näherung.
Eigene Messung und Recht. Wer selbst bei Besuchern misst, prüft § 25 TDDDG. Danach ist das Speichern von Informationen auf dem Endgerät oder der Zugriff darauf nur mit Einwilligung zulässig, außer es ist für einen ausdrücklich gewünschten Dienst unbedingt erforderlich (gesetze-im-internet.de). Zuständige Aufsicht für Unternehmen in Sachsen ist die Sächsische Datenschutz- und Transparenzbeauftragte. Wie ein Messskript gebaut ist, entscheidet also mit darüber, ob es in Ihr Einwilligungsbanner gehört.
Geschwindigkeit ist nur eine von vier Fragen
Eine Migration verändert mehr als die Ladezeit. Bevor ich Ihnen etwas empfehle, kläre ich vier Bereiche schriftlich mit Ihnen.
| Frage | Was ich dafür von Ihnen brauche | Warum sie über den Weg entscheidet |
|---|---|---|
| Felddaten | Adresse der Website, Zugang zur Search Console, falls vorhanden | ohne Messung kein Vorher und Nachher |
| Redaktion | wer schreibt, wie oft, wer freigibt | ein Wechsel ins neue CMS kostet Einarbeitung |
| Schnittstellen | Formulare, CRM, Newsletter, Stellenportal, Shop, Anmeldung | jede Schnittstelle muss im neuen System neu entstehen |
| Betriebsaufwand | wer heute Updates einspielt, wo gehostet wird | ein Node.js-Server will gepflegt werden, ein Plugin-Bestand auch |
Die Redaktion unterschätzen viele. Wer seit Jahren im Blockeditor schreibt, verliert bei einem Wechsel Gewohnheiten, Rollen und Vorschau. Wie das nach einem Umzug aussieht, beschreibe ich auf der Seite zur Redaktion nach der Migration in Hannover. Den Betrieb nach dem Wechsel, also Abhängigkeiten, Node.js und Sicherheitsfreigaben, behandelt die Seite zur Wartung nach der Migration in Wuppertal.
Wann WordPress die bessere Antwort bleibt
WordPress bleibt die bessere Wahl, wenn die Messung zeigt, dass das Problem im Bestand liegt und nicht im System, und wenn Ihre Redaktion gut damit arbeitet.
Blockthemes statt alter Themes. Die WordPress-Entwicklerdokumentation nennt Blockthemes den modernen Weg, Themes zu bauen. Sie bestehen vollständig aus Blöcken, ihre Vorlagen sind HTML-Dateien mit Block-Markup, und Ersteller wie Nutzer bearbeiten sie im Website-Editor. Globale Einstellungen und Stile stehen in der Datei theme.json und lassen sich über die Stile-Oberfläche anpassen. Klassische Themes mit PHP-Vorlagen werden weiter unterstützt. Ein Wechsel von einem klassischen Theme mit Page-Builder zu einem Blocktheme ist ein Umbau innerhalb von WordPress: Inhalte, Benutzer und Rollen bleiben, wo sie sind.
Ein Detail, das ich vorher prüfe: Laut Dokumentation zu den Website-Editor-Vorlagen bleibt die Vorlagendatei des Themes unverändert, wenn jemand sie im Editor ändert. Die geänderte Fassung liegt als eigener Beitragstyp wp_template in der Datenbank. Wer ein Theme austauscht, muss diese Änderungen also kennen.
Weniger Plugins. Die Optimierungsseite der WordPress-Dokumentation nennt die Plugins als ersten und einfachsten Ansatz: unnötige deaktivieren und löschen, einzelne gezielt abschalten und die Serverleistung messen. Bremst ein bestimmtes Plugin, empfiehlt die Seite Dokumentation, Support-Forum oder eine Alternative mit ähnlichem Funktionsumfang.
Automatisch geladene Optionen. Plugins und Themes legen Einstellungen in der Tabelle wp_options ab, ein Teil davon wird bei jedem Seitenaufruf geladen. Dieselbe Seite rät, diese automatisch geladenen Optionen unter 800 KB zu halten, und erwähnt, dass ein persistenter Objekt-Cache das Laden beschleunigt. Auf älteren Installationen mit vielen ausprobierten und wieder entfernten Plugins finde ich hier häufig Reste.
Caching, Hosting, CDN. Die Dokumentation unterscheidet Shared Hosting, Managed Hosting und eigene Server, weil davon abhängt, welche Maßnahmen Sie überhaupt umsetzen können. Seiten-Caching, ein aktueller PHP-Stand mit Opcode-Cache und ein CDN für statische Dateien stehen dort als Hebel.
Das Performance-Team von WordPress. Das Core Performance Team arbeitet laut eigener Teamseite daran, die Leistung von WordPress und seinem Umfeld zu beobachten und zu verbessern. Es pflegt das Plugin Performance Lab, eine Sammlung von Funktions-Plugins, die später in den Kern wandern sollen, darunter Modern Image Formats, Speculative Loading und Image Prioritizer. Die Plugin-Seite bezeichnet es selbst im Wesentlichen als Beta-Test und weist auf das Risiko im Produktivbetrieb hin. Ich teste solche Funktionen deshalb auf einer Staging-Kopie und übernehme nur, was dort messbar hilft.
Wenn nach diesen Schritten die Felddaten stimmen und die Redaktion zufrieden ist, rate ich von einer Migration ab. Für diesen Weg gibt es die Seiten zur WordPress-Entwicklung in Dresden und zur WordPress-Wartung in Dresden.

Foto: Juri Kowski, CC BY-SA 3.0, Wikimedia Commons.
Wann Astro passt
Die Astro-Dokumentation beschreibt Astro als Framework für inhaltsgetriebene Websites: Marketing-Seiten, Blogs, Dokumentation, Portfolios, Landingpages und Shops. Es rendert so weit wie möglich auf dem Server und liefert standardmäßig kein JavaScript an den Browser. Interaktive Teile werden laut Dokumentation zu Inseln: Nur Komponenten mit einer client-Direktive bekommen JavaScript, etwa client:visible, das erst lädt, wenn die Komponente ins Bild kommt. Für personalisierte Elemente, die auf dem Server entstehen, gibt es Server-Inseln.
Astro passt, wenn diese Punkte zutreffen:
- Die Website zeigt vor allem Inhalte, und Interaktion beschränkt sich auf einzelne Elemente wie Formular, Suche oder Bildergalerie.
- Die Felddaten sind schlecht, und die Ursache liegt im mitgelieferten JavaScript von Theme und Page-Builder, nicht nur in einem einzelnen Plugin.
- Die Redaktion kann mit einem neuen CMS arbeiten, oder WordPress bleibt im Hintergrund als Headless-Backend.
- Die Inhalte lassen sich sauber aus WordPress holen. Wie der Export aussieht, steht auf der Seite zum WordPress-Export in Essen.
Astro passt schlecht, wenn der Kern der Website ein Kundenbereich mit vielen angemeldeten Funktionen ist. Dann lohnt der Blick auf Next.js.
Wann Next.js passt
Laut Next.js-Dokumentation ist Next.js ein React-Framework für Full-Stack-Webanwendungen. Es gibt zwei Router: den neueren App Router mit Server Components und den ursprünglichen Pages Router, der weiter unterstützt wird.
Für die Entscheidung zählt vor allem der Betrieb. Die Dokumentation zum Deployment nennt vier Wege: Node.js-Server und Docker-Container unterstützen alle Funktionen, der statische Export nur einen Teil, bei Adaptern hängt es von der Plattform ab. Der statische Export erzeugt pro Route eine HTML-Datei, unterstützt aber keine Weiterleitungen, keine Header, keine Cookies, keine inkrementelle statische Regeneration und keinen Draft Mode. Wer also Weiterleitungen aus der alten Website braucht, und das braucht fast jede Migration, regelt sie dann auf dem Webserver. Wie eine solche Liste entsteht, zeigt die Seite zu den Weiterleitungen in Bremen, die Betriebsarten im Detail die Seite zu Hosting und Datenstandort in Frankfurt.
Next.js passt, wenn diese Punkte zutreffen:
- Ein Teil der Website ist eine Anwendung: Kundenkonto, Konfigurator, Händlerbereich, Formulare mit Logik auf dem Server.
- Sie haben jemanden, der einen Node.js-Server oder eine Plattform mit passender Region betreibt, oder Sie beauftragen mich damit.
- React ist in Ihrem Haus bereits im Einsatz, und andere Entwickler sollen später weiterarbeiten können.
Für eine reine Unternehmensseite mit Leistungsbeschreibungen und Stellenangeboten ist Next.js meist mehr System, als die Aufgabe verlangt.
Was das für Unternehmen in Dresden heißt
Für kleinere Betriebe ist ein Detail aus der Wirtschaftsförderung der Stadt wichtig für die zeitliche Planung. Die Landeshauptstadt fördert nach eigener Darstellung Investitionen von Klein- und Kleinstunternehmen in zwei Gebieten, Johannstadt/Pirnaische Vorstadt und Dresden Südwest/Cottaer Bogen, mit Mitteln aus dem EFRE (Stand November 2026). Zu den Auswahlkriterien zählen unter anderem Barrierefreiheit und Innovation, und das Vorhaben darf vor der Bewilligung noch nicht begonnen sein, außer die Stadt hat einen vorzeitigen Beginn genehmigt. Ob ein Website-Projekt als investive Maßnahme zählt, entscheidet das Amt für Wirtschaftsförderung. Sitzt Ihr Betrieb in einem der Gebiete, fragen Sie dort, bevor Sie einen Auftrag erteilen, auch bei mir.
Barrierefreiheit gehört ohnehin in jede Entscheidung, gleich ob Sie bei WordPress bleiben oder wechseln. Was das Barrierefreiheitsstärkungsgesetz für eine Website bedeutet, beschreibt die Seite zum BFSG in Münster.
Checkliste vor der Entscheidung
- Zeigt PageSpeed Insights Felddaten für Ihre wichtigsten Seiten und für den Ursprung, getrennt nach Mobilgerät und Desktop?
- Welcher der drei Werte LCP, INP oder CLS verfehlt die Schwelle, und auf welchen Seitentypen?
- Wie viele Plugins sind aktiv, und welche davon braucht heute noch jemand?
- Wie groß sind die automatisch geladenen Optionen in wp_options?
- Läuft ein klassisches Theme mit Page-Builder, oder ist ein Blocktheme im Einsatz?
- Wer schreibt, wer gibt frei, und soll die Oberfläche gleich bleiben?
- Welche Schnittstellen hängen an der Website, und wer betreut sie?
- Wer übernimmt nach dem Start Updates und Betrieb?
Wenn Sie bei Frage 2 keine Antwort haben, ist die Entscheidung für ein neues Framework verfrüht.
So läuft die Entscheidung mit mir
Sie schicken mir die Adresse und Ihre Antworten auf die Checkliste, so weit Sie sie kennen. Ich lese die Felddaten, sehe mir Plugins, Theme und Hosting an, soweit Sie mir Zugang geben, und stelle Rückfragen schriftlich. Danach erhalten Sie eine schriftliche Empfehlung mit Begründung: bei WordPress bleiben und gezielt nachbessern, schrittweise wechseln wie auf der Seite zum Umzug in Etappen in Köln beschrieben, oder vollständig migrieren. Jede Variante bekommt einen Umfang mit Annahmen. Arbeiten laufen auf einer Staging-Umgebung, und die Abnahme machen Sie, bevor etwas live geht. Gestaltung, Mockups und Wireframes kommen von Ihnen, ich setze sie um. Eine Übersicht über den gesamten Ablauf einer Migration finden Sie auf der Seite zur Migration zu Next.js und Astro.
Häufige Fragen
Meine Website ist langsam. Muss ich dafür WordPress verlassen? Nicht unbedingt. Ich prüfe zuerst die Felddaten und die Ursache. Die WordPress-Dokumentation nennt Plugins, Caching, Hosting und automatisch geladene Optionen als typische Stellen. Liegt das Problem dort, ist es in WordPress lösbar, ohne dass Redaktion und Inhalte umziehen.
Was mache ich, wenn PageSpeed Insights keine Felddaten zeigt? Dann ist Ihre Seite oder Ihr Ursprung nicht im Chrome UX Report, weil sie nicht öffentlich auffindbar oder nicht ausreichend besucht ist. In dem Fall bleiben Labordaten aus Lighthouse und eine eigene Messung bei echten Besuchern, für die § 25 TDDDG gilt, sobald sie Informationen auf dem Gerät speichert oder dort ausliest.
Reicht ein guter Lighthouse-Wert als Begründung für eine Migration? Nein. Lighthouse misst im Labor ohne echte Nutzer und kann INP nicht erfassen. Web.dev nennt Labormessung wichtig, aber keinen Ersatz für Felddaten. Ich vergleiche deshalb die Werte aus dem CrUX-Bericht vor und nach jeder Änderung.
Wann empfehlen Sie Astro statt Next.js? Wenn die Website vor allem Inhalte zeigt: Leistungsseiten, Referenzen, Stellenangebote, Dokumentation. Next.js empfehle ich, wenn Anmeldung, personalisierte Bereiche oder viele serverseitige Abläufe den Kern bilden und Sie einen Node.js-Server oder eine passende Plattform betreiben wollen.
Kann ich erst WordPress optimieren und später migrieren? Ja, und oft ist das die vernünftige Reihenfolge. Aufgeräumte Plugins, saubere Inhalte und eine Liste der Schnittstellen helfen auch bei einer späteren Migration. Ein Umzug in Etappen ist ebenfalls möglich.
Wie bekomme ich eine Einschätzung von Ihnen? Sie schicken mir Adresse, Ziel, Termin und den heutigen Aufbau schriftlich. Ich antworte schriftlich mit einer Empfehlung, die auch lauten kann, bei WordPress zu bleiben. Die erste Einschätzung ist kostenlos.
Schreiben Sie mir, bevor Sie sich festlegen
Wenn Sie in Dresden vor der Frage stehen, ob Ihre Website umziehen soll, schicken Sie mir über das Kontaktformular die Adresse, Ihr Ziel, einen gewünschten Termin und was heute läuft: Theme, wichtige Plugins, Hosting und angebundene Systeme. Ein Screenshot aus PageSpeed Insights hilft, ist aber keine Voraussetzung. Sie bekommen von mir eine schriftliche Ersteinschätzung ohne Kosten, und wenn die Antwort lautet, dass WordPress mit weniger Ballast reicht, steht genau das darin.
Ausgewählte Projekte
Beispiele aus meiner Arbeit.
E-Commerce-Entwicklung: estel-poland.com
estel-poland.com ist ein professioneller Onlineshop für Kosmetik, der für Kunden entwickelt wurde, die hochwertige Pflege- und Make-up-Produkte suchen. Die P...
E-Commerce-Entwicklung: floresy.online
Floresy.online ist eine Website, die für Floresy, den führenden Hersteller, Großhändler und Einzelhändler von künstlichen Pflanzen, Blumen und Bäumen, erst...
E-Commerce-Entwicklung: funderwear.pt
Funderwear.pt ist ein WooCommerce-Onlineshop, der selbst die anspruchsvollsten Kunden bedient, jene, die außergewöhnliche Geschenke suchen oder sich mit ein...
WordPress Support & Entwicklung in Dresden
Brauchen Sie die Leistung: Migration zu Next.js / Astro in Dresden?
Beschreiben Sie Ihr Projekt per E-Mail. Antwort innerhalb von 48 Stunden.
Projekt beschreibenWeitere WordPress-Dienste und Wissensbasis entdecken
Migration zu Astro, Next.js und Headless WordPress.
WooCommerce-Synchronisierung mit ERP und Großhandel.
Geschäftsprozessautomatisierung rund um WordPress und Firmensysteme.
Bibliothek konkreter Automatisierungsfälle.
Headless WordPress, Sanity, Strapi und Contentful mit Astro oder Next.js.
Astro, MDX, Edge Delivery und an echtem Traffic gemessene Core Web Vitals.
Individuelle WordPress-Entwicklung und Architektur.
Skalierbare Headless-, ERP- und KI-Architektur für Enterprise.
Verwandte Kategorien
Unterstützende Artikel

Sechs bis sechzehn Wochen für typische Projekte, in vier Phasen: Analyse, Scoping, Build und Umstellung, Tuning. Die Variablen sind Katalogumfang, Anzahl der Integrationen, URL-Erhalt und die Bereitschaft des Redaktionsteams, nicht die Wahl des Frameworks.

Umfassende 4-Jahres-TCO-Analyse (Total Cost of Ownership), reale Core-Web-Vitals-Benchmarks, Astro 7 GraphQL APQ-Architektur und eine 10-Punkte-Entscheidungsmatrix für Enterprise-Entscheider zwischen entkoppeltem und traditionellem WordPress.

Die Entscheidung Shopify Plus vs WooCommerce headless im Jahr 2026 ist kein binärer "Plattform vs Custom"-Kompromiss mehr. Beide laufen headless, beide integrieren KI, beide liefern am Edge aus. Die echten Achsen sind Kontrolle, Gesamtkosten über fünf Jahre und Exit-Strategie. Dieser Artikel durchläuft die Entscheidungsmatrix mit bestätigten Plattformfakten.