Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 16 Episoden

Zu spät, zu wenig, zu riskant – wie Datenmigration in SAP Projekten erfolgreich gelingt

Factory-Ansatz, kritische Erfolgsfaktoren und wie Unternehmen Migration skalierbar und sicher umsetzen

31.03.2026 20 min

Zusammenfassung & Show Notes

In dieser Folge spricht Gastgeberin Anita-Dora Andreadis mit SAP-Experte Michael Rubel über eines der kritischsten Themen in IT-Transformationen: Datenmigration.

Michael bringt über 19 Jahre Erfahrung aus großen SAP S/4HANA-Transformationen mit und teilt praxisnahe Einblicke in typische Herausforderungen. Ein zentrales Ergebnis: Rund 60–70 % aller digitalen Transformationen scheitern oder überschreiten Zeit- und Budgetziele deutlich. Hauptursachen sind dabei organisatorisches Change Management und unzureichend geplante Datenmigration.

Die Folge beleuchtet, warum Migration häufig zu spät adressiert wird, welche Risiken unterschätzt werden und wie sich diese Fehler konkret auf Projekte auswirken. Besonders spannend: Michael zeigt auf, dass Datenmigration kein rein technisches Thema ist, sondern tief in Prozesse, Organisation und Entscheidungsstrukturen eingreift.

Projektmanager erhalten konkrete Impulse, wie sie Migration strategisch früher einplanen, Risiken reduzieren und Transformationen erfolgreicher steuern können.

📢 Episode: Warum 70 % der SAP-Transformationen scheitern – und Migration der wahre Grund ist

🎙 Gast: Michael Rubel - SAP Management Consultant
🎙 Host: Anita-Dora Andreadis - Managing Director bei Sidekick Network

🎯 Thema: Datenmigration entscheidet über Erfolg oder Scheitern von S/4HANA-Projekten. Warum sie oft zu spät kommt, unterschätzt wird – und wie du sie strategisch richtig aufsetzt.

🔍 In dieser Episode erfährst du:

✅ Warum bis zu 70 % aller Transformationen scheitern oder massiv aus dem Ruder laufen
✅ Weshalb Datenmigration **kein IT-Thema**, sondern ein Business-Risiko ist
✅ Warum Migration in Projekten fast immer **zu spät eingeplant** wird
✅ Welche typischen Fehler beim Go-Live richtig teuer werden
✅ Wie der **Factory-Ansatz** Migration skalierbar und beherrschbar macht
✅ Warum standardisierte Templates und Vorstudien entscheidend sind
✅ Welche Rolle Timing (z. B. Jahreswechsel) für Projektrisiken spielt
✅ Drei konkrete Hacks, wie du Migration frühzeitig in den Griff bekommst

📌 Highlights & Kapitelmarken:

⏳ [00:00:04] – Intro & Begrüßung
👤 [00:00:25] – Vorstellung von Michael Rubel
🧠 [00:02:23] – Warum Datenmigration über Projekterfolg entscheidet
⚠️ [00:03:22] – Was schlechte Migrationen Projekte wirklich kosten
🏗️ [00:05:04] – Der Factory-Ansatz: Migration systematisieren
🌍 [00:08:13] – Parallele Rollouts effizient steuern
👥 [00:11:59] – Team, Tooling & Zusammenarbeit im Hybrid-Setup
🚀 [00:14:57] – Drei Smart Hacks für Projektmanager
🎯 [00:18:55] – Fazit & Verabschiedung

🔔 Folge uns, um keine Episode zu verpassen!

Mehr Infos zu Michael Rubel: https://www.linkedin.com/in/michael-rubel/
Mehr Infos zu Anita-Dora Andreadis: https://www.linkedin.com/in/anita-dora-andreadis/

Transkript

