Metro Boutique und die ehrliche Rechnung hinter dem Migrationsentscheid

Metro Boutique betreibt 25 Filialen in der Schweiz und spricht eine Zielgruppe zwischen 16 und 34 Jahren an. Der Online-Shop funktionierte – aber eben nur das.

Das NopCommerce-System aus dem Jahr 2015 verursachte CHF 250’000 pro Jahr allein für Wartung. Jede Inhaltsänderung brauchte Developer-Einsatz, Black Friday-Kampagnen mussten manuell um Mitternacht aktiviert werden, Scheduling existierte nicht.

Der primäre Treiber war wirtschaftlicher Natur: Die Plattformkosten machten es zunehmend schwieriger, profitabel zu bleiben.

Phase 0: Erst der Business Case, dann die Migration

what. startete nicht mit Entwicklung, sondern mit einem strukturierten Store Check & Migration Assessment. Ziel war es, datenbasiert zu klären, ob eine Migration zu Shopify überhaupt Sinn ergibt – und wenn ja, wie.

Das Assessment lieferte konkrete Zahlen:

• 55% TCO-Einsparung über 5 Jahre
• CHF 2 Mio. projizierte Einsparung über denselben Zeitraum
• 9 Millionen URLs im bestehenden Shop – davon nur 88’000 indexiert
• 1.04% Conversion Rate als Ausgangswert

Dieser Business Case war intern vertretbar. Das Management konnte die Entscheidung mit echten Zahlen begründen, nicht mit Bauchgefühl.

Eine weitere Erkenntnis aus dem Assessment: Das starke Branding von Metro Boutique lebte primär in den Filialen. Online wurde die Marke gedämpft. «Same brand, different decibels.»

Die Systemlandschaft vor und nach der Migration

Die drei grössten technischen Herausforderungen – und wie what. sie gelöst hat

Komplexe Systemlandschaften haben immer Stellen, die auf dem Papier simpel aussehen und in der Realität es nicht sind. Bei Metro Boutique gab es drei davon.

Akeneo-Connector

Der bestehende Connector war für die spezifische Datenstruktur von Metro Boutique nicht ausreichend. Der Vendor reagierte langsam, die Anpassungsbereitschaft war gering. what. entwickelte einen eigenen Connector – sauber, wartbar, auf die tatsächlichen Anforderungen zugeschnitten.

Das ist eine Situation, die häufiger vorkommt, als man denkt: Off-the-shelf-Lösungen passen selten zu 100 %. Der Unterschied liegt darin, ob man bereit ist, das anzupacken.

Physische Geschenkkarten als Payment Method

Giftcards machen rund 4 % des Online-Umsatzes aus. Shopifys natives Gift Card System ist für physische Filialkarten nicht ausgelegt.

what. entwickelte eine vollständig custom implementierte Payment Method, die den Kartensaldo über den externen Payment Provider MF Group validiert. Das klingt nach einem Detail – aber 4 % Umsatz, die man einfach wegfallen lässt, wäre keine Option gewesen.

Wichtig anzumerken ist, dass der alte Shop bereits über diese Funktion verfügte; unsere Custom-Entwicklung schloss bloss die Lücke auf Shopify-Seite.

App-Wishlist-Synchronisation

Die ursprünglich evaluierte Drittlösung verursachte Synchronisationsprobleme. what. entwickelt aktuell ein eigenes Script. Dieser Punkt ist noch in Umsetzung – und das wird hier bewusst transparent kommuniziert, weil es zum Projektstand gehört.

Timeline: Von Offerte bis Go-Live

Geplanter Launch war Oktober 2025. Tatsächlicher Go-Live: Mitte Januar 2026 – rund 7 Monate nach Projektstart.

Beim Go-Live gab es keine Downtime, keinen Datenverlust, und alle kritischen Integrationen funktionierten einwandfrei.

Das Timing wurde nach hinten verschoben, weil die Qualität der Integrationen Vorrang hatte. Das ist die richtige Entscheidung – ein Go-Live mit offenen kritischen Punkten schafft mehr Probleme als er löst.

Was sich seit dem Launch verändert hat

Denis Spycher von Metro Boutique bringt es auf den Punkt:

«Intern stand bereits seit längerer Zeit die Überlegung im Raum, unser Shop-System zu wechseln – vor allem aufgrund der hohen Fixkosten und der eingeschränkten Flexibilität. Schon ab Tag 1 hatte ich ein sehr gutes Gefühl: Die Zusammenarbeit war effizient, zielorientiert und gleichzeitig angenehm. Mit Shopify haben wir heute deutlich mehr Flexibilität, eine bessere Effizienz im Tagesgeschäft und ein CMS, das schnell, verständlich und einfach zu bedienen ist.»

Die Conversion Rate stieg von 1.04% auf 1.08% in den ersten 90 Tagen. Das klingt nach einer kleinen Zahl, aber auf dem Volumen eines nationalen Fashion-Retailers ist das spürbar.

Was sich qualitativ verändert hat, ist mindestens genauso relevant:

• Das E-Commerce Team kann eigenständig Kampagnen aufschalten – ohne Developer
• 95% der Content-Änderungen werden selbstständig umgesetzt
• Zeitgesteuertes Kampagnen-Scheduling ohne manuelles Aktivieren ist jetzt möglich (muss noch implementiert werden)
• Die Basis für Personalisation, A/B-Testing und SEO-Optimierung ist gelegt
• UX / UI verbessert
• Kostenstruktur nachhaltig verbessert

Und zum Arbeitsalltag des Teams:

«Seit dem Go-Live haben wir deutlich mehr Freiheit und können viel proaktiver agieren. Für viele Themen sind wir nicht mehr auf externe Unterstützung angewiesen, sondern können selbst direkt eingreifen, den Shop optimieren und neue Ideen schnell testen. Ich bin überzeugt, dass Shopify Plus für uns die richtige Entscheidung war.»

Die Plattformkosten liegen heute bei etwa einem Viertel der früheren Ausgaben.

Der vollständige Technologie-Stack

*Der alte Shop verfügte bereits über diese Funktion; unsere Custom-Entwicklung schloss bloss die Lücke auf Shopify-Seite.

Was dieses Projekt über den richtigen Migrationsansatz sagt

Migrations-Projekte scheitern häufig nicht an der Technologie, sondern daran, dass zu früh mit der Umsetzung begonnen wird, ohne den Business Case zu verstehen.

Das Assessment zuerst war kein netter Zusatz – es war die Grundlage dafür, dass Metro Boutique intern die Entscheidung treffen und vertreten konnte. Erst verstehen, dann entscheiden, dann bauen.

Und wenn ein bestehender Vendor-Connector nicht funktioniert, baut what. eben einen eigenen. Das ist kein Sonderfall, sondern ein Prinzip: Komplexe Systemlandschaften brauchen Lösungen, die wirklich passen.

Planst du eine ähnliche Migration?

