User Migration auf neue Software Version

Tipps und Tricks für B2B-Unternehmen, die ihre Nutzer auf eine neue Version ihrer SaaS-Lösung migrieren wollen.

Warum dieser Artikel?

Das hier ist die längere Version eines Reddit-Kommentars von mir in r/ProductManagement, der relativ viel Aufmerksamkeit bekommen hat. Die Tipps sind primär aus Product-Management-Sicht geschrieben, jedoch nicht darauf beschränkt.

Die beste Migration

Im Idealfall ist gar keine Migration notwendig. Stattdessen wird primär unter der Haube geschraubt und viele kleine Verbesserungen werden Schritt-für-Schritt released. Kontinuierliche Verbesserung ist einem Relaunch immer vorzuziehen. Leider ist das manchmal aus technischen Gründen nicht möglich. Oder wenn sich Usability und Navigationskonzepte grundlegend ändern. Oder bei der Übernahme und Integration einer SaaS-Lösung in eine größere Suite.

Die Tipps

Keine neuen Features für die alte Version. Alles was neu gebaut wird, wird nur für die neue Version gebaut. Punkt. Es ist verlockend hier und da noch Quickwins umzusetzen. Aber am Ende vergrößerts du damit nur die Liste der Features, die du auf die neue Version portieren musst.

Wenn v1 bereits ein funktionierendes Produkt mit glücklichen Kunden und Product-Market-Fit ist, erfinde für v2 nicht das Rad neu. Verwende soviel wie möglich neu. Sowohl auf technischer Seite (Datenbanken, Backendservices, APIs), als auch aus Produkt-Sucht (Navigationskonzepte, Layouts, Flows, Bezeichnungen, Tooltips). Die schnellste Migration ist eine 1-zu-1-Kopie mit einen hübscheren Frontend. Dazu schmeißt du immer mal wieder 1 bis 2 Verbesserungen, die Nutzer regelmäßig angefragt haben. Wenn jedes Feature ein bisschen besser ist – und irgendwie ein paar größere Neuerungen schlummern – sind deine Kunden mehr als glücklich.

Sollte v1 nicht (mehr) gut funktionieren, ist der Relaunch die perfekte Möglichkeit alles umzuschmeißen und Grundlagen nochmal komplett neu zu denken. In diesem Fall solltest du einplanen, dass eine komplette Neuentwicklung genau so lange dauert, wie die Entwicklung der ursprünglichen v1. Und manchmal sogar länger weil du parallel weiterhin Support und Bugfixing für v1 machen musst.

Fokussiere dich nicht auf große Innovationen bevor die Kernfunktionalität nicht portiert ist.

Ermittle für alle Features, wie wichtig sie sind. Zum Beispiel über die Intensität und Häufigkeit der Nutzung. Oder über Interviews. Portiere dann die wichtigsten Features und Workflows zuerst.

Zuallererst würde ich jedoch 2 oder 3 Features von mittlerer Wichtigkeit portieren. Als Test und um zu lernen.

Für 90% deiner Nutzer sollte mindestens ein absolutes Key-Feature in der neuen Version mindestens 50% besser als in der alten Version sein. So erreichst du, dass Nutzer wechseln wollen.

Stell sicher, dass Nutzer mit einem Klick zwischen der alten und der neuen Version wechseln können, ohne sich erneut einloggen zu müssen. Das erhöht die Wechselbereitschaft enorm.

Überall, wo du auf deinen Login verweist (www-Website, Blog, E-Mails, QR-Code, Single sign-on Integrationen) solltest du auf den Login zu neuen Version verweisen.

Integriere dein Legal-Team so früh wie möglich. Manchmal sind einzelne Features vertraglich zugesichert. Eine Software als neu zu bezeichnen kann ein Sonderkündigungsrecht auslösen, usw.

Die rechtlichen und vertraglichen Rahmenbedingungen so früh wie möglich zu kennen, erspart später viel Stress!

Falls es zu Infrastruktur-Änderungen kommt, plane weise und verschaff dir viel Flexibilität. Nichts ist schlimmer als ein ungenutztes Server-Cluster noch 11 Monate bezahlen zu müssen oder sich bei einem Cloud-Anbieter zu früh zu hoch zu committen.

Grundsätzlich gilt: Wenn du eine Produkt-Migration (zB Version 1 zu Version 2) mit einer technischen Migration (zum Beispiel von eigener Hardware zu AWS) verbindest, plan für den Übergang ein deutliches größeres IT-Budget als sonst ein.

