--- title: "Nutzer-Migration auf eine neue Software-Version (2026)" description: "Wie migrierst du B2B-Nutzer auf eine neue SaaS-Version? Acht Regeln: Kernfunktionen zuerst, Wechsel mit einem Klick, Recht früh klären, Kunden mitnehmen." url: "https://www.maltelandwehr.de/articles/user-migration/" lang: de --- # Wie migriert man Nutzer auf eine neue Software-Version? Tipps und Tricks für B2B-Unternehmen, die ihre Nutzer auf eine neue Version ihrer SaaS-Lösung migrieren wollen. By Malte Landwehr, veröffentlicht Juli 2020, zuletzt aktualisiert 14. Oktober 2026 ## Zusammenfassung Die beste Migration ist eine, die deine Nutzer gar nicht bemerken. Kontinuierliche Verbesserung ist einem Relaunch immer vorzuziehen. Wenn ein Relaunch doch nötig ist, helfen ein paar Regeln. Bau keine neuen Features mehr für die alte Version. Portiere die wichtigsten Features und Workflows zuerst. Mach den Wechsel mit einem Klick möglich. Kläre Recht und Infrastruktur früh, nimm Kunden, Sales und Support mit und mach die Migration zum Ziel der ganzen Firma. Contents 1. [Für wen ist dieser Artikel?](#fuer-wen) 2. [Woher kommt meine Erfahrung?](#erfahrung) 3. [Was ist die beste Migration aus Nutzersicht?](#beste-migration) 4. [Welche Regeln helfen bei der Nutzer-Migration?](#tipps) 1. [Nicht alles neu bauen](#nicht-alles-neu) 2. [In welcher Reihenfolge du portierst](#reihenfolge) 3. [Den Wechsel so leicht wie möglich machen](#wechsel) 4. [Recht und Infrastruktur früh klären](#recht-infrastruktur) 5. [Kunden und Kollegen mitnehmen](#kunden-kollegen) 6. [Die Migration company-weit steuern](#company-weit) 7. [Nicht jedes Feature muss mitkommen](#nicht-jedes-feature) 8. [Namen und interne Kommunikation](#namen) 5. [Alle Regeln im Überblick](#ueberblick) ## Für wen ist dieser Artikel? Die Tipps sind primär aus Product-Management-Sicht geschrieben. Die Gedankengänge und Konzepte sind aber auch für (Technologie-)Entscheider relevant. ## Woher kommt meine Erfahrung? Bei Searchmetrics war ich an der Migration der Searchmetrics SEO Suite zur Searchmetrics SEO & Content Suite beteiligt. Die neue Suite hatte ein neues Backend und ein neues Frontend. Bei Searchmetrics haben wir außerdem das eigene Rechenzentrum nach AWS migriert. Bei idealo gab es ebenfalls eine Migration vom Rechenzentrum nach AWS. Die Regeln unten beruhen auf diesen Erfahrungen. ## Was ist die beste Migration aus Nutzersicht? Im Idealfall ist - aus Nutzersicht - gar keine Migration notwendig. Stattdessen wird primär unter der Haube geschraubt und viele kleine Verbesserungen werden Schritt-für-Schritt implementiert. Kontinuierliche Verbesserung ist einem Relaunch immer vorzuziehen. Deine Nutzer müssen nichts neu lernen, und jede Verbesserung ist sofort in Produktion statt erst am Ende eines mehrjährigen Projekts. 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 Software Suite. ## Welche Regeln helfen bei der Nutzer-Migration? ### Nicht alles neu bauen **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ößerst du damit nur die Liste der Features, die du auf die neue Version portieren musst. Wenn Version 1 (v1) bereits ein funktionierendes Produkt mit **glücklichen Kunden und Product-Market-Fit** ist, erfinde für v2 nicht das Rad neu. **Verwende so viel wie möglich wieder** - sowohl auf technischer Seite (Datenbanken, Backendservices, APIs), als auch aus Produkt-Sicht (Navigationskonzepte, Layouts, Flows, Bezeichnungen, Tooltips). Die schnellste Migration ist eine 1-zu-1-Kopie mit einem hübscheren Frontend. Dazu packst du immer mal wieder ein oder zwei Verbesserungen, die Nutzer regelmäßig angefragt haben. Wenn jedes Feature in v2 ein bisschen besser ist – und irgendwo 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**. Die Altlasten sind ohnehin der Grund, warum v1 nicht mehr funktioniert. 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! ### In welcher Reihenfolge du portierst Fokussiere dich nicht auf große **Innovationen** bevor die **Kernfunktionalität** nicht portiert ist. Solange ein Nutzer seine tägliche Arbeit in v2 nicht erledigen kann, ist ihm jede neue Idee egal. 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. ### Den Wechsel so leicht wie möglich machen 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. Ein komplett neuer Registrierungsprozess für die neue Version ist ein NoGo und wird die Migration deiner Nutzer massiv verlangsamen. Überall, wo du auf deinen Login verweist (www-Website, Blog, E-Mails, QR-Code, Single sign-on Integrationen) solltest du auf den **Login zur neuen Version** verweisen. Jeder Link auf die alte Version ist eine Einladung, dort zu bleiben. ### Recht und Infrastruktur früh klären 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 (z. B. Version 1 zu Version 2) mit einer technischen Migration (zum Beispiel von eigener Hardware zu AWS) verbindest, plan **für den Übergang ein deutlich größeres IT-Budget** als sonst ein. ### Kunden und Kollegen mitnehmen Im Enterprise-Software-Segment ist der Aufwand um einen Kunden nach vielen Jahren der Nutzung an eine neue Software-Version zu gewöhnen, **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](https://www.walkme.com/). **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 den 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 sich 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 Trainings** 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. So erreichst du viele Nutzer gleichzeitig, statt jedes Onboarding einzeln zu machen. - **Live-Webinare** sorgen für mehr Zeitdruck und FOMO (*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 gib dann allen Kunden einen „exklusiven“ **100% Voucher**. Kostenlose Kurse macht niemand. Einen Kurs, der eigentlich Geld kostet und den der Kunde geschenkt bekommt, schon. ### Die Migration company-weit steuern 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) kannst. Wenn du OKRs (oder OWKRs) benutzt, mach die **Migration zum Objective für die ganze Company**. Es ist keine reine Produkt-Management- oder Customer-Success-Aufgabe sondern ein Kraftakt für die gesamte Unternehmung. ### Nicht jedes Feature muss mitkommen Bau nicht alles neu. Reddit ist ein super Beispiel. Einige Features - 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. ### Namen und interne Kommunikation 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- und Services-Kollegen** für die neue Version zu sorgen, ist es ein super Instrument die ersten Erfolge zu zelebrieren. 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. ## Alle Regeln im Überblick 1. [Nicht alles neu bauen](#nicht-alles-neu) 2. [Die wichtigsten Features zuerst portieren](#reihenfolge) 3. [Den Wechsel so leicht wie möglich machen](#wechsel) 4. [Recht und Infrastruktur früh klären](#recht-infrastruktur) 5. [Kunden und Kollegen mitnehmen](#kunden-kollegen) 6. [Die Migration company-weit steuern](#company-weit) 7. [Nicht jedes Feature mitnehmen](#nicht-jedes-feature) 8. [Namen vor der internen Kommunikation festlegen](#namen) ![Malte Landwehr](https://www.maltelandwehr.de/assets/img/malte-landwehr-author-192.jpg) [Malte Landwehr](https://www.maltelandwehr.de/) is an expert in Enterprise SEO and AI search with 20+ years of experience. [Speaker profile](https://www.maltelandwehr.de/speaker/)