Wenn deine Plattformkosten zu hoch sind, dein Team für jede Änderung auf Developer angewiesen ist oder du weisst, dass dein System dich zurückhält – dann ist der erste Schritt ein ehrlicher Blick auf den Status quo.

Genau das bieten unsere Shopify Migration Services an: vom initialen Assessment über die technische Umsetzung bis zum Go-Live und darüber hinaus. Als führende Shopify Plus Agentur der Schweiz mit über 200 realisierten Shops wissen wir, wo die echten Herausforderungen liegen – und wie man sie löst.

The post Von NopCommerce zu Shopify Plus: Wie what. Metro Boutique in die E-Commerce-Zukunft führte appeared first on what. AG.

Wer ist Schweizer Päckli und wo kamen wir ins Spiel?

Schweizer Päckli schafft etwas, das schwieriger ist, als es klingt: Sie verkaufen sorgfältig kuratierte Pakete mit authentischen regionalen Schweizer Spezialitäten – die sich anfühlen wie ein echtes Geschenk, nicht wie eine x-beliebige Online-Bestellung.

Jedes «Päckli» wird mit viel Bedacht zusammengestellt, um dem Empfänger ein Stück einer bestimmten Schweizer Region näherzubringen. Der Inhalt ist nicht generisch, sondern mit echtem Gespür für regionale Herkunft ausgewählt – genau das verleiht dem Produkt seinen Charakter. Für jemanden, der etwas Bedeutungsvolles verschicken möchte, macht genau diese Besonderheit den Unterschied.

Mitte 2023 zeigte die technische Grundlage, die all das zusammenhielt, erste Alterserscheinungen. Wir von what. haben die vollständige Plattformmigration übernommen und Schweizer Päckli von OctoberCMS auf Laravel und Vue 3 umgestellt – mit Laravel Nova als Backend. Das Projekt wurde Anfang 2024 abgeschlossen.

Warum eine vollständige Migration sinnvoller war als das Flicken des alten Systems

OctoberCMS hatte seinen Zweck erfüllt. Aber die Einschränkungen hatten sich so weit angehäuft, dass es nicht mehr realistisch war, sie zu umgehen.

Neue Features hinzuzufügen war kaum möglich. Die Abhängigkeit von CMS-Plugins bedeutete wenig Kontrolle über die zugrunde liegenden Datenstrukturen. Und die Skalierung auf neue Regionen – ein echtes strategisches Ziel für Schweizer Päckli – war bestenfalls mühsam.

Das ehrliche Argument für eine vollständige Migration war letztlich: Wenn die Architektur selbst die Grenze setzt, verzögern schrittweise Verbesserungen nur das Unvermeidliche. Laravel und Vue 3 bieten dem Projekt nun ein solides Fundament:

• Bessere Performance und einfachere Erweiterbarkeit
• Sauberere Datenstrukturen mit weniger Plugin-Abhängigkeiten
• Ein Backend, das der Kunde selbstständig verwalten kann – ohne für Routineaktualisierungen eine Agentur hinzuziehen zu müssen

Die technischen Herausforderungen, die das Projekt verlangsamten

SSR-Einrichtung war schwieriger als erwartet

Der anspruchsvollste Teil des Projekts war die Konfiguration des Server-Side Renderings (SSR) für das Vue 3-Frontend. Da der Shop von Schweizer Päckli als Single Page Application (SPA) läuft, ist SSR das, was ihn für Suchmaschinen crawlbar und indexierbar macht. Ohne SSR existiert der Shop für Google praktisch nicht.

Die Schwierigkeiten kamen von älteren JavaScript-Bibliotheken, die eine Browserumgebung voraussetzen. Sobald man versucht, sie serverseitig zu rendern, funktionieren sie nicht mehr. Das Team musste diese Konflikte einen nach dem anderen lösen.

Was das Ganze noch heikler machte: Das Frontend musste exakt so aussehen wie zuvor. Der Kunde wollte keine sichtbaren Änderungen an der Benutzeroberfläche. Das Team schrieb also die internen Strukturen neu, während die Oberfläche identisch blieb – was aus einem technisch eingrenzbaren Problem eine deutlich delikatere Angelegenheit machte.

Datenmigration und CSS-Kontinuität

Die vorhandenen Daten mussten sauber in neue Schemata übertragen werden – ohne Verluste oder Integritätsprobleme. Keine aufregende Arbeit, aber genau hier lauern die unsichtbaren Fallstricke vieler Migrationen.

Bei CSS und SCSS war die Situation ähnlich. Jahrelange Stylesheets aus der CMS-Ära brachten die üblichen Altlasten mit sich: Spezifitätskonflikte, undokumentierte Überschreibungen, Stile, die an Markup gebunden waren, das nicht mehr existierte. Diese innerhalb von Vue 3-Komponenten korrekt zum Laufen zu bringen, ohne ein komplettes visuelles Redesign auszulösen, erforderte echte Geduld.

Was wir gelernt haben

Die unsichtbare Arbeit zählt am meisten

Das wichtigste Ergebnis, das niemand bemerkte: die komplette Überarbeitung der PDF-Generierung. Die Lieferantendokumente sehen auf den ersten Blick exakt gleich aus wie zuvor. Doch die interne Logik wurde neu aufgebaut, um ein deutlich höheres Dokumentenvolumen zu bewältigen, als das alte System je gekonnt hätte.

Das ist ein Muster, das man sich merken sollte: Die Verbesserungen, die die grösste langfristige Zuverlässigkeit schaffen, sind oft genau jene, die die Nutzer nie zu Gesicht bekommen. Das ist kein Grund, sie zu überspringen – sondern ein Grund, sie konsequent umzusetzen.

Moderner Stack als Voraussetzung, nicht als Luxus

Auf der alten Plattform lief fast jede Feature-Anfrage gegen dieselbe Wand. Die Antwort war immer: «Geht nicht – oder wird teuer.» Das trifft nicht nur Entwickler, sondern hat direkte geschäftliche Folgen.

Nach der Migration hat sich diese Diskussion grundlegend verändert. Neue Regionen können jetzt direkt im Backend hinzugefügt werden, ohne Entwicklungsaufwand. Features, die früher unerreichbar waren, lassen sich nun problemlos umsetzen.

Automatisierte Tests schützen dich, wenn sich die Geschäftslogik ändert

what. hat Testfälle eingeführt, die vor jedem Deployment ausgeführt werden. Für ein Unternehmen wie Schweizer Päckli – wo sich die Logik rund um regionale Pakete, Lieferanten und Bestellungen mit dem Wachstum des Produkts weiterentwickelt – ist das ein echtes Sicherheitsnetz. Es erkennt Probleme frühzeitig, bevor sie die Kunden erreichen.

Was gut funktioniert hat

Ein paar Dinge sind besonders reibungslos gelaufen:

• CDN-Einrichtung: Bilder, JavaScript- und CSS-Dateien werden nun über ein CDN auf den verschiedenen regionalen Domains von Schweizer Päckli ausgeliefert. Assets laden schneller, egal auf welcher regionalen Version der Website ein Besucher landet. Eine vergleichsweise einfache Entscheidung mit unverhältnismässig grosser Wirkung auf die wahrgenommene Performance.
• Laravel Nova-Backend: Der Kunde kann nun Inhalte, Regionen und Pakete selbst verwalten, ohne für Routineaktualisierungen Entwickler einzubeziehen. Diese redaktionelle Unabhängigkeit reduziert die Agenturabhängigkeit und schafft Zeit für wirklich komplexe, technische Aufgaben.
• Regionsverwaltung: Das Hinzufügen einer neuen Region, das früher erheblichen Entwicklungsaufwand erforderte, ist jetzt eine Backend-Aufgabe. Es gibt ausserdem einen Regionsumschalter, der einen schnellen Überblick über alle regionalen Versionen der Website bietet – nützlich, da das Unternehmen weiter expandiert.

Nächste Schritte

Die Migration war das Fundament, nicht das Ziel. Schweizer Päckli arbeitet aktiv an weiteren Verbesserungen des Shops – genau die richtige Herangehensweise. Die neue Architektur unterstützt diese Art der iterativen Weiterentwicklung auf eine Weise, wie es das alte System schlicht nicht konnte.

Aktuelle Themen sind Shop-Verbesserungen und die weitere regionale Expansion. Das Team steht nicht still.

Die wichtigsten Erkenntnisse aus diesem Projekt

Plattformmigrationen sind nie rein technisch. Die grössten Herausforderungen bei diesem Projekt waren nicht technischer Natur: die Benutzeroberfläche optisch unverändert zu lassen, jahrelange Daten sauber zu migrieren und mit Legacy-JavaScript-Bibliotheken umzugehen, die nicht für moderne Rendering-Ansätze ausgelegt waren.

Die Dinge, die den nachhaltigsten Wert geschaffen haben, waren nicht die auffälligsten Ergebnisse. Die PDF-Überarbeitung, die CDN-Einrichtung, die Testsuite – das sind die strukturellen Verbesserungen, die über Jahre hinweg im Hintergrund Probleme verhindern werden. Sie lassen sich auch am einfachsten streichen, wenn Zeitpläne drücken – und genau deshalb sollten sie priorisiert werden.

Wenn du an einem veralteten CMS festhältst und Gründe suchst, eine Migration aufzuschieben: Die Kosten dieser Verzögerung sind wahrscheinlich höher, als es den Anschein hat. Jede Feature-Anfrage, die mit «geht nicht» beantwortet wird, hat geschäftliche Konsequenzen – nicht nur technische.

Wenn du über eine Plattformmigration oder einen Website-Relaunch nachdenkst: what. hilft Unternehmen dabei, genau diesen Prozess zu bewältigen – von den Anforderungen und der Systemauswahl bis hin zur Implementierung und Inbetriebnahme. Schau dir die Website-Relaunch- und Entwicklungsdienste von what. an, um zu sehen, wie wir dabei vorgehen.

The post Wie wir Schweizer Päckli von OctoberCMS zu Laravel & Vue 3 migriert haben appeared first on what. AG.

Gemeinsam mit der ETH Zürich haben wir den ETH Companion entwickelt: einen AI-Leadership-Coach, der ausschliesslich auf wissenschaftlichen Quellen basiert und über 3000 Führungskräfte der ETH unterstützt. Hier sind die ehrlichen Erkenntnisse dahinter.

Die ETH Zürich – Forschung auf Weltklasseniveau

Die ETH Zürich ist eine der renommiertesten Forschungsuniversitäten weltweit. Seit ihrer Gründung 1854 steht sie für wissenschaftliche Exzellenz in Naturwissenschaften, Technologie, Ingenieurwesen und Mathematik.

Mit über 13’000 Mitarbeitenden aus rund 120 Ländern ist die ETH nicht nur eine Schweizer Institution, sondern ein globaler Akteur in Bildung und Forschung. Wer hier arbeitet, bewegt sich in einem hochkomplexen, internationalen Umfeld – mit entsprechend hohen Anforderungen an Führung und Entscheidungsfindung.

Genau da setzt der ETH Companion an.

Was diesen AI-Coach wirklich besonders macht

Die eigentliche Frage zu Beginn war nicht technischer Natur – sondern eine strategische: Wie macht man hochwertiges Leadership-Coaching für tausende Führungskräfte zugänglich, ohne dafür hohe Summen in individuelle Coaching-Programme zu investieren? Klassisches 1:1-Coaching skaliert nicht. Digitales Coaching schon.

Der Schlüssel liegt in der Qualität der Wissensbasis. Der ETH Companion zieht ausschliesslich Informationen aus vertrauenswürdigen Artikeln von ETH-Psychologen. Keine Inhalte aus beliebigen Internetquellen – nur wissenschaftlich abgesicherte Inhalte, entwickelt von der ETH für die ETH.

Und das ist kein kleiner Unterschied. Ein persönliches Leadership-Coach-Programm kostet schnell mehrere hunderttausend Franken pro Jahr – wenn man ernsthaft Führungsentwicklung im grossen Massstab betreiben will. Der ETH Companion skaliert genau das: wissenschaftlich fundiertes Leadership-Coaching, zugänglich für jede Führungskraft, jederzeit.

Das Ziel ist nicht, einen Chatbot zu bauen. Es geht darum, ein Tool zu schaffen, das Führungskräfte bei echten Herausforderungen begleitet – basierend auf Ansätzen, die funktionieren, weil sie wissenschaftlich belegt sind.

Das klingt simpel, ist aber konzeptionell anspruchsvoll. Man muss sehr früh klären: Welche Inhalte kommen rein? Wer kuratiert sie? Wie wird sichergestellt, dass der Coach im Scope bleibt?

Diese Fragen sollte man lösen, bevor man auch nur eine Zeile Code schreibt.

MVP definieren ist schwerer als MVP bauen

Der herausfordernste Moment des Projekts war nicht technisch – es war die Definition des MVP (Minimal Viable Product).

Was gehört rein? Was kommt später? Wo ist die Grenze zwischen «gut genug zum Testen» und «zu roh, um echten Wert zu zeigen»? Diese Diskussionen dauern länger als erwartet, sind aber entscheidend.

Wir haben in Scope-Definition-Workshops mit dem ETH-Team gearbeitet, User Stories erstellt und das Framework schrittweise aufgebaut. Das hat sich gelohnt – aber es kostet Zeit, die man einplanen muss.

Ein klarer Tipp: Fang klein an und skalier dann. Konzentrier dich im MVP auf das absolut Wesentliche, schau, ob es funktioniert – und erweitere erst dann mit zusätzlichen Features. Was du im MVP nicht geklärt hast, kostet dich später das Doppelte.

