Das VTEX-Frontend-Trilemma: IO behalten, zu FastStore migrieren oder entkoppeln

VTEX-Kunden, die nach DACH und in den weiteren EU-Markt expandieren, stoßen irgendwann auf dieselbe Weggabelung beim Frontend. VTEX IO und Store Framework, das ursprüngliche proprietäre Tooling der Plattform, betreiben nach wie vor einen großen Teil der laufenden Storefronts. FastStore, die aktuelle Jamstack-Empfehlung von VTEX, ist die eigene Antwort der Plattform darauf, wohin sich das Frontend als Nächstes entwickeln soll. Und immer mehr Teams wählen einen dritten Weg: das Frontend vollständig vom VTEX-Frontend-Tooling zu entkoppeln, während VTEX als Commerce-Backend bestehen bleibt.

Keine der drei Optionen ist abstrakt betrachtet falsch. Jede ist unter bestimmten Voraussetzungen die richtige Wahl. Dieser Entscheidungsguide hilft dabei herauszufinden, welche Voraussetzungen bei euch zutreffen, mit einem konkreten Blick darauf, was sich ändert, wenn euer Betrieb in der EU sitzt, insbesondere in DACH: Hosting, Datenresidenz, Barrierefreiheitsrecht und die Realität des lokalen Talentmarkts.

Warum es diese Wahl überhaupt gibt

VTEX hat mehr als eine Frontend-Generation ausgerollt, ohne die vorherige vollständig abzulösen. VTEX IO mit Store Framework ist die ursprüngliche Architektur: eine proprietäre Entwicklungssprache und ein Komponentenmodell, gebaut speziell für das VTEX-Ökosystem. Es funktioniert, und eine große installierte Basis läuft damit, aber es ist nichts, was ein durchschnittlicher React- oder Vue-Entwickler in einer Woche lernt. FastStore ist das neuere, auf Next.js basierende Jamstack-Toolkit, das VTEX jetzt für neue Builds empfiehlt, mit einer CMS-First-Architektur. Es ist technisch konventioneller als IO, aber die Migration von einer bestehenden IO-Storefront dorthin ist keine Konfigurationsänderung, sondern ein Frontend-Rewrite. Dazu kommt: Bestimmte Content- und CMS-Funktionen funktionieren weiterhin nur sauber im klassischen CMS von VTEX, was Workaround-Brücken wie das „Gift List App"-Muster zwischen altem und neuem Stack erzeugt.

Ein VTEX-Kunde mit nennenswerter Frontend-Investition auf IO wählt also nicht zwischen „modern" und „veraltet". Er wählt zwischen drei realen Trade-offs, jeder mit eigenen Kosten.

Option 1: VTEX IO und Store Framework behalten

Bei IO zu bleiben vermeidet einen Rewrite. Das ist das ehrliche Argument dafür, und für manche Organisationen reicht das. Wenn eure Storefront stabil läuft, eure Roadmap fürs nächste Jahr backend-fokussiert ist und ihr nicht täglich gegen euer Frontend kämpft, gibt es keinen zwingenden Grund zu wechseln.

Die Kosten zeigen sich über Zeit, nicht sofort. Die proprietäre Sprache von IO bedeutet einen engen Recruiting-Pool, und in DACH speziell ist dieser dünn. Die Frontend-Spezialisten von VTEX konzentrieren sich auf den LatAm-Markt; IO-erfahrene Entwickler in Deutschland, Österreich oder der Schweiz zu finden, ist eine langwierige, teure Suche im Vergleich zur Einstellung für einen Standard-Stack. Jede IO-spezifische Anpassung wird schwerer zu besetzen, zu dokumentieren und bei Teamwechseln zu übergeben. Und ihr übernehmt die eigene Plattformrichtung von VTEX: IO ist nicht dort, wo neue Frontend-Investitionen von VTEX hinfließen, daher wird die Lücke zwischen dem, was IO unterstützt, und den neueren Plattform-Fähigkeiten wahrscheinlich eher wachsen als sich schließen.

Option 2: Migration zu FastStore

FastStore ist die technisch sauberere Option, und das sollte man klar so benennen. Next.js, ein CMS-First-Content-Modell und moderne Jamstack-Konventionen machen es zu einem wartungsfreundlicheren Ziel als IO, für Teams, die im VTEX-Frontend-Ökosystem bleiben wollen.

Der Trade-off ist, dass die Migration zu FastStore kein Upgrade im Sinne eines Plattform-Versionssprungs ist. Es ist ein Frontend-Replatforming: neue Komponentenarchitektur, eine neue Build-Pipeline und ein CMS-First-Content-Modell, das euer Team lernen und befüllen muss. Budgetiert und plant das genauso wie jeden Frontend-Rewrite, denn genau das ist es, auch wenn das Backend dabei nicht bewegt wird. Für EU-Betriebe löst die FastStore-Migration allein auch nicht die beiden Probleme, die typischerweise DACH-spezifisch sind: EU-Hosting-Konfiguration und native Integration in den EU-Marketing-Stack (Consent-Management, EU-basiertes Analytics, EU-gehostete Personalisierungstools) müssen bewusst in das FastStore-Setup eingebaut werden. Das ist kein automatisches Ergebnis des Wegs von IO.

Option 3: Frontend per GraphQL entkoppeln

