[ WORDPRESS → NUXT ]
Weg von WordPress. Behaltet, was es euch eingebracht hat.
Das Schwierige war nie das Framework. Es ist der Umzug, ohne die Inhalte einzufrieren und ohne auf halbem Weg steckenzubleiben.
- jede indexierte URL abgebildet
- alte Site als Netz live
- kein Redaktions-Freeze
- Rollback per Klick
- Fixpreis nach dem Audit
- EU-Data-Residency
Pflege
Was man spürt, sind die Unterbrechungen, nicht die Rechnung
Eine WordPress-Site wird nicht auf einen Schlag teuer. Sie wird teuer, weil jemand ungefähr einmal im Monat aufhören muss, woran er gerade arbeitet, um Dinge zu aktualisieren, die niemand ausgesucht hat — und weil jede dieser Runden die Site eines Kunden zerlegen kann, der auf etwas anderes wartet.
WordPress
12Update-Runden pro Jahr
- Plugins erscheinen nach ihrem Kalender, nicht nach eurem
- Getestet in Produktion – oder auf einem Staging, das jemand pflegen muss
- Rollback heisst: Datenbank zurückspielen
- Ein PHP-Sprung kann ein Plugin stranden lassen, von dem die Site abhängt
Nuxt oder Elysia + JAMflow
2–4Update-Runden pro Jahr
- Weniger bewegliche Teile, und kein Plugin, das ihr nicht gewählt habt
- Auf einem Branch mit eigener Preview getestet, bevor etwas live geht
- Rollback ist das vorherige Deploy — und ihr drückt den Knopf
- Das Upgrade-Plugin patcht das Mechanische und markiert den Rest
Das sind unsere Zahlen, keine Studie. Eine WordPress-Site mit einem Dutzend Plugins verlangt etwa monatlich Aufmerksamkeit, weil jedes Plugin nach seinem eigenen Kalender erscheint. Ein Nuxt- oder Elysia-Projekt auf diesem Stack alle drei bis sechs Monate, und den mechanischen Teil jeder Runde übernimmt das Upgrade-Plugin. Eure Zahlen werden abweichen — das Audit sagt, um wie viel.
Drei Schritte — und nach dem ersten dürft ihr aufhören
Das Audit ist ein Ergebnis, kein Verkaufsgespräch. Ihr bekommt einen schriftlichen Plan mit Kosten und Zeit, und der gehört euch, ob der Rest passiert oder nicht — genau das macht danach einen Fixpreis überhaupt möglich.
Audit
Wir lesen die Site von vorne bis hinten — Plugins, Content-Modell, Integrationen, indexierte URLs, was in Produktion tatsächlich kaputtgeht. Heraus kommt ein schriftlicher Plan mit Kosten- und Zeitschätzung und ein Umfang, der präzise genug ist, um ihn zu bepreisen.
- eine Site, keine Verpflichtung
- Inventar von Plugins, Content und URLs
- schriftlicher Plan + Fixpreis-Umfang
Traffic
Beim Umzug geht keine URL verloren
Das ist der Einwand, an dem die meisten WordPress-Migrationen scheitern, und er verdient eine echte Antwort statt einer Beruhigung. Alles, was die Suchmaschinen über die Site wissen, wird inventarisiert, bevor eine einzige Seite live geht — und wir belegen es mit einem Crawl der neuen Site gegen die alte.
- Die Map kommt zuerst, nicht zuletzt
- Jede indexierte Adresse bekommt ein Ziel, bevor irgendetwas gebaut wird. Redirects gehen mit dem Code live und lassen sich damit reviewen, testen und zurücknehmen wie alles andere auch.
- Ein Crawl-Vergleich, den ihr dem Kunden weiterleiten könnt
- Die neue Site wird gecrawlt und mit der alten verglichen — Statuscodes, Canonicals, Titel, strukturierte Daten. Wenn sich etwas bewegt hat, das nicht sollte, steht es in einem Dokument und nicht in den Analytics des nächsten Monats.
- Die alte Site bleibt, bis die Kurve flach ist
- Nach dem Go-live liefert WordPress hinter dem Proxy weiter aus. Sackt die Traffic-Kurve dort ab, wo sie nicht sollte, ist der Rückweg eine Konfigurationsänderung und kein Neuaufbau.
Was am Ende dasteht
Ein Standard-Nuxt-Projekt, nicht etwas, das nur wir betreiben können
Der Sinn des Umzugs ist nicht das Framework — es ist, dass die Site danach lesbar, testbar und umkehrbar ist und niemand mehr mit einem Plugin verhandeln muss, das er nicht geschrieben hat.
- Nichts Proprietäres im Weg
- Schlichtes Nuxt auf Nitro. Jede Nuxt-Entwicklerin kann es übernehmen, und es deployt überall dorthin, wohin Nitro deployt — auch irgendwohin, wo nicht wir sind.
- Inhalte in git, Redaktion dort, wo sie hingehört
- Texte und Medien sind mit dem Code versioniert, und wer publiziert, behält einen Editor. Welcher Editor, hängt davon ab, wer publiziert — das ist eine Entscheidung pro Projekt, keine fürs Leben.
- Rollback ist ein Klick, und zwar eurer
- Deploys sind atomar. Zurückgehen heisst, auf den vorherigen Build zu zeigen — nicht, um zwei Uhr nachts eine Datenbank zurückzuspielen.
- Schnell, weil weniger da ist
- Kein Plugin-Stack, der bei jedem Request mitläuft. Seiten werden vorgerendert, wo es geht, und was nicht geht, läuft auf Infrastruktur, deren Rechnung ihr sehen könnt.
Was es kostet
Das Audit ist gratis. Das Projekt ist ein Fixpreis. Das Hosting steht auf der Preisliste.
Man sollte keinen Call buchen müssen, um zu erfahren, was etwas kostet. Das Audit kostet nichts und der Plan bleibt euch. Das Projekt wird zum Fixpreis angeboten, sobald das Audit gesagt hat, was tatsächlich in der Site steckt — genau dafür gibt es das Audit.
Zur Preisliste →- Audit — kostenlos
- Eine Site, von vorne bis hinten gelesen. Ihr bekommt einen schriftlichen Plan mit Kosten- und Zeitschätzung, und der bleibt euch, ob wir zusammenarbeiten oder nicht.
- Migration — Fixpreis, angeboten nach dem Audit
- Keine Stundenschätzung, die davonläuft. Erst das Audit macht einen Fixpreis möglich, weil wir dann wissen, wie viele Templates, wie viele Integrationen und wie viel Content tatsächlich umziehen.
- Hosting — nutzungsbasiert, CHF 0.01 pro RU-Stunde
- Compute wird pro Resource Unit und Stunde abgerechnet, Storage pro GB, Egress pro GB nach Zone. Veröffentlichte Sätze, dieselben wie auf der Preisseite. Eine Site mit weniger Traffic im August kostet im August weniger.
- Nicht enthalten
- Lizenzen Dritter, die das Projekt braucht, eure Domains und Postfächer, und das Schreiben der Inhalte. Wir sagen es vorher, damit nichts als Überraschungsposten ankommt.
Häufige Fragen
Die Fragen aus dem ersten Call, hier beantwortet — damit der erste Call von eurer Site handeln kann.
Fragt uns etwas anderes →Wie lange dauert es?
Für eine Marketing-Site mit rund 40 Seiten, fünf Templates und ein paar Formularen: fünf bis sieben Wochen vom Kickoff bis zum Go-live, Redirects inklusive. Kommt ein Shop, ein geschützter Bereich oder eine massgeschneiderte Integration dazu, seid ihr bei drei bis fünf Monaten. Das Audit sagt, welcher Fall ihr seid, bevor ihr euch auf irgendetwas festlegt.
Wie viel Ausfall gibt es?
Keinen, den eine Besucherin sieht. WordPress liefert bis zum Umschalten aus und bleibt danach hinter dem Proxy erreichbar — der Wechsel ist damit eine Routing-Änderung und kein Fenster mit ausgeschaltetem Licht.
Was ersetzt das WordPress-Backend für die Leute, die publizieren?
Das hängt davon ab, wer publiziert. Ein Marketing-Team, das Seiten visuell bearbeiten will, bekommt Nuxt Studio; ein Projekt, bei dem Datenmodell und Freigabeprozess das Schwierige sind, bekommt Payload; Inhalte, die wirklich strukturierte Daten sind, können direkt in Postgres liegen. Das Nuxt-Frontend ist hinter allen dreien dasselbe — das ist also eine Entscheidung pro Projekt und keine endgültige.
Können wir WordPress für einen Teil der Site behalten?
Ja, und für vorsichtige Kunden ist das ein häufiger erster Schritt. WordPress kann als headless Content-Quelle für einen Bereich bleiben — meist der Blog — während alles andere auf Nuxt läuft. Auch diese Entscheidung muss nicht endgültig sein.
Was müssen wir tun, während es läuft?
Fragen zu den Teilen der Site beantworten, die nie jemand dokumentiert hat, und die Dinge entscheiden, die euch zustehen. Eine Entwicklerin oder einen Entwickler braucht ihr nicht: Wenn ihr nur das Design habt, gebt uns das Figma und wir bauen es. Habt ihr Entwickler und wollt sie im Repository, sind sie ab Tag eins willkommen — so bleibt das Wissen bei euch.
Wer macht die Arbeit tatsächlich?
Wir — und wir sind auch die Cloud, auf der es danach läuft; es gibt also keinen Dritten zu koordinieren, wenn etwas zu reparieren ist. Wenn ihr über eine Agentur hierhergekommen seid, bleiben Projekt und Beziehung bei ihr und wir stehen dahinter.
Wenn ihr eine Agentur seid
Ihr habt eine Flotte, keine Site
Sobald es mehr als eine ist, ändert sich die Rechnung. Eine gemeinsame Basis statt zehn Codebases, ein Patch statt zehn Nachmittagen, und eine Zusammenarbeit, die die Kundenbeziehung dort lässt, wo sie ist.
Wie wir mit Agenturen arbeiten →Wenn es eure eigene Site ist
Schickt uns die, die weh tut
Es braucht keine Agentur dazwischen. Wir lesen die Site, schreiben den Plan, machen den Umzug und betreiben danach das Hosting — und den Plan dürft ihr auch anderswohin mitnehmen.
Erzählt uns von der Site →Schickt uns eine WordPress-Site.
Nehmt die, die euch am meisten Zeit kostet. Wir lesen sie von vorne bis hinten und schicken einen Migrationsplan mit Kosten- und Zeitschätzung zurück — kostenlos, und er bleibt euch, ob ihr mit uns arbeitet oder nicht.