User-Testing zeigt, was Dokumente nie zeigen

Der schönste Moment des gesamten Projekts war während der User-Testing-Interviews.

Wir haben gesehen, wie Führungskräfte mit dem Companion interagiert haben – und die echte Begeisterung war spürbar. Das validiert nicht nur das Produkt, sondern auch alle Entscheidungen davor.

Aber User-Testing hat uns auch konkrete Erkenntnisse geliefert, die wir vorher nicht hatten:

• Wie Führungskräfte Fragen formulieren und was das für die Gesprächsführung des Coaches bedeutet
• Wo der Dialog zu generisch wurde und mehr Tiefe brauchte
• Welche Einstiegspunkte intuitiv sind – und welche nicht

Ohne diese Phase wäre das Produkt schlechter geworden. Kein Dokument, kein interner Test ersetzt echte Interaktionen.

Sicherheit ist kein optionales Add-on

Ein Security-Audit gehörte zum Entwicklungsprozess – und das war richtig so.

Bei einem Tool, das auf sensiblen Leadership-Situationen basiert und von tausenden Führungskräften genutzt werden soll, ist Sicherheit keine Kür. Sie ist Pflicht.

Plane das von Anfang an ein – nicht als letzten Schritt kurz vor dem Launch.

Was wirklich zählt: langfristige Integration, nicht kurzfristige Nutzung

Kurz nach dem Launch liegt der Fokus verständlicherweise auf der Frage: Sind die Nutzer zufrieden mit den Antworten?

Das ist legitim – aber zu kurz gedacht. Die eigentliche Vision des ETH Companions ist eine andere: Der AI-Leadership-Coach soll langfristig ein fester Bestandteil des Arbeitsalltags werden und die Entscheidungsqualität von Führungskräften nachhaltig verbessern.

Und die Vision geht noch weiter: Was heute für ETH-Führungskräfte gebaut wurde, soll morgen auch für grosse Unternehmen ausserhalb der ETH verfügbar sein – als skalierbare Lösung für Organisationen, die Leadership-Entwicklung ernst nehmen, ohne dafür hunderttausende Franken in individuelle Coaching-Programme zu investieren.

Das ist ein anderer Massstab. Und er braucht andere Metriken als «Hat die KI heute eine gute Antwort gegeben?»

Was wir geliefert haben – und was weitergeht

Das Ergebnis ist ein funktionierender, stabiler AI-Leadership-Coach mit einem durchdachten Design, der produktiv im Einsatz ist. Was nach dem Launch kommt, ist genauso wichtig wie der Launch selbst.

Wir arbeiten in kontinuierlichen Sprints an der Weiterentwicklung – weil ein KI-Tool dieser Art kein abgeschlossenes Projekt ist, sondern ein lebendiges Produkt.

Was du daraus mitnehmen kannst

Wenn du ein ähnliches Projekt planst, sind das die Erkenntnisse, die wirklich zählen:

• Differenzierung entsteht durch Inhalt, nicht durch Technik – die Qualität der wissenschaftlichen Datenbasis und der klare Fokus des Coaches machen den Unterschied.
• Klein anfangen, dann skalieren – MVP-Scope schriftlich festlegen, validieren, dann erst erweitern.
• User-Testing ist nicht optional – plane es als echte Phase, nicht als Checkbox am Ende.
• Sicherheit und Skalierbarkeit müssen von Anfang an mitgedacht werden, nicht nachträglich.

Interessiert dich, wie KI-Automatisierung konkret in deinem Unternehmen aussehen könnte? Genau das ist es, womit wir uns täglich beschäftigen.

The post ETH Zürich AI-Leadership-Coach: Unsere Learnings appeared first on what. AG.

Das war die zentrale Herausforderung in unserem Projekt mit BMW Classic: Wie modernisiert man, ohne einen hochspezialisierten, weltweit versendenden Betrieb aus dem Takt zu bringen? Hier erfährst du, was tatsächlich passiert ist – und was wir dabei gelernt haben.

Das eigentliche Problem war nicht die alte Technologie

BMW Classic betreibt einen der spezialisiertesten Online-Shops in der Motorradwelt – Originalteile für alles von Klassikern aus den 1920er Jahren bis hin zu aktuellen Modellen, mit globalem Versand. Die Plattform hatte jahrelang ihren Dienst getan, war aber an ihre Grenzen gestossen:

• SEO war de facto inexistent. Die Website wurde kaum indexiert, was bedeutete, dass Kunden, die nach Nischen-Ersatzteilen suchten – oft sehr spezifische Suchanfragen – den Shop einfach nicht finden konnten.
• Inhaltsaktualisierungen waren langsam und riskant.
• Das System war nicht dafür ausgelegt, moderne Marketing-Workflows oder ein reibungsloses Einkaufserlebnis zu unterstützen.

Die versteckte Komplexität: Ein erheblicher Teil der Geschäftslogik steckte in FileMaker, einem veralteten Datenbanksystem, in dem sich jahrelanges Betriebswissen angesammelt hatte – Produktstrukturen, Kompatibilitätsregeln, Fulfillment-Logik. Das schaltet man nicht einfach ab.

Das Geschäft am Laufen halten und gleichzeitig neu aufbauen

Die wichtigste architektonische Entscheidung, die wir früh getroffen haben, war diese: FileMaker nicht mit einem Big Bang ersetzen. Sondern behutsam darum herum aufbauen.

Das bedeutete, einen dedizierten Sync-Layer zu entwerfen – eine strukturierte Integration, die FileMaker mit der neuen, massgeschneiderten Storefront verbindet, Produkt- und Katalogdaten synchron hält und den Shop vor den Risiken schützt, die mit alten Datenquellen einhergehen. Wenn FileMaker vorübergehend nicht verfügbar ist, läuft der Shop einfach weiter. Diese Stabilität ist nur dank der Abstraktionsebene zwischen beiden Systemen möglich.

Was uns das gelehrt hat: Die Vorbereitung und das Verständnis des bestehenden Systems sind wichtiger als die Technologie, auf die man migriert. Wir haben viel Zeit mit den Architekten des alten Shops verbracht, bevor wir auch nur eine einzige Zeile des neuen geschrieben haben. Diese Investition hat sich direkt in der Qualität der Integration ausgezahlt.

Zwei Systeme, zwei Aufgabenbereiche – warum Payload CMS die richtige Wahl war

Ein Shop wie BMW Classic braucht zwei grundlegend verschiedene Dinge, die parallel laufen: eine strukturierte Commerce-Ebene für Teiledaten, Preise, Kompatibilität und Lagerbestände – und eine flexible Content-Ebene für Landingpages, Kampagnen und redaktionelles Storytelling.

Beides in ein einziges System zu packen, führt auf beiden Seiten zu Kompromissen. Also haben wir sie bewusst getrennt.

