[53364] in SAPr3-news
Re: Migration
daemon@ATHENA.MIT.EDU (Volker Gueldenpfennig)
Sat Feb 12 04:46:38 2005
To: sapr3-news@mit.edu
Date: 12 Feb 2005 01:46:28 -0800
From: volker_remove_this@4soi.de (Volker Gueldenpfennig)
Message-ID: <be90f755.0502120146.5267d086@posting.google.com>
Hi Jan,
> > Besonders im FAQ-Kapitel werden die meisten Fragen beantwortet.
>
> meine leider nicht, die bewegen sich mal wieder in der Grauzone
> zwischen offiziellen Statements und gelebter Praxis ;-)
also hier mal ein paar hoffentlich aufhellende Worte:
SAP führt einen Migrations-Check i.A. NUR für produktive Systeme
durch!
Wenn also ganz offiziell gearbeitet wird, sieht das so aus, dass ein
zertifizierter Berater alle 3 Systeme migriert und normalerweise das
P-System zum Test vorweg, um mehr Erfahrung zu gewinnen (kann auch das
Q-System sein). Zu Beginn dieser Aktion wird die Migration bei SAP
angemeldet und der Zeitplan mitgeteilt. (Es müssen z.B. mindestens 2-3
Wochen zwischen Test- und PRD-Migration liegen) Dazwischen muss dann
vom Kunden auch getestet werden. Da bei einer OS/DB-Migration sich
auch immer zumindest das OS oder die DB oder beides ändert, ist NICHT
bei jedem Kunden sichergestellt, dass er sich nachher auch gut mit dem
System auskennt! Wenn man z.B. von NT-MSS nach Linux-Oracle geht,
sollte man zumindest Unix-Skills und auch gute Oracle Skills im Hause
habem was beileibe nicht immer sichergestellt ist. Es gibt einige
Kunden, die tatsächlich nur migrieren, weil die Hardware billiger ist
oder weil es gerade "in" ist auf Linux zu gehen. Hier sind dann schon
einige Risiken zu erwarten, wenn keine erfahrene Person dabei ist.
Durchgeführt wird der Check von SAP dann nur auf dem PRD System und
zwar 4 Wochen vor und 4 Wochen nach der Migration auf dem PRD-System.
Dieser Service ist als ein Service pro Jahr Bestandteil der Wartung.
Also meistens braucht man ihn als Kunde nicht zu kaufen, wenn man
nicht gerade schon andere Services hatte.
Wenn die Datenbank wechselt, muss ggf. hierfür noch die neue DB
gekauft werden. Wenn das über SAP geschieht, wird pauschal für MaxDB
3%, MSS 8% und Oracle 13% des Anteiles an der SAP-Lizenzsumme für
dieses System berechnet und von SAP an den DB-Hersteller weiter
geleitet.
Will man nur ein Spielsystem migrieren, reicht es wohl zumeist aus,
wenn man sich auf Source- und Target-Plattform ganz gut auskennt, da
die Tools in der Zwischenzeit schon wirklich ganz gut sind. Da eh kein
Check gemacht wird, muss man nur nachher das System mit der
Vertragsabteilung "umbuchen" (und ggf. Lizenzanteile nachzahlen). SAP
schreibt allerdings auch hier das Durchführen durch einen
zertifizierten Mig-Berater vor. Mir ist nicht bekannt, dass es da dann
aber schon mal grössere Probleme gegeben hätte, wenn dies durch den
Kunden nicht befolgt wurde (ausser, wenn direkt nach der "illegalen
Migration" viele OSS Meldungen aufgemacht werden, weil "alles" nicht
läuft - dann geht SAP von Dummheit beim Kunden aus - was ja wohl auch
nicht ganz von der Hand zu weisen ist)
Will man auch eine produktive Landschaft "illegal" migrieren, könnte
selbst das durchgeführt werden, weil der von SAP durchgeführte Check
dann zwar durchgeführt wird, aber auf jeden Fall eine rote Ampel
zeigt. Das kann ich aber auf keinen Fall empfehlen, weil man bei einer
produktiven Landschaft sicherlich auf Support am berühmten
"Montag-Morgen" angewiesen ist!!!
Warum hat SAP das so strikt gemacht ?
Es gab tatsächlich in der Vergangenheit Kunden, die migriert haben,
dabei dann aber einige Tabellen oder auch nur einige Spalten einiger
Tabellen fehlten, weil die Vorarbeiten nicht korrekt durchgeführt
wurde (und die Tools auch noch nicht auf dem heutigen Stand waren). Da
danach das Geschrei natürlich gross war, hat man sich zu diesem
Schritt entschlossen, der m.E. für eine produktive Landschaft auch
absolut sinnvoll ist. Schliesslich ist ein produktiver SAP-Kunde
zumeist keine Würstchenbude, wo es nicht drauf ankäme, wenn die
Systeme am Montag nicht korrekt laufen.
Also wird hier klar, wie wichtig es in einem solchen Projekt ist, auch
die User mit einzubeziehen, dass diese ALLE "Prio-1-Prozesse" WIRKLICH
durchtesten (Mir ist auch klar, dass nicht das komplette R3 getestet
werden kann.) Es müssen auch alle Schnittstellen und externen
Interfaces umgebaut und dann getestet werden usw.
Langsam wird dann evtl. einsichtig, warum es immer hilfreich ist, wenn
man eine gesamte Landschaft ändert, dann auch einer dabei ist, der das
schon mal erfolgreich getan hat.
Wenn es weitere Fragen gibt, melde Dich einfach bei mir ...
(http://www.easymarketplace.de/gueldenpfennig-de.php)
Gruß
Volker