Der Aufwand um einen Kunden nach vielen Jahren der Nutzung an eine neue Software-Version zu gewöhnen, ist genau so groß wie der initiale Onboarding-Aufwand. Denn jeder Nutzer muss nicht nur die neue Version kennenlernen sondern auch die alte Verlernen. Viele Customer Success und professional Services Organisationen sind nicht darauf eingestellt auf einmal das x-fache an Onboardings zu bewältigen. Hier ist es wichtig smarte 1-zu-n Lösungen zu finden, wie Self-Onboarding in der Software mit Lösungen wie WalkMe.

Inkludiere wichtige Kunden so früh wie möglich. Zeig ihnen bei einem QBR wie die neue Version aussehen wird. Gib ihnen einen Beta-Zugang. Nenn sie Early Adopter, damit sie sich gut fühlen. Und – ganz wichtig – hör ihnen zu. Wenn 9 von 10 Kunden die neue Version scheiße finden, sollte dir das zu denken geben! Nicht immer ist eine vermeintliche Verbesserung gut.

Power User zu migrieren ist einfach, da sie schnell der Wert der verbesserten Features erkennen. Problematisch sind die Nutzer, die sich nur einmal im Monat einloggen um einen bestimmten Task auszuführen. Diese haben die Software oft gar nicht verstanden sondern haben sie nur die 4 oder 5 Klicks gemerkt, die sie brauchen um die KPI fürs monatliche Reporting zu finden. Diese Nutzer werden dir die meisten Kopfschmerzen bereiten und bis zum Ende an v1 festhalten.

Sowohl Sales, als auch Customer Support, benötigen Material und Trianings um für jedes Feature erklären zu können was sich in v2 geändert und – ganz wichtig – was sich verbessert hat.

Veranstalte viele Webinare für Top x Use Cases in v2 für verschiedene Zielgruppen oder Personas.

  • Live-Webinare sorgen oft für mehr Zeitdruck (ich muss mir das jetzt anschauen) und erlauben Interaktivität durch Rückfragen.
  • Aufzeichnungen haben den Vorteil, dass man die Videos häppchenweise in einem Helpcenter anbieten oder ggf. sogar über Social Media spielen kann.

Biete eine Zertifizierung als Online Kurs für v2 an. Mach sie angemessen teuer und gebe dann allen Kunden einen "exklusiven" 100% Voucher.

Vom C-Level muss es eine klare Richtlinie geben ob die Migration möglichst schnell stattfinden soll oder ob man sich 1-2 Jahre Zeit lässt und damit eine Preiserhöhung durchdrückt. Der Vorteil der schnellen Migration ist, dass du etwaige Churn-Probleme schneller in den Griff bekommst und Infrastruktur schneller abschalten (und somit die IT-Kosten senken) kann.

Wenn du OKRs (oder OWKRs) benutzt, mach die Migration zum Objective für die ganze Company. Es ist keine Produkte-Management- oder Customer-Success-Aufgabe sondern ein Kraftakt für die gesamte Unternehmung.

Bau nicht alles neu. Reddit ist ein super Beispiel. Einige Featurs - wie Karma pro Subreddit -  sind auch Jahre nach dem Relaunch nur im alten Layout verfügbar. Warum? Weil sie für die Core-Experience der Plattform nicht notwendig sind und nur von wenigen Usern genutzt werden. Und diese Nutzer sind bereit, den Bruch in Design- und Navigation zu akzeptieren.

Wenn du in der Kunden-Kommunikation bessere Namen als alte und neue Version oder Version 1 und 2 verwenden willst, finde diese Namen bevor du intern kommunizierst. Sobald alle Mitarbeiter sich an Version 1 und 2 gewöhnt haben, werden sie diese auch in der Kundenkommunikation benutzen. Um das zu verhindern ist es manchmal sinnvoll total absurde interne Namen wie Hulk Hogan zu verwenden. Dann ist jedem klar, dass es ein Working-Title ist.

Um für Begeisterung bei Sales and Services Kollegen für die neue Version zu sorgen, ist es ein super Instrument die ersten Erfolge groß zu highlighten. Sobald ein großer Kunde mit Wechsel von v1 auf v2 vom Churn-Risiko zum Aktivitäts-Champion wurde, werden viele Kollegen den Wert der neuen Version erkennen.