Payload CMS wurde zum Content-Zentrum. Es gab dem BMW Classic-Team die Möglichkeit, Marketinginhalte zu veröffentlichen und zu aktualisieren, Kampagnenseiten zu erstellen und redaktionelles Material zu verwalten – ohne für jede Änderung einen Entwickler zu benötigen. Diese operative Unabhängigkeit ist entscheidend, besonders für ein Team, das einen Katalog dieser Grösse verwaltet.

Die individuelle Commerce-Ebene übernahm den Rest: Produktdaten, Checkout, Preisgestaltung und Bestellablauf. Über den Sync-Layer verbunden, gaben beide Systeme zusammen BMW Classic etwas, das sie zuvor nicht hatten – Geschwindigkeit ohne Risiko.

SEO als Produktanforderung, nicht als nachträglicher Einschub

Eine der klarsten Entscheidungen, die wir von Anfang an getroffen haben: SEO als Kernanforderung behandeln – nicht als eine Etappe, die erst nach der Entwicklung angegangen wird. Für einen Shop, der über 40’000 Ersatzteile verkauft, ist organische Auffindbarkeit kein «Nice-to-have». Sie entscheidet darüber, ob man die Long-Tail-Suchanfragen für sich gewinnen kann oder sie komplett verpasst.

In der Praxis hiess das:

• Eine saubere, indexierbare URL- und Navigationsstruktur vom ersten Tag an
• Schnelle Seitenladezeiten über Next.js und Digital-Ocean-Infrastruktur
• Eine skalierbare Metadaten- und Inhaltsarchitektur, die mit dem Katalog wächst
• Eine Navigation, die echtes Suchverhalten abbildet: von der Modellfamilie über die Kategorie bis zum gesuchten Teil.

Die vorherige Plattform hatte im Grunde keine SEO-Grundlage. Das strukturell zu beheben, anstatt nur zu flicken, war eine der wirtschaftlich relevantesten Massnahmen in diesem Projekt.

Was wir genauso machen würden – und worauf wir genauer achten würden

Das Design und die technische Architektur haben sich gut bewährt. Eine Storefront rund um die echte Customer Journey aufzubauen – das richtige Modell finden, sicher durch die Kategorien navigieren, Teiledetails prüfen, reibungslos kaufen – ist der richtige Ansatz für einen Ersatzteilshop dieser Grösse.

Was wir beim nächsten Mal noch genauer im Blick behalten würden: eine noch gründlichere Dokumentation der FileMaker-Datenstrukturen, bevor die CMS-Migration beginnt. Altsysteme enthalten oft Sonderfälle, die erst unter realen Bedingungen auftauchen. Je gründlicher du das alte System im Voraus abbildest, desto weniger Überraschungen tauchen während der Sync-Tests auf.

Die andere wichtige Erkenntnis – und das gilt über BMW Classic hinaus – ist, dass ein Sync-Layer nicht bloss eine technische Notlösung ist. Er ist ein langfristiges architektonisches Merkmal. Zukünftige Migrationen, Erweiterungen oder der Austausch einzelner Komponenten erfordern keinen Neuaufbau der gesamten Plattform. Besonders wertvoll, wenn das Geschäft wächst und sich verändert.

Wo wir heute stehen

Der Shop ist live, läuft stabil und wird kontinuierlich weiterentwickelt. Wir arbeiten laufend an SEO-Verbesserungen, UX-Optimierungen und dem Ausbau der Content-Ebene. Ein Projekt wie dieses endet nicht mit dem Launch – es tritt in eine Wachstumsphase ein, und das Fundament muss solide genug sein, um das zu tragen.

Wenn es eine Erkenntnis gibt, die man aus diesem Projekt mitnehmen sollte: Der schwierigste Teil bei der Migration eines Altsystems ist nicht die neue Technologie. Es geht darum, das alte System gut genug zu respektieren und zu verstehen, um sicher darauf aufzubauen.

Arbeitest du mit einer inhaltsreichen Plattform oder überlegst du dir eine CMS-Migration? Unsere Payload CMS Services sind genau für solche Projekte gemacht – komplexe Daten, redaktionelle Unabhängigkeit und kein Big-Bang-Risiko.

Auch relevant: Erfahre, wie wir einen ERP-Shopify-Konnektor entwickelt und den E-Commerce-Shop für Rokker zusammengeführt haben.

The post E-Commerce- und CMS-Migration für BMW Classic appeared first on what. AG.

Was wir entwickelt haben: Eine Live-Datenbrücke zwischen Shopify und SAP S/4 HANA

Die Rausch GmbH brauchte eine vollautomatische Verbindung zwischen ihrem Shopify-Plus-Shop und SAP S/4 HANA. Keine manuellen Exporte, keine Spreadsheet-Übergaben.

Wir haben einen massgeschneiderten SAP-Konnektor entwickelt, der vier Kernaufgaben übernimmt: Bestellungen, Zahlungsbedingungen, Sendungsverfolgungsnummern und Bestandsabgleich. In Zusammenarbeit mit Eddyson – einem externen SAP-Integrationspartner – haben wir die Shopify-Seite übernommen, während Eddyson die Verbindung zu SAP hergestellt hat.

Der Ablauf funktioniert so:

• Shopify sendet Bestelldaten per Webhook an unseren Konnektor
• Wir reichern die Dateien mit fehlenden Informationen an und legen sie auf einem FTP-Server ab, von dem Eddyson sie abholt
• In die andere Richtung sendet SAP Sendungsverfolgungs- und Bestandsaktualisierungen an Eddyson, das sie an uns weiterleitet – wir reichern sie an und übertragen sie zurück nach Shopify

Ein sauberer Kreislauf – wenn er funktioniert.

Dateianreicherung und Zahlungsabläufe: Hier liegt die eigentliche Komplexität

Der Shopify-Bestell-Webhook liefert nicht alles, was SAP S/4 HANA braucht – und genau diese Lücke war für den Grossteil der Arbeit verantwortlich.

Barcodes zum Beispiel sind nicht Teil der Bestelldaten. Der Konnektor geht jede einzelne Position durch, löst einen zusätzlichen API-Aufruf mit der Varianten-ID aus und holt den Barcode separat. Gleiche Logik bei Geschenkkarten: Wir erkennen den Namen des Zahlungsgateways, rufen den Transaktions-Endpunkt auf und holen die Geschenkkartendaten, bevor die Datei verpackt wird.

Jeder dieser Schritte ist für sich genommen nicht komplex. Aber wenn du Felder zwischen zwei Systemen mit grundlegend unterschiedlichen Datenmodellen abbildest, summiert sich das schnell.

Kauf auf Rechnung erforderte eine komplett eigene Lösung. SAP behandelt diese Bestellungen mit einer Liefersperre – die Bestellung existiert, wird aber erst versandt, wenn die Zahlung bestätigt ist. Das bedeutete, dass orders/create und orders/paid nicht demselben Ablauf folgen konnten. Wir haben zwei separate Abläufe gebaut, die jeweils unterschiedliche nachgelagerte Logik auslösen. Das SAP-Verhalten sauber zu dokumentieren hat länger gedauert als erwartet.