Der dritte Weg lässt VTEX genau dort, wo es stark ist, als Commerce-Backend, und ersetzt die Frontend-Ebene vollständig, indem er sich an die GraphQL-API von VTEX anbindet statt auf IO oder FastStore zu bauen. Das ist die Option, für die wir bauen. Eine Composable Frontend Management Platform setzt sich auf die Standard-GraphQL-Schnittstelle von VTEX, sodass es keine VTEX-spezifische Frontend-Sprache gibt, für die rekrutiert werden muss, und keinen FastStore-artigen Rewrite, der eingeplant werden muss.

Für einen DACH- oder EU-Betrieb bringt dieser Weg genau die Punkte nach vorn, die Option 1 und 2 als Nachgedanke behandeln. EU-Hosting ist eine Konfigurationsentscheidung, kein Nachrüsten. BFSG-Barrierefreiheit, die deutsche Umsetzung des European Accessibility Act, ist in die Komponenten-Ebene eingebaut statt als separater Audit-Sprint an eine FastStore-Migration angehängt zu werden. Standard-Connectoren zum EU-Marketing-Stack, Tools wie Klaviyo, Cookiebot und Algolia, funktionieren ohne den Custom-Glue-Code, den der eher LatAm-orientierte App Store von VTEX sonst erfordert. Beim Recruiting verschiebt sich der Fokus von einer engen IO- oder FastStore-Spezialistensuche zu einem Standard-Vue- oder Nuxt-Talentpool, der in DACH deutlich breiter ist.

Das Backend bleibt VTEX. Das Frontend wird unabhängig davon, auf welcher VTEX-Frontend-Generation ihr zuvor gestanden habt.

Der Entscheidungsrahmen

Die drei Optionen beantworten drei unterschiedliche Fragen, und welche für euch richtig ist, hängt davon ab, welche Frage in eurer Organisation gerade tatsächlich akut ist.

Die EU-/DACH-spezifischen Variablen, die bei dieser Entscheidung stark einfließen sollten, unabhängig davon, zu welcher Option ihr tendiert: ob eure Kundendaten aus Compliance-Gründen in einer EU-Region bleiben müssen, ob ihr VTEX-spezifische Frontend-Skills realistisch lokal besetzen könnt, und ob eure Barrierefreiheitspflichten unter dem BFSG gegen euer aktuelles Frontend schon abgeglichen sind oder noch offen stehen.

Wie Entkopplung in der Praxis aussieht

Der Wechsel zu einem entkoppelten Frontend auf VTEX erfordert keinerlei Eingriff ins Backend. In der Praxis läuft die Sequenz so ab: Audit des aktuellen Frontends (IO, FastStore oder eine Mischung) und des GraphQL-Schemas; Anbindung der Frontend-Ebene an die GraphQL-API von VTEX mit Feld-Mapping für eure Produkt- und Account-Struktur; Übertragung bestehender Komponenten in eine Komponenten-Bibliothek mit euren Brand-Tokens und einem BFSG-Barrierefreiheits-Check; Aktivierung von EU-Marketing-Stack-Connectoren (Consent, Analytics, Personalisierung, Suche); und ein Umschalten Land für Land oder Marke für Marke vor dem vollständigen Cutover. Für ein Single-Country-Setup dauert das typischerweise Wochen mit Founder-Begleitung; Multi-Country-Enterprise-Rollouts, vergleichbar mit einer großen europäischen Handelsgruppe, die VTEX über mehrere Märkte betreibt, skalieren auf etwa zwei bis drei Monate.

Eine Anmerkung zu VTEX' eigenem Agentic-Tooling

VTEX hat im April 2026 einen MCP-Server für das WebOps-Tooling von FastStore ausgeliefert, gedacht für agentengestützte Frontend-Operationen innerhalb des FastStore-Stacks. Das ist eine echte Fähigkeit, ändert aber nichts am zugrunde liegenden Trilemma. Es ist ein Feature des FastStore-Wegs, keine vierte Option, und es adressiert nicht die DACH-Recruiting- oder EU-Compliance-Fragen, die die meisten Entkopplungsentscheidungen überhaupt erst antreiben.

FAQ

Bedeutet Entkopplung, VTEX zu verlassen? Nein. VTEX bleibt als Commerce-Backend bestehen. Nur die Frontend-Ebene ändert sich, sie bindet sich an die GraphQL-API von VTEX an, statt auf IO oder FastStore zu bauen.

Ist eine FastStore-Migration manchmal die richtige Wahl gegenüber Entkopplung? Ja, wenn euer Team langfristig auf das VTEX-Frontend-Ökosystem festgelegt ist und eure EU-Compliance- und Hosting-Anforderungen bereits separat gelöst sind. FastStore ist ein legitimes Ziel, nur keine Abkürzung um einen Rewrite herum.

Wie lange dauert eine VTEX-Frontend-Entkopplung? Der Median für ein Single-Country-Setup mit Founder-Begleitung liegt bei unter zwei Wochen für das initiale Setup, mit vollständigem Soft-Launch und Cutover typischerweise abgeschlossen innerhalb von sechs bis vierzehn Wochen, je nach Umfang. Multi-Country-Enterprise-Rollouts skalieren davon ausgehend.

Mehr zu unserem Headless Frontend für VTEX, seht euch an, wie sich der Ansatz vergleicht in FastStore vs. Laioutr für VTEX, oder stöbert im Laioutr Insights Blog für mehr zu unserer Agentic Frontend Management Platform und unserem Composable Headless Frontend-Ansatz.