ServiceNow-zu-Jira-Service-Management-Transformation
MRI Software hat diesen Weg beschritten – von ServiceNow zu Jira Service Management – und kam mit einer einfacheren, kosteneffizienteren und leistungsfähigeren Umgebung heraus.
ITSM Migration vs Transformation
In sozialen Netzwerken teilen
ITSM-Migration vs. Transformation: Warum ein reiner Plattformwechsel oft keinen Mehrwert bringt
Zoi Raskou
Published on 30. Juli 2026
Zuletzt aktualisiert am: 24. August 2026
16 Min. Lesezeit
Zoi Raskou
Published on 30. Juli 2026
Zuletzt aktualisiert am: 24. August 2026
16 Min. Lesezeit
This blog explores why a simple migration often replicates existing inefficiencies, and how a transformation-led approach often delivers lasting business value.
Wenn Sie mit Ihrer aktuellen Service-Management-Plattform frustriert sind, haben Sie sich wahrscheinlich schon gefragt: Was nun? Vielleicht sind die Lizenzkosten kaum noch zu rechtfertigen. Vielleicht hat sich der versprochene Mehrwert Ihrer CMDB nie vollständig eingestellt. Vielleicht arbeiten Ihre Teams eher gegen das Tool als mit ihm. Was auch immer der Auslöser ist – die Entscheidung, vor der Sie stehen, betrifft nicht nur die Wahl der Plattform, sondern die Art und Weise, wie Sie den Wandel selbst angehen.
Diese Wahl ist wichtiger, als die meisten Führungskräfte annehmen. Und sie falsch zu treffen, gehört zu den teuersten Fehlern, die einem Unternehmen unterlaufen können.
Warum der Instinkt zur Migration oft zu kurz greift
Wenn Unternehmen sich entscheiden, von einer veralteten ITSM-Plattform wegzukommen, ist der natürliche Instinkt, dies als rein technische Aufgabe zu behandeln. Man bildet die bestehenden Prozesse ab, sucht die entsprechenden Funktionen im neuen Tool, überträgt die Daten, schult die Teams um und schaltet das System scharf. Dies wird gemeinhin als „Lift-and-Shift"-Migration bezeichnet – der häufigste Ansatz bei ITSM-Übergängen in Unternehmen.
Der Reiz ist nachvollziehbar: Migration fühlt sich risikoärmer an. Sie bewahrt das Bestehende, was Stakeholder beruhigt und die gefühlte Reibung eines Veränderungsprozesses vermeidet. Auf dem Papier wirkt es wie ein einfacher Weg von A nach B.
Doch hier liegt das Problem: Wenn Ihre aktuelle Plattform keinen Mehrwert liefert, ist nicht allein die Technologie der Grund dafür, dass Ihr Unternehmen zurückgehalten wird. Es sind die Prozesse, die darauf laufen, die eingefahrenen Gewohnheiten und die fehlende organisatorische Abstimmung darunter. Diese Prozesse und Gewohnheiten in ein neues Tool zu migrieren, behebt nichts davon. Es reproduziert lediglich die bestehenden Probleme in einer glänzenderen Umgebung – und bringt zusätzlich neue, unvorhergesehene Probleme mit sich. Diese können durch Kompatibilitätsunterschiede zwischen Quell- und Zielsystem oder durch Funktionsunterschiede entstehen. Sie haben für eine Transformation bezahlt, aber eine unvollständige oder mangelhafte Kopie geliefert bekommen.
Das Ergebnis ist vorhersehbar: Innerhalb von sechs bis zwölf Monaten äußern die Teams dieselben Beschwerden. Die Akzeptanz bleibt lückenhaft. Neue Frustrationen entstehen durch die Neuheit des Tools und dessen umständliche Funktionalität. Die Probleme mit der Datentransparenz sind nicht verschwunden. Und nun haben Sie ein beträchtliches Budget in ein Programm investiert, das nichts bewegt hat. Man könnte sogar argumentieren, dass sich die Lage verschlechtert hat.
Was bedeutet eine ITSM-Transformation wirklich?
Eine Service-Management-Transformation geht von einer grundlegend anderen Prämisse aus. Statt zu fragen „Wie bilden wir das Bestehende im neuen Tool ab?", fragt sie: „Wie sieht gutes Service-Management für unser Unternehmen aus, und wie bauen wir es auf?"
Der Fokus verschiebt sich von der Technologie hin zu den Ergebnissen: die Definition des zukünftigen Betriebsmodells, das Verständnis dafür, wie Services erbracht werden sollten, und die Festlegung der Erfahrung, die Unternehmen und Nutzer benötigen. Erst danach sollte überlegt werden, wie Tools, Prozesse und Automatisierung diese Vision ermöglichen können. Indem man mit den gewünschten Geschäftsergebnissen beginnt statt mit der technischen Umsetzung, vermeiden Unternehmen, bestehende Ineffizienzen in einer neuen Plattform zu reproduzieren, und schaffen stattdessen die Grundlage für nachhaltigen Erfolg.
Diese Unterscheidung mag philosophisch klingen, hat jedoch sehr praktische Konsequenzen dafür, wie das Programm strukturiert ist, wer beteiligt wird, wie lange es dauert und was es letztlich erreicht.
Eine Transformation begreift den Plattformwechsel als Chance für einen Neuanfang – nicht, um institutionelles Wissen zu verwerfen, sondern um über Jahre gewachsene Prozesse, Workflows und Konfigurationen zu hinterfragen und zu prüfen, ob sie dem Unternehmen wirklich noch dienen. Viele Unternehmen stellen fest, dass ein erheblicher Teil ihrer ITSM-Anpassungen nicht aus echtem geschäftlichem Bedarf entstanden ist, sondern weil jemand vor Jahren eine Lösung für einen Einzelfall oder ein isoliertes Problem gebaut hat – was sich im Laufe der Zeit summiert hat. Diese Anpassungen verursachen Wartungsaufwand, erschweren Upgrades und verschleiern oft, was ITIL-Best-Practices eigentlich empfehlen würden.
Transformation setzt dort an, wo Unternehmen heute stehen, und entwirft einen Weg dorthin, wo sie hinwollen – indem sie angehäufte Komplexität durchbricht. Sie vereinfacht, standardisiert und modernisiert zentrale ITSM-Prozesse, etabliert einen Ansatz, der den geschäftlichen Mehrwert in den Mittelpunkt stellt und ein Zurückfallen in übermäßige Individualisierung vermeidet – und schafft entscheidend die Voraussetzungen dafür, Fähigkeiten wie KI und Automatisierung zu nutzen, die saubere, strukturierte Daten und konsistente Arbeitsweisen benötigen, um wirklich zu funktionieren.
Nichts davon geschieht automatisch durch einen reinen Plattformwechsel. Es erfordert bewusste Planung, engagierte Stakeholder und einen strukturierten Veränderungsansatz.
Die Rolle des Organisatorischen Change Managements und warum es nicht verhandelbar ist
Von allen Elementen, die eine Transformation von einer Migration unterscheiden, ist keines wichtiger als Organisatorisches Change Management (OCM). Es ist zugleich das Element, das in technologiegetriebenen Programmen am häufigsten unterschätzt oder gänzlich übersprungen wird.
OCM ist mehr als ein Kommunikationsplan oder ein Schulungsprogramm. Es ist die nachhaltige, strukturierte Anstrengung und der Kulturwandel, um die Menschen mitzunehmen – indem man die Vision und die erwarteten Vorteile vermittelt – und so das Vertrauen, die Ausrichtung und die Fähigkeiten aufbaut, die eine dauerhafte Akzeptanz weit über den Go-Live hinaus sichern.
In der Praxis bedeutet das: die richtigen Stakeholder zum richtigen Zeitpunkt einzubeziehen. In Discovery-Sessions mit Führungskräften wird festgehalten, wie die Arbeit heute tatsächlich abläuft und welche Ergebnisse angestrebt werden. In Steering-Groups wird institutionelles Wissen erfasst und bewährte Elemente aus Tools und Prozessen eingewoben. Man hört den Teams zu – ihren Frustrationen, ihren Ideen, ihren Bedürfnissen.
Man arbeitet zusammen, bevor Konfigurationsentscheidungen getroffen werden, und webt das Feedback in die Lösung ein – man schafft gemeinsam Mehrwert. Am Ende geht es darum, iterativ eine Lösung zu entwickeln, die sich auf das konzentriert, was das Unternehmen erreichen will, und einen Weg zu definieren, der das Ergebnis sowie die langfristige Akzeptanz und Bestandsfähigkeit der Lösung sichert.
Der Grund, warum das so entscheidend ist: ITSM-Plattformen betreffen nahezu jeden im Unternehmen. Eine Änderung daran, wie Incidents gemeldet, Anfragen bearbeitet oder Changes genehmigt werden, hat Auswirkungen auf jedes Team, das auf IT-Support angewiesen ist – also praktisch jedes Team. Wenn die richtigen Personen nicht in die Gestaltung der neuen Arbeitsweisen eingebunden waren, werden sie diesen mit Widerstand begegnen. Und Widerstand im ITSM-Kontext ist keine bloße Unannehmlichkeit – er schlägt sich direkt in schlechter Akzeptanz, Workarounds und einer Verschlechterung der Datenqualität nieder, die den Wert der gesamten Investition untergräbt. Hinzu kommen die Kosten der Verzögerung und die Auswirkungen, die eine schlechte ITSM-Lösung auf die Produktivität des gesamten Unternehmens haben kann. Der Widerstand gegen Transformation kann zudem zu versteckten Kosten führen, die schwerer zu messen sind: Unternehmen verpassen die Chance zur Modernisierung und Innovation und bleiben nicht an der Spitze der Entwicklung. Die Technologie mag zwar live sein – doch die Transformation ist ins Stocken geraten, und die Chance wurde vertan.
Die fünf integrierten Phasen einer Service-Management-Transformation
Um zu verstehen, wie eine gut strukturierte Transformation in der Praxis aussieht, hilft es zu verdeutlichen, warum sie andere Ergebnisse liefert als eine Migration. Im Kern durchläuft ein Transformationsprogramm fünf klar definierte Phasen, die jeweils aufeinander aufbauen.
Onboarding legt das Fundament. In dieser Phase geht es zunächst um Menschen, nicht um Technologie: Man identifiziert, wen die Transformation im gesamten Unternehmen betreffen wird, baut durch strukturiertes Stakeholder-Engagement Vertrauen auf, bildet Steering-Groups mit der nötigen Entscheidungsbefugnis und stimmt Ziele ab, bevor überhaupt mit dem Lösungsdesign begonnen wird. Unternehmen, die diese Phase überspringen und direkt zur Plattformkonfiguration übergehen, bauen auf Sand. Ohne echte Abstimmung auf Führungsebene wird jede Design-Entscheidung zur Verhandlung, und jeder Go-Live zum Kampf um Akzeptanz.
Design folgt einem iterativen Modell, das sich auf Discovery konzentriert. Statt den Ist-Zustand zu dokumentieren und ihn andernorts nachzubauen, hinterfragt die Design-Phase bestehende Prozesse durch Decision Sprints und strukturierte Workshops, in denen das Team die Entscheidungen durcharbeitet, die das neue Service-Management-Modell definieren werden. Ziel ist nicht, die gewachsene Komplexität zu bewahren, sondern zu einer Lösung zu gelangen, die sich an dem orientiert, was das Unternehmen tatsächlich braucht – informiert durch ITIL-Best-Practices und die Möglichkeiten der Plattform. Diese Phase liefert klare Implementierungsanforderungen und ein Lösungsdesign, das von den Stakeholdern wirklich mitgestaltet wurde.
Implementieren und validieren folgt einem iterativen Ansatz, um sicherzustellen, dass die Lösung mit den Unternehmenszielen übereinstimmt. Die Konfiguration wird schrittweise aufgebaut, in User-Acceptance-Testing-Zyklen geprüft und auf Basis von direktem Feedback verfeinert. Dies ist keine lineare Abfolge von „erst bauen, dann testen", sondern ein Kreislauf: Feedback fließt in Änderungen ein, die erneut getestet werden, bevor es weitergeht. Das Ergebnis ist eine Plattformkonfiguration, die von den künftigen Nutzern validiert wurde – nicht nur von einem Projektmanager abgenickt.
Menschen befähigen ist die Phase, für die die meisten Migrationen kein wirkliches Äquivalent haben. Statt einer Standard-Endnutzerschulung in der Woche vor dem Go-Live investiert diese Phase in den Aufbau echter Kompetenz im Unternehmen – durch rollenbasierte Befähigung, Schulungen im Lösungsmanagement und den Aufbau des Selbstvertrauens, das Teams befähigt, die Plattform selbst zu verantworten, statt dauerhaft von externem Support abhängig zu sein. Das ist der Unterschied zwischen einem Team, das sein Service-Management-Modell bei veränderten Anforderungen selbst weiterentwickeln kann, und einem Team, das bei jeder Workflow-Anpassung ein Support-Ticket eröffnen muss.
Nutzenrealisierung schließt den Kreis. Ein Transformationsprogramm sollte Erfolg von Anfang an in messbaren Begriffen definieren – Produktivität, Kosten, Akzeptanzraten, KI-Bereitschaft – und dann aktiv gegen diese Kennzahlen verfolgen und berichten. Diese Phase stellt sicher, dass sich die Investition in die Transformation in dokumentierten, sichtbaren Ergebnissen niederschlägt, die den gewählten Ansatz rechtfertigen und die nächste Entwicklungsstufe informieren.
Wie Sie erkennen, ob Sie eine Migration oder eine Transformation brauchen
Nicht jedes ITSM-Projekt erfordert ein vollständiges Transformationsprogramm. Wenn Ihre bestehenden Prozesse gut gestaltet sind, Ihre Daten sauber sind und sich lediglich die zugrunde liegende Technologie ändern muss, kann eine gezieltere Migration angemessen sein. In der Praxis trifft diese Beschreibung jedoch auf sehr wenige große Unternehmen zu. Zudem hängt es von der Zielplattform ab – nicht alle Plattformen eignen sich für eine direkte Datenübertragung.
Die ehrlichen diagnostischen Fragen, die Sie sich stellen sollten, lauten:
Sind Ihre aktuellen Prozesse wirklich zweckmäßig, oder haben sich über die Jahre Workarounds und Ausnahmen angehäuft? Wenn Ihre Teams regelmäßig außerhalb des Tools arbeiten müssen – etwa per E-Mail, Excel-Tabellen oder informellen Kanälen –, ist das ein Zeichen dafür, dass das Prozessdesign nicht funktioniert, nicht nur die Plattform.
Haben Ihre Service-Management-Teams und die Fachbereiche, mit denen sie zusammenarbeiten, ein gemeinsames Verständnis davon, wie gute Leistung aussieht? Wenn IT und die übrige Organisation unterschiedliche Erwartungen an Service-Level, Reaktionszeiten und Erfüllungsprozesse haben, wird ein reiner Plattformwechsel diese Lücke nicht schließen – denn die Lücke ist nicht technologischer Natur.
Haben sich Ihre Führungskräfte darauf verständigt, was Service-Management erreichen soll – nicht nur im Sinne von Kostensenkung, sondern im Sinne von Geschäftsergebnissen? Transformationsprogramme sind dann erfolgreich, wenn sie von strategischer Absicht getragen werden. Wird das Programm ausschließlich von der IT verantwortet und rein als Kostensenkungsmaßnahme gerahmt, wird es auch so behandelt – und der breitere organisatorische Mehrwert bleibt ungenutzt.
Wenn die ehrlichen Antworten auf diese Fragen zugrunde liegende Probleme offenbaren, die über die Technologie hinausgehen, wird eine Migration diese nicht lösen. Eine Transformation schon. Diese Unterscheidung sollte man sich vor Augen führen, bevor man sich für einen Ansatz entscheidet. Wenn Sie keinen unvoreingenommenen Blick darauf werfen können, kann es sich lohnen, eine Discovery-Beratung bei einem vertrauenswürdigen Lösungspartner anzufragen.
Die Frage ist nicht nur, wohin Sie gehen, sondern: Wo wollen Sie als Unternehmen stehen?
Die Entscheidung, sich von einer veralteten ITSM-Plattform zu lösen, steht für immer mehr Unternehmen an. Die Kombination aus steigenden Kosten, begrenzter Wertschöpfung und nicht zugänglicher KI-Funktionalität veranlasst Führungskräfte, ihre bestehende Investition kritisch zu hinterfragen – und für viele lautet die ehrliche Antwort: Sie ist nicht mehr gerechtfertigt.
Doch der Wert der nächsten Entscheidung wird nicht davon abhängen, welche Plattform Sie wählen. Er wird davon abhängen, wie Sie den Übergang gestalten. Eine Migration bringt Sie auf eine neue Plattform. Eine Transformation bringt Sie zu einem besseren Betriebsmodell – einfacher, stärker standardisiert, unternehmensweit besser abgestimmt und wirklich in der Lage, die Möglichkeiten modernen Service-Managements zu nutzen.
Wenn Sie als Führungskraft Ihre Optionen bewerten, lautet die wichtigste Frage für dieses Gespräch nicht „Auf welches Tool sollten wir wechseln?", sondern: „Welche Art von Service-Management-Organisation wollen wir sein – und sind wir bereit, sie richtig aufzubauen?"
Verfasst von
Principal Technical Consultant