Projektkoordination zwischen drei Parteien: Die versteckten Kosten mangelnder Abstimmung

Jedes Projekt mit einem Kunden, einer Agentur und einem externen Integrationspartner hat natürliche Reibungspunkte. Die Mapping-Entscheidungen brauchten Zeit zum Festlegen, und manche Verzögerungen entstanden weniger durch die technische Arbeit selbst als durch das Warten auf Abstimmung zwischen den Parteien.

Wir haben das gemeistert – aber es hat uns etwas Wichtiges darüber gelehrt, wie solche Projekte von Anfang an aufgesetzt werden sollten.

Was wir bei einer Shopify-ERP-Integration anders machen würden

Wir sind ohne detaillierte Anforderungsliste oder Zeitplan mit Meilensteinen in dieses Projekt gegangen. Das hat uns Zeit gekostet.

Vorab-Dokumentation ist unabdingbar. Wenn du zwischen Shopify, einem massgeschneiderten Konnektor und einem externen SAP-Middleware-Partner koordinierst, kommt Unklarheit teuer zu stehen. Eine Anforderung, die für eine Partei selbstverständlich erscheint, ist für eine andere neu.

Ein paar Dinge, die wir bei jeder Shopify-ERP-Integration mittlerweile als unverzichtbar ansehen:

• Eine detaillierte Anforderungsliste vor dem Start – besonders für Zahlungsabläufe, Steuerlogik und Sonderfälle wie Geschenkkarten oder individuelle Zahlungsmethoden.
• Ein gemeinsamer Slack-Kanal, in den alle Beteiligten vom ersten Tag an eingebunden sind – wenn der Kontext über E-Mails und Anrufe verstreut ist, bremst das alles aus.
• Daten-Mapping früh und detailliert abschliessen – die Lücke zwischen dem, was Shopify sendet, und dem, was SAP erwartet, kostet Projekte Wochen.

Die wichtigsten Erkenntnisse für deine Shopify-SAP-Integration

Wenn du eine Shopify-SAP oder eine umfassendere Shopify-ERP-Integration mit einem externen Middleware-Partner planst, hier die Kurzfassung dessen, was uns dieses Projekt gelehrt hat:

• Anforderungen vor dem Start definieren – kein grober Umfang, sondern eine konkrete Liste: Zahlungsabläufe, Steuerlogik, Sonderfälle.
• Daten frühzeitig abbilden – die Feldunterschiede zwischen Shopify und SAP sind real und brauchen Zeit, um sie sauber zu lösen.
• Auf einem Stack aufbauen, den du auch warten wirst – technische Schulden aus alten Codebasen tauchen als Migrationskosten auf, nicht «ob», sondern «wann».
• Einen gemeinsamen Kommunikationskanal vom ersten Tag an – wenn drei Parteien schnell auf einen Stand kommen müssen, bremst asynchrone Fragmentierung den Schwung.

Der Konnektor funktioniert. Die Lektionen haben sich gelohnt.

Für die Rausch GmbH haben wir auch das gesamte Spektrum unserer Shopify-Servicesumgesetzt – den Aufbau ihres Shopify-Plus-Shops, die Migration von Shopware 5 und die Implementierung eines massgeschneiderten Produktkonfigurators für ihre Pick&Mix-Lösungen. Der ERP-Konnektor ist Teil eines grösseren, funktionierenden Ökosystems.

The post Shopify ↔ SAP S/4 HANA Integration: Was wir beim Aufbau eines massgeschneiderten ERP-Konnektors gelernt haben appeared first on what. AG.

Aber selbst gut geplante Webentwicklungs-Projekte haben ihre Tücken – und dieses hat uns mehr gelehrt, als wir erwartet hatten.

Content-Management erfordert echten Einsatz

Wenn du mit spezialisierten technischen Systemen wie Bewässerungs- und Beleuchtungsanlagen arbeitest, geht es bei den Inhalten nicht einfach darum, Seiten zu füllen – es geht um Präzision. Unser hoher Qualitätsanspruch und die genaue Darstellung der komplexen Produktpalette der Rudolf Hirt AG haben dazu geführt, dass diese Phase deutlich mehr Zeit in Anspruch genommen hat als ursprünglich geplant.

Die Struktur stand, das Design war freigegeben, die Entwicklung lief. Aber das Sammeln, Hochladen und Aufbereiten von Bildern und technischen Spezifikationen für Spezialgeräte verlangte grosse Sorgfalt. Jedes Produkt benötigte den richtigen Kontext, präzise technische Daten und visuelle Elemente, die die Qualität der Systeme wirklich widerspiegeln.

Die eigentliche Lektion? Behandle Content niemals als Nebensache. Wenn du einen Website-Relaunch planst, rechne ernsthaft Zeit für diese Phase ein – vor allem dann, wenn technische Genauigkeit und hochwertige Darstellung unabdingbar sind.

Klarer Scope verhindert böse Überraschungen

In spezialisierten Branchen wie der Bewässerungs- und Beleuchtungstechnik sind Details enorm wichtig – besonders für SEO und Auffindbarkeit. Während dieses Projekts haben wir festgestellt, wie entscheidend Elemente wie umfassende Alt-Texte sind, damit potenzielle Kunden hochtechnische Produkte über die Web-Suche finden können.

Alt-Texte waren in unserer ursprünglichen Vereinbarung nicht explizit vorgesehen. Als uns klar wurde, wie wichtig sie für die SEO-Performance in diesem Nischenmarkt sind, mussten wir umdisponieren – was mit mehr Vorausplanung deutlich reibungsloser hätte laufen können.

Das war eine wertvolle Erfahrung für beide Seiten: Wer sich zu maximaler Qualität und Detailgenauigkeit verpflichtet, braucht eine ebenso detaillierte Planung. Heute arbeiten wir von Anfang an mit umfassenden Checklisten, die diese SEO-kritischen Elemente berücksichtigen – besonders für Unternehmen mit spezialisierten technischen Angeboten.

Was sich nach diesem Projekt geändert hat: Wir legen jetzt vor Beginn der Entwicklung Verantwortlichkeiten, Leistungen und Erwartungen im Detail fest. Wir halten fest, was enthalten ist, was optional ist und wo Kompromisse nötig sein könnten. Frühe Klarheit ist keine Bürokratie – sie verhindert Missverständnisse, die später Zeit und Vertrauen kosten.

Nutzererfahrung vor visueller Komplexität

Das Gesamtdesign wurde freigegeben. Super. Die Entwicklung startete mit komplexen Scroll-Animationen, die visuellen Feinschliff brachten – und erhebliche technische Komplexität mit sich.

