S/4Hana Selective Data Transition: Der flexible Weg – mit versteckten Fallstricken
01.07.2025 19 min
Zusammenfassung & Show Notes
In dieser Folge von Smart Hacks für IT-Projektmanager spricht Anita-Dora Andreadis mit der SAP-Expertin Alexandra Lügger über den komplexen Umstieg von SAP ECC auf S/4HANA mittels Selective Data Transition (SDT). Dabei werden die Unterschiede zwischen Shell Conversion und Mix-and-Match-Ansätzen erläutert. Alexandra teilt ihre praktischen Erfahrungen, beleuchtet typische Herausforderungen – insbesondere bei Systemlandschaft, Datenmigration und Testplanung – und gibt konkrete Handlungsempfehlungen für eine erfolgreiche Projektumsetzung. Besonders hilfreich: eine mitgebrachte Checkliste zur Systemplanung sowie klare Tipps zur Vermeidung häufiger Fehler.
📢 Episode: Selective Data Transition – So gelingt der smarte Umstieg auf SAP S/4HANA
🎙 Gast: Alex – SAP-Projektleiterin & SDT-Praktikerin
🎙 Gastgeberin: Anita-Dora Andreadis - Managing Director Sidekick Network GmbH
🎯 Thema: Warum die Selective Data Transition der Mittelweg zwischen Greenfield und Brownfield ist – und worauf es wirklich ankommt.
🎙 Gast: Alex – SAP-Projektleiterin & SDT-Praktikerin
🎙 Gastgeberin: Anita-Dora Andreadis - Managing Director Sidekick Network GmbH
🎯 Thema: Warum die Selective Data Transition der Mittelweg zwischen Greenfield und Brownfield ist – und worauf es wirklich ankommt.
🔍 In dieser Episode erfährst du:
✅ Was genau Selective Data Transition ist und wie sie sich von Shell Conversion und Mix & Match unterscheidet.
✅ Welche Vorteile dieser Ansatz Unternehmen bei der S/4HANA-Umstellung bietet.
✅ Welche Stolpersteine in Planung, Test und Systemlandschaft auf dich warten – und wie du sie vermeidest.
✅ Warum Fiori in der Conversion-Phase oft zum Problem wird – und wie du smarter damit umgehst.
✅ Bonus: Eine praktische Checkliste zur Planung deiner Systemlandschaft! (siehe unten)
📌 Highlights:
⏳ [00:00] – Begrüßung & Intro
🔄 [00:30] – Selective Data Transition: Was steckt dahinter?
📈 [02:00] – Gründe für SDT & typische Szenarien
🚧 [04:00] – Herausforderungen & Fehlerquellen aus der Praxis
🧪 [06:00] – Teststrategie & Systemlandschaft: Drei Zyklen, klare Struktur
🖥️ [12:00] – Fiori-Falle & Entwicklungskomplexität
🍬 [14:30] – „Kind im Bonbonladen“: Fokus statt Feature-Overload
✅ [17:00] – Drei Hacks + Checkliste für die Planung (sieh unten)
👋 [18:30] – Abschluss & Ausblick
🎧 Jetzt reinhören & deine SAP-Projekte smarter machen!
🔔 Abonniere den Podcast, um keine Episode zu verpassen! 🚀
Mehr Infos zu Alex: https://www.linkedin.com/in/alexandra-l%C3%BCgger-5aa081178/
Mehr Infos zu Sidekick Network: https://www.linkedin.com/company/sidekick-network/
CHECKLISTE: „Sicht eines Projektleiters auf die Systemlandschaft einer S4 Conversion“:
Umfang der S/4 Hana Systemlandschaft:
- Wie viele Systeme werden über die gesamte Projektlaufzeit benötigt werden?
- Wie viele Mandanten soll es in den Systemen geben?
- Soll die S/4 Hana Landschaft eine Drei- oder Zwei-System Landschaft werden?
- Wann wird das produktive S/4 System aufgebaut?
- Entwickelt sich die S/4 Landschaft zum GoLive ggf. zu einer Drei-System-Landschaft?
- Tipp: eine einfache Übersicht der Systeme und Mandanten für die jeweiligen Aktivitäten ist hilfreich 😉
Anforderungen aus den Testzyklen:
- Wie viele Testzyklen sollen durchgeführt werden?
- Sollen die Testzyklen aus jeweils Datenmigrations- und Funktionstests in separaten Systemen durchgeführt werden?
- Sind ggf. unterschiedliche Mandanten ausreichend?
- Was soll in welchem System / Mandanten wann erfolgen?
- Welche Systeme werden als Basis für die Datenmigrationstests genutzt?
- Müssen diese ggf. mit Daten aus einem Produktivsystem aktualisiert werden?
- Ist es erforderlich, Systemverbindungen zwischen Quell- und Zielsystemen aufzubauen?
Zeitlicher Vorlauf:
- Werden die Systeme durch das Unternehmen selbst oder durch einen Provider zur Verfügung gestellt?
- Sind es On Premise Systeme oder erfolgt die Migration in ein Cloud System?
- On Premise Systeme zusätzlich: Ist ausreichend Hardware vorhanden oder muss weitere Hardware beschafft werden?
- Welcher zeitliche Vorlauf wird benötigt, um die Systeme oder die Mandanten aufzubauen? ○ Dauer der Beschaffung von Hardware
- Vorlaufzeiten / Anmeldezeiten bei IT oder Provider
- Dauer für den Systemaufbau durch IT oder Provider
- Dauer der Einbindung in die Transportlandschaft
Anforderungen an das Transportwesen:
- In welchem System erfolgt die Custom Code Adaption?
- Wie werden die Daten aus dem ECC-System in das S/4 Hana System übertragen? ○ Ist ein Retrofit Prozess implementiert?
- Wer sichert die Qualität des Retrofits ab?
- Wie sehen die Transportfreigaben / Transportfenster für die Vorbereitung der Tests aus, d.h. auf welchem Stand der Projektarbeit kann der jeweilige Test erfolgen?
- Ab wann kann die Weiterentwicklung auf dem ECC System gestoppt werden? ○ Spätestens zum Start des 3. Testzyklus sollten alle Entwicklungen auf dem ECC System abgeschlossen und in das S/4 Hana System übertragen worden sein.
Transkript
One, two, three, four.
Hallo und herzlich willkommen bei Smart
Hacks für IT Projektmanager,
präsentiert von Sidekick Network basiert
unser Podcast auf der Erfahrung
von über 20.000 IT Projekten.
Bist du bereit?
Direkt zum Punkt zu kommen?
Dann lass uns starten.
Herzlich willkommen zu einer neuen
Folge von Smart City Breakbridge.
Ich bin Anita und heute geht es um eine
spannende Herausforderung in der SAP Welt.
Der Umstieg von S vier Hana auf Selective
Data Transition, auch bekannt als
Shell Conversion oder Mixer Match.
Da gibt es noch ein paar Unterschiede,
aber das wird uns mein
heutiger Gast erklären.
Alex Ich freue mich sehr, dass du da bist.
Sie hat bereits mehrere SAP Projekte
geleitet, hat bereits SV Hana Projekt
genau mit diesem Ansatz
erfolgreich umgesetzt.
Ich spreche mit dir über Stolperfallen,
über Herausforderungen und
wie man diese meistern kann.
Wir erhalten sehr wertvolle
Einblicke aus der Praxis.
Und natürlich gibt es wieder ein paar
Hacks von uns, die wir
am Ende mitnehmen können.
Ich freue mich sehr auf
einen spannenden Podcast.
Ich freue mich darauf, selber was zu
lernen und es wird sicherlich
sehr aufschlussreich.
Daher, lieber Alex, herzlich willkommen!
Schön, dass du da bist.
Hallo Anita.
Danke, dass ich da sein darf.
Alex was genau ist mit Selective Data
Transition im SV Hana Kontext gemeint?
Ich habe gerade schon mal angedeutet, dass
es da doch ein paar Unterschiede
gibt mit den ganzen Begriffen.
Es sind, ja, es kursieren ja diverse
Begriffe im Internet, in Unternehmen, in
Dokumenten zwischen
Menschen, Projektleiter.
Das ist für mich auch oft schwierig.
Ist da den Unterschied zu verstehen.
Daher Selective data Transition.
Kurz die Vorteile dieses Ansatzes.
Da würde ich mich freuen
für eine kurze Erläuterung.
Genau.
Also wichtig ist Bei der Selective Data
Transition werden existierende
Systemeinstellungen weiterverwendet.
Je nachdem, ob du mehr mitnehmen möchtest
von dem, was im System existiert.
Oder du sagst, ich möchte mir
gewisse Funktionen auswählen.
Gibt es unterschiedliche Ansätze?
Auch unterhalb der
Selective Data Transition.
Das eine, wenn man sagt, man möchte das
gesamte Customizing mit übernehmen, dann
bezeichnet man das auch
als Shell Conversion.
Und wenn man sagt, man möchte eventuell
nur ausgewählte Funktionalitäten aus dem
alten System mitnehmen, dann ist
es ein der Mix and Match Ansatz.
Aber beides gehört zusammen
zur Selective Data Transition.
So die Daten, die man ja im alten System
hat, werden je nach Anforderungen
des Kunden später migriert.
Das heißt, wir befinden uns
zwischen Brownfield und Greenfield.
Die Multi Shell oder Shell Conversion wird
bezeichnet, wenn man näher an der alten
Lösung ist, das heißt
mehr Customizing mitnimmt.
Und mit dem Mix and Match geht man eher in
Richtung der Greenfield Implementation,
weil man mehr ist für Hannah dazumischt.
Wir bleiben aber jetzt erstmal für diesen
Podcast generell Selective Data
Transition.
Jetzt muss ich auch schon wieder
nachdenken, Wie schlimm
ist der Data Transition?
Was sind typische Gründe, warum
Unternehmen sich für eine Selective
Data Transition entscheiden?
Der eine Grund ist, dass die Unternehmen
vielleicht mit ihrem System sehr zufrieden
sind und sagen Prozessual muss ich nicht
wahnsinnig viel verändern,
aber ich muss hier auf SV Hana umsteigen.
Also das ist ja ein Must
have, was wir heute haben.
Und mit der
gerade mit der Shell Conversion können Sie
viele Ihrer Prozesse übernehmen und erst
mal gar nichts oder überhaupt gar nichts
verändern und auf das
SV Hana System wechseln.
Dann ist noch ein Aspekt, dass man
eventuell Daten, die man über jahrelang
angesammelt hat, weil ein System schon
lange läuft, nicht alle mitnehmen möchte.
Also über die Migration kann
man Daten auch zurücklassen.
Genau.
Ja, grundsätzlich ist es so die
Systemeinstellungen werden aus dem alten
System in ein neues System übernommen.
Das wird erstmal konvertiert.
Dann kümmert man sich um zwingende
Anpassungen, die man machen muss oder
guckt was Muss man eventuell optional oder
was möchte man optional ergänzen
und übernimmt halt nur die Daten?
Teilweise
zwingend sind zum Beispiel Anpassungen,
die die SAP in ihrem Readiness check.
Also es gibt eine Prüfroutine, die die SAP
durchführt, bevor man sein System anpasst.
Den Readiness Check.
Dann gibt es zwingende
Anpassungen, die man machen muss.
Und das können Funktionen sein, die man im
System genutzt hat, später nicht mehr
nutzen kann oder etwas, was man unbedingt
nutzen muss, wie den Business Partner.
Das ist ja etwas, was im Svana sein muss.
Das ist ja dann super.
Ich will dich nicht unterbrechen, aber
dann fällt mir natürlich gleich ein am
Anfang in der Planungsphase,
wenn das Thema ist mit Go live.
Was natürlich auch ein sehr
strategisches Thema ist.
Dann aber gemeinsam
über den Check Go Live.
Welchen Ansatz fahren wir, dass man das
komplett miteinander verknüpft, diese
Entscheidungen und diese Diskussion, weil
das kann man ja dann
dementsprechend optimieren.
Wie viel Zeit habe ich, welches
sollte ich zuerst machen?
Was sind Prioritäten.
Genau?
Und man kann es eben am Anfang, wenn man
auch insbesondere
sich für den Ansatz entschieden hat und
dann weiß, wie man
genau vorgehen kann und den Realitätscheck
analysiert hat, kennt man auch die
wichtigsten Eckpunkte, über die
man sich Gedanken machen muss.
Und wenn man nicht viel verändern muss,
kann man vielleicht die
Laufzeit verlängern.
Wenn man weiß, ich muss halt viel anpassen
in meinem alten System, dann hat man ja am
Anfang noch die Zeit zu sagen okay, wir
müssen den Plan vielleicht
nach hinten gehen.
Ist immer besser, als mitten im
Projekt überrascht zu werden.
Man erlebt ja, so oder so werden noch
Überraschungen kommen
im Laufe des Projekts und daher ist
das ja natürlich ein wichtiger Punkt.
Du hast jetzt schon
mehrere Projekte erlebt.
Wo liegt aus deiner Sicht speziell
bei der Selective Data Transition?
Du hast schon ein paar Punkte genannt,
aber wo liegen da konkret die
größten Herausforderungen?
Wie wir gerade gesagt und wie wir gerade
gesagt haben, bereits
in der Planungsphase.
Was kann man da bereits in
der Planungsphase vermeiden?
Genau.
Also kurz angedeutet schon,
aber noch mal konkreter.
Genau.
Die größten Herausforderungen.
Haben sich immer wieder erwiesen.
Ist der Aufbau der Systemlandschaft etwas,
was man aus der Erfahrung der bisherigen
Releasewechsel in einem EC System
vielleicht nicht so im Fokus hat,
ist das doch etwas speziell, wenn
man auf ein SVH System wechselt.
Und was man nicht unterschätzen darf oder
was man hochpriorisieren sollte, ist der
Umfang der Tests, dass man dort sich Zeit
nimmt und eben auch ausführlich testet,
weil man die Kombination hat von
Datenmigration und Funktionen, die sich
verändern,
was normalerweise Bei einem normalen
Releasewechsel ist man ja manchmal dazu
übergegangen, die Tests schon sehr zu
standardisieren, runterzufahren und auf
wirklich kritische
Funktionen zu begrenzen.
Das reicht bei einer Svana
Conversion nicht mehr.
Also muss wieder umfangreicher testen.
So, wenn man sich das ganze jetzt mal vor
Augen hält, wie eine selektive Data
Transition vor sich geht, ist es so Man
nimmt die Systemeinstellungen Customizing
und Entwicklung und kopiert diese aus der
Produktivumgebung in ein neues System.
Das ist noch ein CC System.
Dieses System wird dann konvertiert.
Das ist ein SVH System ist und wird später
als Entwicklungssystem weiterverwendet.
Ab diesem Zeitpunkt könnten in diesem
Entwicklungssystem und werden auch
Anpassungen vorgenommen, die sich aus dem
Readiness Check ergeben haben oder
neue Funktionen eingeführt, die man
dann doch unter Svhana nutzen möchte.
Da aber Vorsicht, da kommen
wir später noch dazu.
Was jetzt hier aber wichtig ist das
produktive System läuft
ja in der Regel weiter.
Also die Unternehmen stehen ja nicht still
auf einmal, bloß weil ich
auf SVH konvertieren möchte.
Das heißt, ich habe ein
System, was ich weiterentwickelt und ich
habe das Svhana System, was zum einen
diese Weiterentwicklung immer mitnehmen
muss und aber auch weiterentwickelt wird.
Und zwar anders in eine andere
Richtung mit neuen Funktionen etc..
Was sollte man bei den
Testzyklen speziell beachten?
Du hast ja erzählt, das verstehe ich auch.
Ich habe parallele Systemlandschaften,
wird komplex, Kann ich so
ein bisschen nachvollziehen.
Was sollte ich bei Testzyklen beachten?
Genau.
Also meine Testzyklen
habe ich es als sehr vorteilhaft erlebt,
dass man
drei Testzyklen sich vornimmt, und zwar
immer in Kombination Datenmigration,
gefolgt von einem Funktionstest.
Dann testet man zum einen, wie gut ist die
sind die Datenmigration Routinen
entwickelt und zum anderen kann ich mit
den migrierten Daten meine
Funktionen ausführen.
Also es empfiehlt sich
dann einen ersten Zyklus.
Dann hat man die Datenmigration
im ersten Reifegrad.
Vielleicht nur 30 % der Objekte sind
realisiert für die Migration oder 31 % der
der Daten sind drüben und man baut mit
diesen Daten einen Funktionstest,
gegebenenfalls erweitert
um manuell angelegte Daten.
Zweiter Zyklus wäre dann der Reifegrad der
Datenmigration verbessert sich und
auch in den Funktionen ist man weiter.
Der dritte Zyklus ist dann eine
vollständige Datenmigration
plus Integrationstests.
So, das heißt natürlich im Umkehrschluss,
dass man auch mit der Umsetzung der
Routinen für die Datenmigration frühzeitig
beginnen muss, damit man das alles
fertig hat in den Testphasen.
Das funktioniert nicht, wenn man zu
knapp vor dem Go Live damit beginnt.
Generell ja nicht.
Da haben wir das Thema Testwert.
Ich glaube, da werden wir hatten wir
gemeinsam sogar schon mal, als wir
zusammen ein Projekt unterstützt haben.
So, und dann ergibt sich die
Herausforderung, dass man je nach
Projektplan sich auch überlegen muss, wenn
die Tests in eigenen Systemen
durchgeführt oder reichen.
Eigene Mandanten hat auch was mit der
Komplexität der Entwicklungen zu tun.
Wenn ich nicht viel in der Entwicklung
anpasse, was ja mandantenübergreifend
ist, kann ich mit Mandanten arbeiten.
So, das heißt, daraus ergeben sich auch
Anforderungen an eine Systemlandschaft.
Wie muss meine SAP sVorlandschaft
aussehen,
damit ich alle meine Projektphasen
sauber hintereinander durchlaufen kann?
Ja, und das ist ein bisschen anders wie
bei einem Releasewechsel in einem System.
So, dann kommt noch als einen
Komplexitätstreiber dazu, dass man
sinnvollerweise für die Tests der
Datenmigration im Quellsystem,
also ein Quellsystem nimmt, was man stabil
hält für den Test der Datenmigration und
hier natürlich auch immer wieder Daten aus
der Produktion auffrischen muss, weil
auch das produktive Leben geht weiter.
Vielleicht entwickeln sich
Datenkonstellationen, die man in der
Datenmigration nicht berücksichtigt
hat, die Fehler hervorbringen.
Und je näher man an den produktiven Daten
ist, desto mehr Fehler hat man in den
Testphasen natürlich schon gesehen,
ausgemerzt, korrigiert und desto
geschmeidiger läuft es dann am Ende, wenn
man wirklich live geht mit dem Ganzen.
Vor allem, was du gesagt hast, dass es
eben parallel Weiterentwicklungen sind in
dem Produktivsystem,
in dem vorhandenen EQ.
Da denke ich natürlich
an so Orgänderungen.
Reorganisation sollte man nicht tun.
Gerne genommen, da machen
wir nicht sehr aufpassen.
Das kennen wir auch, Haben wir
gemeinsam auch schon mal erlebt.
Ja und das heißt also wir haben dieses
Thema, wir haben die CC Landschaft, die
sich weiterentwickelt, wir haben einen SV
Hana System, was eine
neue Technologie ist.
Wir haben die Systemanforderungen für
Datenmigration und Tests
und daher sehe ich es so, dass die
Gestaltung der Systemlandschaft etwas ist,
was eine der größten Herausforderungen
in der SV Hana Conversion ist.
Und wenn man sich darüber am Anfang in der
Planung seine Gedanken macht, ist das sehr
hilfreich, weil man teilweise im Verlauf
dann dort sehr viel Zeit verlieren kann.
Ein neues System, ein neuer Mandant.
Je nach Flexibilität der IT
ist es schnell aufgebaut.
Aber ganz oft sind gerade solche
Funktionen ja outgesourced und es sind
administrative Abläufe erforderlich oder
Vorwarnphasen, die es
etwas schwieriger machen.
Deswegen, so meine Erfahrung, um dort
nicht unter Druck zu geraten, empfiehlt es
sich, dass man sich das schon frühzeitig
anschaut und die Gegebenheiten
berücksichtigt, unter denen man
seine Systeme aufbauen muss.
Genau.
Sondern aus meiner Erfahrung ist es halt
so Man muss sich Gedanken machen
über Anzahl und Größe der Systeme.
Welchen Vorlauf brauche ich, welche
Vorlaufzeit, um Systeme aufzubauen?
Welche Vorlaufzeit brauche ich, um ein
Quellsystem aufzufrischen und
wie gehe ich mit Retrofit und
Transportprozessen
zwischen den Systemen um?
Also retrofit Wie hole ich die Sachen, die
ich im ICC gemacht habe auch auf das S4
System muss ich alles manuell abtippen
oder habe ich einen Prozess,
den die SAP vorgesehen hat etc..
Also das sind so die vier Bereiche,
auf die man ein Auge haben sollte.
Gibt es noch einen weiteren Punkt, der
weniger offensichtlich ist, wo du sagst,
das wird auch noch gern übersehen?
Also zuzüglich zu dem, was
du gerade schon erwähnt hast.
Genau das ist so halb technisch aus meiner
Sicht und halb anwendungsspezifisch.
Gerade in der SV Hana Conversion kommt
die SAP ja oder steigt immer mehr auf.
Fury als Oberfläche um und.
Das kennen wir.
Ja.
Das ist ja auch so ein schönes Schlagwort
und das sieht auch so schön einfach aus
und man kann sich alles sehr
schön zusammenkonfigurieren.
Aber ich glaube, dass da
oder auch bei uns im Projekt hat es sich
gezeigt, dass das einer der
größten Stolpersteine ist.
Wenn man sagt, in der SV Conversion steigt
man auch sofort komplett auf Fury um.
Insbesondere wenn man
Applikationen mit viel kundeneigene
Entwicklung hat, weil Fury in diesem Fall
eben auch weiterentwickelt werden muss.
Also die Oberfläche müssen
weiterentwickelt werden und das läuft
etwas anders als in der heutigen
App ab Entwicklung oder GUI
Transaktionsentwicklung.
Deswegen ist so meine Erfahrung und meine
Empfehlung in der reinen S4 Conversion
sich auf die Transaktionen zu
begrenzen, die man unbedingt braucht.
Weil es gibt Transaktionen, die gibt es
nur noch in Fury später und ansonsten aber
idealerweise auf der alten GUI
Transaktion erstmal zu verbleiben.
Was geht?
Ja und ja, dann sollte man versuchen, das
auf kleinere Initiativen in
die Zukunft zu verschieben.
Weil man darf nicht vergessen
so eine SV Conversion.
Das gesamte System muss umgestellt werden
und das hat eine gewisse Komplexität
schon von sich aus, von Haus aus.
Während wenn man später sagt ich optimiere
weitere Funktionen, dann ist es vielleicht
nicht so schlimm, wenn dort sich einmal.
Also erstens kann man die Komplexität
reduzieren, weil man einzelne
einzelne kleine Aktivitäten durchführen
kann, und es ist nicht so schlimm, wenn
sich dort die Zeit verzögern sollte.
Bei einer SV Conversion ist aber eine
Zeitverzögerung direkt extrem teuer,
weil die Mannschaft dabei ist etc.
Deswegen Fokus auf das, was unbedingt
notwendig ist und nicht versuchen so
viel wie möglich direkt umzusetzen.
Das fand ich eigentlich
ganz nett, nämlich mit dem Bonbonladen.
Ja, ich finde SAP ist halt.
Kann man so ganz nachvollziehen, deswegen
würde ich da gern noch mal nachhaken.
Genau.
Also wenn man in die SV Hana Conversion
geht, gibt es ja viele neue Funktionen und
vieles, was die SAP auch gerade
unter Fury optimiert und einfacher macht.
Und Reporting, Transaktional Reporting
Kacheln, die auch wirklich einen guten
Eindruck machen, so dass man davor steht,
wie ein kleines Kind im Bonbonladen und
sich denkt Oh, das möchte ich haben und
das möchte ich haben
und das schmeckt super.
Und wie mit den Bonbons ist es, Wenn man
zu viel auf einmal genießt,
hat man am Ende Bauchschmerzen?
Und für mich war das
eine der wesentlichsten Erfahrungen zu
sehen, dass eine SV Hana
Orientierung genau das sein kann.
Das kleine Kind im Bonbonladen
Lieber wenige Bonbons sehr dosiert essen,
vorher entscheiden, welche Süßigkeiten es
heute gibt und in diesem Jahr und dann
später sagen Du kriegst dieses Bonbon drei
Monate später oder jenes Bonbon,
dann ein halbes Jahr später.
Und sich einfach in der Organisation,
in kleinen Initiativen weiterentwickeln.
Wenn man jetzt am Anfang eines Projektes
steht, noch mal ganz kurz
so zusammengefasst.
Also generell was würdest
du den Unternehmen raten?
Wie haben die Risiken aufgeführt?
Stolpersteine, wenn du jetzt
am Anfang des Projekts stehen.
So, und wenn du jetzt auf die drei
Themen siehst, die wir hatten, ist es.
Nimm dir ausreichend Zeit für deine
Testzyklen, Plane idealerweise
drei Testzyklen ein.
Immer Migration und Funktion
hintereinander geschaltet, immer auch mit
entsprechenden Abnahmezeiten hinten dran.
Denkt frühzeitig an die Systemlandschaft,
überlegt, wie man das intelligent aufbauen
kann und welche Zeit ihr vor allem auch
dafür braucht, damit es gut funktioniert.
Und ähm, ja, was zu den, ähm,
zur Systemlandschaft angeht, da würden wir
dann noch mal auf die Checkliste
im Hintergrund verweisen.
Ja, erkläre ich gleich was genau.
Damit ihr da vielleicht auch noch ein
paar Fragen zu dem ganzen Text habt.
Welche?
Welche Fragen man sich stellen sollte,
wenn man über die
Systemlandschaft nachdenkt.
Ich freue mich, dass
du es übernommen hast.
Die Zusammenfassung der Hacks,
das schreiben wir auch noch mal in
die Show, in die Shownotes rein.
Das waren jetzt zwei und wir haben einen
ganz besonderen dritten Hack heute.
Das hast du gerade kurz
erwähnt, dass die sind.
Das ist in den Shownotes aufgeführt.
Nämlich?
Du hast uns eine Checkliste mitgebracht,
die man für den Systemaufbau bereits in
der Planungsphase nutzen kann, wenn man
sich für eine selektive
Data Transition entscheidet.
Egal ob Mixer, Match oder Shell.
Das ist das Schöne.
Man kann es für beide verwenden und man
kann Copy Paste und man kann in der
Planungsphase dann die Checkliste
durchgehen, was natürlich grandios ist.
Ich habe viel gelernt und freue mich
ganz herzlich, dass Du da warst.
Vielen Dank für die Insights und auch für
die ehrlichen Worte aus deinem Projekt.
Das war wirklich spannend.
Danke schön.
Es hat Spaß gemacht.
Und Euch, liebe Zuhörerinnen und
Zuhörer, danke fürs Dabeisein.
Bis zum nächsten Mal, eure Anita.
Bis dann.
Ich schicke.