Hallo und herzlich willkommen bei Smartmax für IT Projektmanager. Präsentiert von Sidekick Network basiert unser Podcast auf der Erfahrung von über IT Projekten. Bist du bereit, direkt zum Punkt zu kommen? Dann lass uns starten. Ich habe in meiner Projektlaufbahn schon viele Dinge erlebt, aber kaum ein Thema sorgt so zuverlässig für lange Abende. Ich bin Anita. Schön, dass ihr wieder dabei seid bei SmartTax für IT Projektmanager. Über meinen heutigen Gast freue ich mich ganz besonders. Wir kennen uns schon ziemlich lange und ich erinnere mich noch an eine oder andere Herausforderung, die wir gemeinsam meistern mussten und gemeinsam in den Projekten erlebt haben. Herzlich willkommen im Michael Hubel. Hallo Anita, freut mich, dass wir heute sprechen. Ich denke, es sind circa zehn Jahre, wenn ich das grob überschlage, dass wir uns kennen. Ja, es sind sicherlich schon zehn Jahre, über zehn Jahre. Ich glaube, es müssten so circa 14, 15 Jahre mittlerweile schon sein, wo wir zusammen auf dem ERP Projekt unterwegs waren. Leicht unterschätzt. Kurz zu deiner Heute ist Michael SAP Management Consultant mit über 19 Jahre Erfahrung, großen SAP S HANA Transformation vom Anwendungsberater bis hin zum Projektleiter im Einsatz. Er war Principal bei BCG Platenien, hat zahlreiche Migrationsprojekte begleitet und in einem großen Transformationsprogramm einen spannenden Migrationsansatz mit aufgebaut. Das macht mich sehr neugierig und genau darüber sprechen wir heute und was Projektmanager besser machen können. Vor allem reden wir über das SAP Umfeld. Michael wie geht es dir heute? Mir geht es sehr gut. Anita, danke dir. Wir sind gerade mit einem spannenden Projekt am Ende der Hypercare Phase angelangt. Wir hatten gerade den Go Live jetzt zum Jahreswechsel und haben noch die letzten Themen ausgeräumt und das Projekt neigt sich langsam dem Ende. Von daher bin ich da sehr glücklich und zufrieden, dass es alles gut geklappt hat und blicke jetzt auf das nächste Jahr und hast heute Zeit. Ich freue mich sehr, dass du mein Gast bist. Steigen wir doch direkt ein, wenn du das Wort Migration hörst. Was ist dein erster Gedanke? Also beim Thema Migration denkt man natürlich sofort an große Transformationsprojekte, groß angelegte Projekte. Und da gibt es ein paar interessante Zahlen, die ich mal mitgebracht habe. Und zwar Laut Studien von McKinsey und auch BCG scheitern circa 60 bis 70 Prozent aller digitalen Transformation oder gehen zumindest weit über den Zeitplan und über das Budget heraus. Und wenn man da mal auf die Gründe schaut, dann sieht man, dass circa 40 Prozent, also eine der Hauptursachen für diese Themen, das Thema organisatorisches Change Management sind und Datenmigration. Und das heißt, da hat man schon die zwei großen Blöcke und Datenmigration sicherlich eins davon. Von daher ist es absolut wichtig, dass man sich dieses Thema bei großen IT Transformationen sehr gut anschaut. Wenn ich das so höre, was kostet das aus deiner Sicht, also jetzt nicht nur technisch, sondern gesamt auf das Projekt betrachtet? Beim Thema Datenmigration ist es natürlich so, wenn ich da auf größere Probleme stoße, hat das natürlich extreme Implikationen auf das Gesamtprojekt, denn ich rede dann meistens von einer Verschiebung. Bei kleineren Problemen kann es natürlich so sein, dass man vielleicht nur um einen sehr kurzen Zeitraum von ein paar Tagen etwas schieben muss, um vielleicht ein paar Fehler zu korrigieren und dann einen neuen Ansatz zu machen. Aber wenn ich wirklich größere Probleme feststelle in meiner Migrationskonzeption oder wirklich im Setup der Migration, dann werde ich bei einer Live Migration, wenn ich wirklich vom alten System aufs neue System gehen möchte, erstmal den nächsten geeigneten Zeitpunkt finden müssen, wann ich das überhaupt machen kann. Und das ist eben ein Thema, wo man nicht einfach eine Woche, zwei Wochen, drei Wochen mal eben in die Zukunft schaut und sagt, ach ja, dann mache ich es einfach noch mal, sondern ich muss wirklich einen passenden Zeitraum finden. Diverse Migrationen, Datenmigrationen werden ja gern zum Jahresende gemacht, zum Geschäftsjahresende. Das hat den Vorteil, dass man die Daten dann sauber übernehmen kann und dieses nächste Geschäftsjahresende kommt ja nicht einfach mal so um die Ecke, sondern man blickt dann durchaus weit in die Zukunft oder muss schauen, wann habe ich den nächsten Zeitpunkt, so einen passenden Abschluss zum Beispiel, wo ich das nochmal machen kann. Das bedeutet eben, man muss zum einen den Zeitpunkt sehr gut wählen, wann man das macht, zum anderen aber auch sehr gut vorbereitet sein, um auf diesen Zeitpunkt hinzuarbeiten. Ja, das klingt aufwendig, wir kennen das, aber dann könnte man fast sagen, dass Migration eigentlich eine ganz andere Art von Organisation benötigt. Wie könnte man Migration eigentlich aufsetzen, damit sie dann nicht jedes Mal neu erfunden wird? Da kann ich gerne ein Beispiel geben von einem Kunden, wo ich aktuell war und noch unterwegs bin. Und zwar ist es da so, dass wir genau die Situation uns da auch überlegt haben zum Kleinen. Der Kunde ist ein DAX 30 Unternehmen aus Deutschland, ist in der Energiebranche tätig und er hatte, wie so viele andere Kunden, Großkunden natürlich auch die Herausforderung vor einigen Jahren, dass das Thema S HANA Transformation anstand und der Kunde sich überlegt, wie komme ich von meiner alten Systemlandschaft im SAP auf die neue S HANA Landschaft. Und der Kunde hat sich dazu entschieden, dazu eine Vorstudie zu machen, das war im Jahr 2019 und dann in einem sogenannten Greenfield Ansatz, also wirklich ein neues Template aufzubauen, um dann seine zukünftige S HANA Landschaft aufzubauen. Das Ganze wurde eben so gemacht, dass man in dem ersten Jahr mal das Template aufgebaut hat, also die Prozesse, Datenstrukturen aufgebaut hat, die notwendig sind und danach natürlich überlegt hat, wie komme ich dann von diesem Template weiter in die weiteren Rollouts, wie seid ihr da genau die Migration angegangen. Wir hatten da natürlich die Thematik, dass wir im ersten Schritt in diesem ersten Jahr das Template aufgebaut haben, wie ich gerade sagte, und uns natürlich primär auf die erste Pilotgesellschaft fokussiert haben, die dort eben ausgerollt wurde auf die neue S HANA Landschaft. Während wir das gemacht haben, haben wir natürlich aber schon nachgedacht, wie wird es denn danach weitergehen. Der Kunde hat natürlich hunderte von weiteren Gesellschaften, die eben auch auf die SAP S HANA Plattform kommen müssen und daher hat man sich überlegt, man muss natürlich einen Ansatz finden, wo man in einem möglichst kurzen Zeitraum eine Vielzahl von Gesellschaften auf das neue Template holen kann und das Ganze ausrollen kann. In dem Zusammenhang hat man eben einen sogenannten industrialisierten Factory Ansatz sich ausgedacht, wo man sich natürlich dann nach dem ersten Jahr vom Fokus her etwas wegbewegt hat von dem Template, weil das ja bereits gebaut war, hat das Template eben dann stabilisiert bzw. Neuerungen reingebracht und hat dann eben ab dem zweiten Jahr, die Folgejahre, einen viel stärkeren Fokus eben auf das ganze Thema Rollout gelegt und damit einhergehend natürlich auch Migration, denn diese Themen oder die klassischen Querschnittsthemen in so einem Projekt wurden dann natürlich weitaus relevanter, dass man das entsprechend gut durchsetzen kann. Um das eben zu machen, wurde, wie gerade schon erwähnt, so ein industrialisierter Factory Ansatz aufgebaut. Das heißt, es gab für die Querschnittsthemen einzelne Teams, die sich mit diesen Themen befasst haben und da war es eben so, dass man zum einen ganzheitlichen oder einheitlichen Ansatz gewählt hat. Wie machen wir das, um das dann eben in den folgenden Jahren bei diesen einzelnen Gesellschaften umzusetzen? Michael Ich denke natürlich an komplexe Projekte. Sofort kommt mir natürlich die Wie könnte das bei einem Projekt aussehen mit vielen parallelen Rollouts? Ich denke, da spreche ich im Namen vieler Projektleiter, wenn ich auf das Thema eingehe. Ja, absolut. Und das ist auch genau die Situation, die wir hatten parallele Rollouts. Denn wir hatten natürlich in diesem Projekt diverse Gesellschaften pro Rollout Welle, teilweise weit über 100 Gesellschaften, die wir gleichzeitig live gesetzt haben und eben auch nationale und auch internationale Gesellschaften, Cluster, die wir gleichzeitig live gesetzt haben auf den neuen SAP Template. Das bedeutet, Parallelisierung von Rollouts war absolut gegeben von Anfang an. Dementsprechend haben wir das umgesetzt und genau dafür ist dieser Factory Ansatz so wichtig und auch wertvoll aus meiner Sicht. Denn um parallel Rollouts durchführen zu können, auch in mehreren Wellen hintereinander, ist es eben so wichtig, dass man das Ganze strukturiert und möglichst effizient angeht. Denn in so einem parallelen Rollout Setup ist es aus meiner Sicht nicht möglich oder nicht zielführend, wenn man viele einzelne Vorgehen und Methodiken hat, die man durchführt, sondern es muss halt einen Best Practice Ansatz geben, mit dem man das Ganze angeht, um das eben effizient umsetzen zu können. Wie ist deine heutige Sicht drauf? Es klingt aufwendig, es klingt jedoch sehr strukturiert. Was waren die eindeutigen Vorteile dieser Vorgehensweise? Der Vorteil aus meiner Sicht war ganz klar, dass man eben sehr klare und einheitliche Vorgehensweisen Wie gehe ich jetzt dieses Thema Datenmigration in diesen einzelnen Rollouts an? Weil wir hatten natürlich in diesen Rollout Wellen in den Jahren, die kamen, eine Vielzahl von Gesellschaften, auch mehrere Gesellschaften oder Cluster kann man es auch nennen, die gleichzeitig auf das S HANA Template kamen. Daher war es sehr, sehr hilfreich, dass wir eine einheitliche Vorgehensweise hatten, wie wir das Ganze gemacht haben. Also wie identifizieren wir die Migrationsobjekte, wie sie Migrationskonzept aus, wie werden die Mappings erstellt für Datenfelder und so weiter? Plus natürlich ein einheitlicher Projektplan, der war für alle Gesellschaften gleich und auch eine einheitliche Meetingkadenz und Vorgehensweise, also welche Meetings wird es geben? Wie wird das Ganze durchgeführt? Wie strukturieren wir das? Sodass man eben in jedem Jahr in jede Rollout Welle, in die man reingegangen ist, dieses Standard Framework nehmen konnte und das immer wieder anwenden konnte, was ich halt ausgezahlt hat dazu natürlich, und das ist auch einer mit der Hauptfaktoren, ein entsprechendes Team, was das Ganze umsetzen kann. Zum einen eben Experten von Kundenseite, die da wirklich sehr, sehr fit waren in den Themen, die das Ganze eben betreut haben, eben auch die Gesellschaften betreut haben, zum einen eben mit der Methodik, aber auch mit dem Wissen, wie eine Migration durchzuführen ist. Und dazu natürlich auch noch entsprechende technische Migrationsexperten, in diesem Falle waren die von der S P AG, das war Migrationstool, mit dem das Ganze gemacht wurde, die denen eben auch dann beiseite standen, um eben die technische Migration durchzuführen. Und so war es eben möglich, dass man die Gesellschaften, die auf das Template kommen sollen, von Anfang an in dieses Thema Migration direkt einbindet, ihnen eben die entsprechenden Vorgehensweisen und Methodiken an die Hand gibt, sodass man eben sehr effizient und auch in einem kurzen Zeitraum zu einem Migrationskonzept kommt und dann eben auch schon früh mit den ersten Testmigrationen anfangen kann, weil das natürlich dann mit Blick auf das Ende des Jahres, wo dann der sogenannte Go Live lag, das entsprechend gut vorbereiten konnte. Ich denke da gleich wieder parallel an meine Testfactory und an meine Test Camps, denn ich bin nach wie vor ein großer Fan von On-Site Phasen im Projekt und wenn ich das vergleiche im Testcamp, alle On Site und eine Art Factory, ich habe es meistens anders genannt, dann kam Corona, dann hatte ich eine Herausforderung und ich bin gespannt, wie du das siehst. Vor Corona, während Corona, nach Corona. Gib uns da doch mal ein paar Einblicke. Ja, sehr interessantes Thema, was du ansprichst, weil genau das hat uns da auch getroffen. Ich hatte es vorhin erwähnt, wir hatten die Vorstudie in 2019 gemacht, da war Corona noch nicht da und dann traf uns in 2020 voll die Corona Welle und davor war natürlich sehr viel on site, dann hatten wir die Lockdowns, da ging es gar nicht On Site und haben natürlich zum Remote Setting geswitcht und haben aber festgestellt, dass wir das auch hingekriegt haben. Das hat auch wirklich sehr gut funktioniert in dem Projekt, weil da alle an einem Strang gezogen haben. Und wir haben dann danach, also auch nachdem Covid dann vorbei war, größtenteils in einem hybriden Setting weitergemacht, aber auch in einem sehr stark Remote Setting, weil wir eben einige Personen on site hatten, die auch weiterhin on site waren, aber auch andere Experten, die von weiter weg kamen, beziehungsweise die sogar aus international kamen und wir daher eben gesagt haben, diese Personen können und auch wollen wir nicht die ganze Zeit dorthin holen. Von daher haben wir eben da ein Remote Setting gewählt und das hat wirklich sehr gut funktioniert, da wir ja teilweise dann auch, wie wir gerade schon sagten, parallele Rollouts hatten, national, international. Man kann ja nicht überall gleichzeitig sein, gerade wenn man Termine oder Workshops macht mit diversen Clustern, die auch international sind. Das heißt, da muss man sowieso ein Remote Setting wählen. Und von daher war es für uns zum einen eine Herausforderung, urplötzlich in das Remote Setting zu switchen, haben uns da aber sehr gut zurechtgefunden, Das gesamte Team hat sich ja sehr gut zurechtgefunden und haben es dann tatsächlich danach sehr stark weitergelebt mit diesem Remote Setting und das hat eben auch mit dem Factory Ansatz sehr gut funktioniert. Ich finde das Thema so interessant, auch in unserem Vorfeld, in unseren Gesprächen, die wir hatten, habe ich ja gleich sehr großes Interesse gehabt und freue mich sehr, dass wir darüber sprechen, denn ich hatte das im Vorfeld schon erwähnt, dass ich Testfactory kenne und ein großer Fan davon bin und das für mich auch sehr viel Sinn macht, das für eine Migration zu machen, habe ich in der Form jedoch noch selbst nicht erlebt und da begeistert mich das sehr. Wenn uns jetzt jemand zuhört, Michael, und vielleicht gerade in einem Rollout steckt oder am Anfang setzt gerade ein Programm auf, wie du auch gesagt hast, vielleicht SAP Greenfield oder auch eine andere Vorgehensweise. Welche drei konkreten Smart Tags würdest du zu dem Thema mitgeben? Also meine drei konkReten SmartTags für das Thema Datenmigration wären erstens Migration von Anfang an betrachten. Das bedeutet, dass ich mich um das Thema Datenmigration nicht erst in einem späteren Projektverlauf kümmere oder im späteren Verlauf einer Rollout Welle, sondern wirklich von Anfang an einer Rollout Welle das Thema Datenmigration schon in meinem Projektplan habe und dementsprechend auch schon die relevanten Beteiligten damit einbeziehe. Also in der SAP Activate Methodik zum Beispiel wäre das in der Explore Phase, wo man schon direkt eben dann mit dieser Migration Factory, die wir etabliert haben, in die Gesellschaften hineingeht, mit denen Migrationsworkshops macht, den Migrationsscope abklärt und dann eben zu einem sehr frühen Zeitpunkt schon die Konzepte entsprechend überarbeiten kann, Mappings erstellen kann, sodass man dann eben vorbereitet ist, auch da wieder früh im Jahr eine erste Testmigration zu machen, um zu schauen, ist das, was man definiert hat, auch wirklich korrekt, wo muss man noch Anpassungen vornehmen, damit man dann eben zum Ende des Jahres den Go Live bestmöglich über die Bühne bekommt. Der zweite smarttag, den ich gerne mitgeben würde, ist das Thema frühe und klare Toolselektion. Mit Tool meine ich das Datenmigrationstool, also mit welchen Werkzeugen kann oder möchte ich denn die Daten aus meinem Quellsystem in das Zielsystem bringen. Da gibt es eine Vielzahl sowohl von SAP selber, aber auch von Drittanbietern, wie ich vorhin erwähnte. Bei uns in dem Fall wurde es mit der S P Crystal Bridge gemacht. Und das ist eben ein Thema, was man auch sich sehr früh im Projektverlauf schon in der Vorstudie überlegen sollte. Denn die Frage ist Reicht ein Tool? Muss ich vielleicht mehrere Tools nehmen, weil ich verschiedene Anforderungen oder verschiedene Vorsysteme habe, wo andere Tools besser passend sind und sich da sehr gute Gedanken dazu machen, um das einmal festzuzurren, um es eben dann auch im Verlauf aller Rollout Wellen durchzusetzen. Denn wenn ich einen Factory Ansatz leben möchte und hier in dem Fall einer Migration Factory, dann muss eben auch die Methodik, aber auch das Tooling von Anfang an klar sein, damit ich da sehr effizient von Rollout Welle zu Rollout Welle gehen kann. Den dritten smarttag, den ich gerne noch mitgeben würde, der hört sich einfach an, der ist aber leider oft auch sehr schwer Experten suchen und diese fürs Projekt gewinnen und begeistern. Warum hört er sich einfach an? Es ist natürlich schwierig, Personen zu finden, die sich in der Datenmigration gut auskennen, die Themen sowohl fachlich als auch technisch verstehen, bewerten und interpretieren können. Denn das ist auch ein Thema gerade bei so einem Factory Ansatz. Man braucht natürlich die entsprechenden Experten, die dann in jeder Rollout Welle diese Gesellschaften, auf die das Template ausgerollt wird, an die Hand nehmen sozusagen und mit denen eben durch das Projekt durchgehen, denen die Migration erklären und denen eben auch das nötige Wissen an die Hand geben, wie die Datenmigration laufen wird und wo man vielleicht noch Veränderungen vornehmen muss, damit es eben gut funktioniert. Und daran angrenzend natürlich das Thema Früher sagte man immer üben, üben, üben in diesem Falle würde ich sagen, testen, testen, testen. Auch das ist ein Thema, kann man nicht oft genug sagen. Je früher man eine Testmigration machen kann, desto besser. Denn je früher ich Fehler finde, sei es in meiner Konzeption, sei es in meinem Mapping, desto schneller kann ich darauf reagieren und eben entsprechend zum Go Live hin meine Datenqualität immer weiter verbessern. Michael, ich bedanke mich sehr bei dir. Manchmal hören sich Themen wie rechtzeitig testen doch so ein bisschen banal an, aber genau das, das muss immer wieder bedacht werden, ganz am Anfang eines Projekts. Ja, ich muss bereits sehr früh mit diesen Themen starten und manchmal braucht man einfach nur wieder mal so einen Impuls oder einen Schlag von jemandem und das zu hören. Deswegen, wenn wir mit deinen Smart Hacks vielleicht den einen oder anderen langen Abend vermeiden könnten, dann ist das bereits ein guter Impuls und vielleicht konnten wir damit auch so paar Ideen, die eine oder andere Ideen bei einigen Projektleitern und dann bei Migrationsverantwortlichen anstoßen. Das würde mich sehr freuen. Vielen Dank, dass du mein Gast warst. Ganz herzlichen Dank für die Einladung. Hat mich sehr gefreut, dass wir heute über das Thema sprechen konnten. Danke dir. Und wir haben bereits beim Brainstorming der Themen Ideen gehabt für ein weiteres Thema. Daher freue ich mich sehr, wenn wir uns mal beim nächsten Thema wiedersehen. Im Augenblick. Vielen Dank fürs Zuhören. Ich freue mich, wenn wir uns im nächsten Podcast wieder begegnen. Bis bald, eure Anita Dora Andreadis.