Dann haben wir eine bewusste Entscheidung getroffen: Nutzererfahrung und Ladegeschwindigkeit der Seite haben Vorrang vor dekorativen Elementen. Die Animationen sahen in der Entwicklung beeindruckend aus, aber wir erkannten, dass sie die Performance beeinträchtigen könnten – und das ist für eine Unternehmens-Website entscheidend, auf der potenzielle Kunden schnell an technische Informationen und Kontaktmöglichkeiten kommen müssen.

Das war wirklich niemandes Schuld. Animationen lassen sich in statischen Mockups schwer beurteilen. Was auf dem Papier vielversprechend klingt, kann im realen Einsatz ablenkend wirken – oder sich als nicht lohnenswert erweisen, sobald die Performance-Einbussen live sichtbar werden.

Die Erkenntnis: Komplexe Designelemente wie Animationen brauchen bessere Vorschaumöglichkeiten, bevor sie vollständig umgesetzt werden. Schnelle Prototypen oder interaktive Demos helfen Kunden, die Abwägung zwischen visueller Attraktivität und technischer Performance zu verstehen – das ermöglicht frühzeitige, fundierte Entscheidungen und reduziert kostspielige Änderungen während der Entwicklung.

Workflows sind wichtiger, als man denkt

Wir haben einen WordPress-Workflow vom ursprünglichen Entwickler übernommen. Technisch hat er funktioniert. Aber er erforderte ständige Anpassungen und verursachte während des gesamten Projekts zusätzlichen Aufwand.

Seit dieser Erfahrung haben wir alle WordPress-Projekte auf einen einheitlichen, optimierten Workflow umgestellt. Die richtigen Tools und Prozesse von Anfang an zu wählen – oder bereit zu sein, sich anzupassen, wenn etwas offensichtlich nicht funktioniert – spart enorm viel Zeit und hält das Budget unter Kontrolle.

Wenn du neugierig bist, wie wir heute eine WordPress-Entwicklung angehen, schau dir unsere WordPress-Services an.

Qualitätsorientierte Entscheidungsfindung

Ganz ehrlich: Jedes Webentwicklungs-Projekt bringt Kompromisse mit sich. Beim Relaunch haben wir uns bewusst dafür entschieden, der Gesamtqualität und dem langfristigen Wert Vorrang vor bestimmten Funktionen zu geben.

Das ist kein Kompromiss bei der Qualität – das ist strategischer Fokus. Der Schlüssel liegt darin, diese Kompromisse transparent zu kommunizieren, damit beide Teams verstehen, welche Elemente den grössten Mehrwert bringen und welche vielleicht anders angegangen oder schrittweise umgesetzt werden könnten.

Dieser kollaborative Ansatz bei der Entscheidungsfindung – immer mit der Frage «Was ist für den Endnutzer am besten?» – hat die Richtung des Projekts geprägt und letztlich zu seinem Erfolg beigetragen.

Warum es trotzdem funktioniert hat

Trotz der Herausforderungen hat der Relaunch echte Ergebnisse gebracht. Die Qualität der eingehenden Anfragen hat sich spürbar verbessert, und das Feedback von Neukunden zum Website-Design war überwältigend positiv. Die Rudolf Hirt AG berichtet, dass sie ihren neuen Webauftritt fast wöchentlich gelobt bekommt – mehrere potenzielle Kunden haben die Website ausdrücklich als einen Faktor für ihre Entscheidung genannt, Kontakt aufzunehmen.

Abgesehen vom subjektiven Feedback sprechen die SEO-Verbesserungen für sich. Zwischen August 2025 und Februar 2026 erzielte die Rudolf Hirt AG deutliche Ranking-Verbesserungen für ihre wichtigsten Keywords. Mehrere Suchbegriffe rückten in die Top-10-Positionen vor und verbesserten die Sichtbarkeit ihrer spezialisierten Bewässerungs- und Beleuchtungsangeboten erheblich.

Das Projekt hat gezeigt: Selbst bei unerwarteten Herausforderungen führt der Fokus auf Zusammenarbeit, Qualität und ehrliche Kommunikation zu messbarem Erfolg.

Schau dir das Redesign von Rudolf Hirt AG Bewässerung, Brunnentechnik und Beleuchtung an, um das Endergebnis zu sehen.

Was du daraus mitnehmen kannst

Der Relaunch der Rudolf Hirt AG ist ein Erfolg – nicht nur wegen dem, was beim Launch erreicht wurde, sondern auch wegen der Grundlage, die damit für weiteres Wachstum geschaffen wurde. what. unterstützt die Rudolf Hirt AG weiterhin mit SEO und kontinuierlichen Verbesserungen. Denn: Nach dem Launch kommt das Wachstum.

Wenn du einen Website-Relaunch planst oder mit einem Webentwicklungs-Team zusammenarbeitest, kommt es auf Folgendes an:

• Plane ausreichend Zeit für die Content-Erstellung ein. Das geht nie so schnell wie gedacht – besonders wenn Qualität und technische Genauigkeit zählen.
• Lege den Scope von Anfang an fest. Arbeite mit Checklisten. Halte genau fest, was enthalten ist – besonders SEO-kritische Elemente für spezialisierte Branchen.
• Sieh dir komplexe Funktionen frühzeitig an. Warte nicht bis zum Ende der Entwicklung, um Animationen oder Interaktionen zu bewerten – und sei bereit, Performance vor Dekoration zu priorisieren.
• Entscheide dich für effiziente Workflows. Die richtigen Tools und Prozesse zahlen sich langfristig aus.
• Sprich offen über Kompromisse. Bei jedem Projekt muss man entscheiden, wo man sich besonders ins Zeug legt – Transparenz bei diesen Entscheidungen schafft Vertrauen und führt zu besseren Ergebnissen.

Das sind keine theoretischen Best Practices – es sind Erkenntnisse aus einem echten Projekt, das weiterhin Ergebnisse liefert. Und sie haben grundlegend geprägt, wie wir heute an Webentwicklung und langfristige Kundenpartnerschaften herangehen.

The post Lehren aus einem Website-Relaunch: Was wir über Content, Design und SEO gelernt haben appeared first on what. AG.

Wir haben den Konnektor komplett neu aufgebaut, ihre Shops zusammengeführt und die monatlichen Kosten um 2000 CHF gesenkt. Hier erfährst du, was wirklich passiert ist.

Der Konnektor ging live – aber nicht ohne Probleme

Mitte Dezember 2025 haben wir den neuen ERP-Konnektor aufgesetzt. Er hat ein veraltetes FTP-basiertes System ersetzt, das auf benutzerdefiniertem ColdFusion-Code und einer Shopify-API-Version aus dem Jahr 2020 basierte.

Das alte Setup? Höchstens rudimentär funktionsfähig. Die Lagerbestände waren falsch, die Übermittlung von Bestellungen funktionierte regelmässig nicht und niemand konnte nachvollziehen, wo es zu Problemen kam.

Der neue Konnektor hat die Lage stabilisiert – aber nicht sofort. Die ersten zwei Wochen des Jahres 2026 haben wir damit verbracht, Sonderfälle und Synchronisierungsprobleme zu beheben. In der zweiten Woche lief dann alles reibungslos.

Die Lektion: Selbst wenn man etwas richtig neu aufbaut, muss man mit einer Übergangsphase rechnen. FTP-Abhängigkeiten und veraltete APIs verschwinden nicht einfach – sie verbergen Probleme, die man erst entdeckt, wenn echte Bestellungen eingehen.

Unterschiede bei der Preisberechnung hätten fast die Automatisierung zum Scheitern gebracht

Hier etwas Interessantes: Shopify berechnet B2C-Preise inklusive Mehrwertsteuer pro Position. Dataforce berechnet B2B-Preise ohne Mehrwertsteuer.

Klingt überschaubar, oder? Falsch.

Aufgrund von Rundungsdifferenzen stimmten die Summen zwischen den Systemen nicht überein. Dataforce konnte keine Rechnungen automatisch erstellen, weil die Zahlen nicht stimmten – manchmal nur um Rappenbeträge, aber genug, um den gesamten Prozess zu blockieren.

Wir mussten die Berechnungslogik auf beiden Seiten angleichen, fehlende Mehrwertsteuersätze im ERP hinzufügen und unvollständige Versandkostendaten korrigieren. Erst dann konnten Bestellungen ohne manuelles Eingreifen abgewickelt werden.

Was wir jedem raten würden, der eine ERP-Integration durchführt: Teste deine Preisberechnungslogik mit realen Bestellungen, bevor du live gehst. B2C/B2B-Unstimmigkeiten, Rundungsregeln und die Handhabung von Steuern führen zu Problemen, die in Modellen nie sichtbar werden.

Die Zusammenlegung der Shops hat Budget eingespart und Abläufe vereinfacht

Die Rokker Company AG hat mehrere Shopify-Shops parallel betrieben. Unterschiedliche Preise, unterschiedliche Apps, sich überschneidende Funktionen – und monatliche Kosten, die sich summierten.

Wir haben alles zu einer übersichtlicheren Struktur zusammengefasst, die Preise über alle Märkte hinweg harmonisiert und unnötige App-Abonnements gekündigt. Allein dadurch konnten wir rund 2000 CHF pro Monat einsparen.

Die Zusammenlegung selbst war Ende Dezember 2025 abgeschlossen. Ein Shop weniger zu verwalten bedeutet weniger Fehler, weniger Verwaltungsaufwand und klarere Daten.

Der Kompromiss: Die Zusammenlegung von Shops klingt einfach, bis man sich mit Zahlungsanbietern, Steuervorschriften und Marketing-Tracking auseinandersetzen muss. Das bringt uns zu…

Subdirectories wurden blockiert – von einer externen Agentur

Wir haben eine ordentliche Shopify Markets-Struktur mit Unterverzeichnissen (ch-de, de-de, at-de usw.) entworfen und vorbereitet. Saubere URLs, bessere Suchmaschinenoptimierung, ordentliche Marktsegmentierung.

Alles war startklar, aber es kam zu einer Verzögerung. Warum? Die Performance-Marketing-Agentur wurde nicht rechtzeitig informiert. Die Anweisungen kamen über einen Mittelsmann, was für Verwirrung und Verzögerungen sorgte – bis das Problem endlich gelöst war.

Die Erkenntnis: Wenn du Shops zusammenführst oder Märkte umstrukturierst, beziehe alle mit ein, die mit URLs, Tracking oder Werbekampagnen zu tun haben. Marketingagenturen brauchen Vorlaufzeit – und Überraschungen bringen den Startplan durcheinander.

Was noch offen ist (und warum es wichtig ist)

Das folgende Problem ist noch nicht geklärt:

Das interne Dataforce-Mapping für einige kundenspezifische Besonderheiten kann nur auf drei Arten gelöst werden: Erweiterung der Bestell-API, Änderung von internen Prozessen bei Rokker oder Erstellung eines benutzerdefinierten Mappings innerhalb von Dataforce selbst.

Wir haben die Möglichkeiten dargelegt. Die Entscheidung liegt beim Kunden.

Warum das für dich wichtig ist: Selbst wenn die technische Arbeit erledigt ist, hängt es von der organisatorischen Abstimmung ab, ob du das, was du entwickelt hast, auch tatsächlich nutzt. Plane Zeit für die interne Koordination ein – das geht selten schnell.

Was tatsächlich funktioniert hat

Trotz der Schwierigkeiten hat das Projekt Früchte getragen:

• Konnektor live und stabil – Bestellungen, Lagerbestände und Kundendaten werden zuverlässig übertragen
• Shop-Merge abgeschlossen – übersichtlichere Struktur, einheitliche Preisgestaltung
• 2000 CHF monatliche Einsparungen – durch App-Konsolidierung und intelligentere Tools
• Automatisierter GLS-Versand – Etiketten, Sendungsverfolgung und Importe funktionieren ohne manuelle Schritte

Der Konnektor hat gezeigt, dass selbst chaotische ERP-Situationen (veraltete APIs, nicht übereinstimmende Berechnungslogik, unvollständige Stammdaten) behoben werden können – wenn man bereit ist, sich mit den Details auseinanderzusetzen und alles ordentlich neu aufzubauen.

Wichtigste Erkenntnisse

Beginne mit einem Proof of Concept. Wir haben das gemacht und konnten so frühzeitig Unstimmigkeiten bei der Preisberechnung aufdecken. Ohne diese PoC-Phase hätten wir diese Rundungsprobleme erst in der Produktion entdeckt – was viel schlimmer gewesen wäre.

Berücksichtige von Anfang an auch die nicht offensichtlichen Dinge. Adressen-Logik, Mehrwertsteuerabwicklung, Regeln zur Kundenerfassung – das ist zwar nicht besonders spannend, aber genau hier scheitern Projekte oft. Erstelle vom ersten Tag an eine Checkliste.

Beziehe alle Beteiligten vor dem Shop-Merge mit ein. Marketingagenturen, Zahlungsanbieter, Analyseteams – wenn sie mit URLs oder Tracking zu tun haben, müssen sie in die Planung einbezogen werden.

Wichtig: Die Anpassung von ERP-Systemen verursacht zusätzliche Kosten, die in der Regel nicht durch Agenturangebote abgedeckt sind.

Wenn du eine Shopify-ERP-Integration in Betracht ziehst oder einen Shop-Merge planst, schau dir unsere Shopify-Services an und erfahre, wie wir solche Projekte angehen.

Lesetipp: Erfahre mehr über die Verbindung deines Shopify-Shops mit ERP-Systemen.

The post Dataforce (Palos) ERP-Konnektor Redesign & Shopify-Shop Merge: Rokker-Projektbeispiel appeared first on what. AG.