HANA Migration richtig vorbereiten

Wenn Eure SAP-Business-One-Datenbank seit Jahren mitgewachsen ist, zeigt sich das vor einer Migration ziemlich schnell: alte Reports, unklare Eigenentwicklungen, Dubletten, offene Altlasten in der Fibu und niemand weiß mehr genau, welche Schnittstelle nachts eigentlich was schreibt. Genau hier entscheidet sich, ob Ihr eine HANA Migration richtig vorbereiten oder ob das Projekt später Zeit, Nerven und Geld frisst.

Eine HANA-Migration ist kein Großprojekt, wenn sie sauber geplant ist. Sie wird aber unnötig kompliziert, sobald Unternehmen versuchen, technische Umstellung und Prozessbereinigung gleichzeitig improvisiert zu erledigen. Für Mittelständler, Start-Ups und wachsende Unternehmen gilt deshalb: erst Klarheit schaffen, dann migrieren. Nicht andersherum.

Warum die Vorbereitung über den Projekterfolg entscheidet

Viele Unternehmen unterschätzen nicht die Migration selbst, sondern den Zustand ihres aktuellen Systems. Auf dem Papier läuft SAP Business One. Im Alltag gibt es dann Excel-Nebenwelten, manuelle Korrekturen, historische Sonderfälle und Add-ons, die zwar genutzt werden, aber nicht dokumentiert sind. HANA macht solche Themen nicht größer - aber sichtbarer.

Das ist die gute Nachricht und gleichzeitig der Knackpunkt. Wer die HANA Migration richtig vorbereiten will, muss nicht alles neu erfinden. Es geht darum, den Ist-Zustand ehrlich zu prüfen und die Teile zu sichern, die im Tagesgeschäft wirklich tragen. Der Rest gehört auf den Prüfstand.

HANA Migration richtig vorbereiten: zuerst den Scope festziehen

Der häufigste Fehler ist ein zu weicher Projektumfang. Dann startet die Migration mit der Idee, “erst mal technisch umzustellen”, und zwei Wochen später geht es plötzlich auch um neue Workflows, neue Reports, neue Beleglogik und ein Bereinigungsvorhaben für den kompletten Artikelstamm. Genau so entstehen Verzögerungen.

Besser ist ein klarer Scope in drei Ebenen. Erstens: Was muss zwingend mit in die HANA-Umgebung, damit Ihr weiterarbeiten könnt? Zweitens: Was soll geprüft und gezielt optimiert werden? Drittens: Was bleibt bewusst draußen, weil es historisch gewachsen, aber heute nicht mehr geschäftskritisch ist?

Diese Trennung ist pragmatisch und spart Diskussionen. Sie hilft auch intern, weil Geschäftsführung, Fachbereich und IT nicht über alles gleichzeitig entscheiden müssen.

Systeme, Add-ons und Schnittstellen vollständig erfassen

Bevor Termine festgelegt werden, braucht Ihr ein belastbares Bild Eurer Systemlandschaft. Dazu gehören die SAP-Business-One-Version, Datenbankstand, eingesetzte Add-ons, individuelle Anpassungen, angebundene Drittsysteme und alle Import- und Exportprozesse. Besonders kritisch sind stille Abhängigkeiten - etwa ein altes Versandtool, ein selbstgebauter SQL-Report oder eine Finanzschnittstelle, die nur eine Person im Unternehmen wirklich kennt.

Gerade bei kleineren Unternehmen liegt dieses Wissen oft nicht sauber dokumentiert vor. Das ist normal, aber riskant. Eine gute Vorbereitung heißt deshalb nicht nur Technik inventarisieren, sondern Verantwortlichkeiten benennen. Wer prüft was, wer entscheidet bei Konflikten, wer gibt Tests frei?

Datenqualität vor Geschwindigkeit

Wer auf HANA migriert, sollte nicht jeden Datenballast automatisch mitnehmen. Es geht nicht darum, die Vergangenheit zu löschen. Es geht darum, schlechte Stammdaten, inaktive Datensätze, doppelte Geschäftspartner oder unklare Kontenzuordnungen früh zu erkennen. Sonst migriert Ihr Probleme einfach nur schneller.

Besonders relevant sind Artikelstämme, Geschäftspartnerdaten, Lagerinformationen und Finanzdaten. Wenn dort Inkonsistenzen stecken, merkt Ihr das später in Reports, Auswertungen und Folgeprozessen. Eine saubere Datenprüfung kostet Zeit, spart aber deutlich mehr Zeit in der Nacharbeit.

Ohne Testplan wird jede Migration teuer

Ein Testsystem allein reicht nicht. Ihr braucht einen Testplan, der zum Alltag Eures Unternehmens passt. Viele Teams testen zu technisch und zu wenig prozessbezogen. Dann wird geprüft, ob sich Belege anlegen lassen, aber nicht, ob der gesamte Ablauf von Angebot über Auftrag, Lieferung, Rechnung und Zahlung wirklich so funktioniert wie im Tagesgeschäft.

Ein guter Testplan orientiert sich an echten Geschäftsvorfällen. Welche Prozesse laufen täglich? Welche sind kritisch für Monatsabschluss, Versand, Einkauf oder Produktion? Welche Sonderfälle dürfen nicht kaputtgehen? Genau diese Szenarien müssen vor Go-live einmal vollständig durchgespielt werden.

Das gilt auch für Berechtigungen, Drucklayouts, Freigaben und Auswertungen. In vielen Projekten sind das nicht die großen Showstopper, aber die Punkte, an denen Fachbereiche Vertrauen verlieren. Wenn ein Vertriebsteam am ersten Tag keine sauberen Belege drucken kann, ist die Stimmung schnell dahin - auch wenn die Datenbank technisch perfekt migriert wurde.

Key User früh einbinden

Migrationen scheitern selten an fehlender Software. Sie scheitern eher daran, dass Fachbereiche zu spät einbezogen werden. Wenn Key User erst kurz vor dem Go-live ins Spiel kommen, sehen sie Probleme, wenn kaum noch Zeit für Korrekturen bleibt.

Deshalb sollten die relevanten Personen aus Finance, Operations, Sales, Einkauf oder Lager früh mit an den Tisch. Nicht für lange Workshops ohne Ergebnis, sondern für klare Entscheidungen. Welche Reports sind unverzichtbar? Welche Masken oder Felder werden täglich genutzt? Welche alten Workarounds sollen bewusst verschwinden?

Das hat noch einen zweiten Vorteil: Die interne Akzeptanz steigt. Wer an der Vorbereitung beteiligt war, zieht die Umstellung später eher mit.

Timing realistisch planen statt schönrechnen

Viele Unternehmen legen den Migrationstermin dort hin, wo er im Kalender gut aussieht. Zwischen Quartalsende, Inventur, Urlaubszeit und Jahresabschluss wirkt fast jede Woche irgendwie machbar. In der Praxis ist das selten so.

Realistisches Timing heißt, Euren operativen Rhythmus ernst zu nehmen. Wenn der Monatsabschluss knapp ist, wenn saisonale Peaks laufen oder wenn parallel ein Lagerprojekt startet, sollte die Migration nicht in genau diesen Zeitraum gedrückt werden. Ein vermeintlich schneller Termin ist teuer, wenn intern niemand Zeit für Tests, Freigaben oder Rückfragen hat.

Auch der Cutover selbst braucht eine klare Planung. Wann werden letzte Daten übernommen? Wer stoppt Schnittstellen? Wer prüft Belegnummernkreise, Benutzerrechte und Druckformulare? Wer entscheidet, falls am Go-live-Morgen noch ein kritischer Punkt offen ist? Wer diese Fragen vorab sauber beantwortet, reduziert Hektik deutlich.

Technische Vorbereitung ist wichtig - aber nicht alles

Natürlich gehört zur Migration auch die technische Basis. Infrastruktur, Versionen, Kompatibilität von Add-ons, Backup-Strategie und Performance-Anforderungen müssen sauber geprüft sein. Gerade wenn Unternehmen aus einer gewachsenen Umgebung kommen, ist es sinnvoll, nicht nur auf “läuft irgendwie” zu setzen, sondern die Zielarchitektur bewusst aufzubauen.

Trotzdem ist die Technik nur ein Teil der Wahrheit. Eine HANA-Datenbank bringt Euch keinen Nutzen, wenn Prozesse weiterhin mit Schattenlisten und manuellen Korrekturen laufen. Der eigentliche Hebel liegt oft darin, die Migration zum Anlass zu nehmen, überflüssige Umwege zu streichen. Nicht als Mammutprojekt, sondern mit gesundem Pragmatismus.

Genau hier trennt sich gute Vorbereitung von Overengineering. Ihr braucht kein Transformationsprogramm mit zehn Teilprojekten. Ihr braucht Klarheit, Prioritäten und einen Partner, der SAP Business One wirklich kennt und nicht erst im Projekt anfängt, Eure Realität zu verstehen.

Was vor dem Go-live wirklich sitzen muss

Kurz vor der Umstellung wird es oft hektisch. Deshalb hilft eine einfache Regel: Alles, was für den ersten Arbeitstag geschäftskritisch ist, muss verbindlich geprüft und freigegeben sein. Dazu zählen Stammdaten, offene Belege, Kernprozesse, Schnittstellen, Benutzerrollen und Standardauswertungen. Nice-to-haves können warten. Geschäftskritische Themen nicht.

Ebenso wichtig ist ein klarer Support-Rahmen für die ersten Tage nach dem Go-live. Wer ist erreichbar? Wie werden Fehler priorisiert? Was ist ein echter Blocker und was nur ein Schulungsthema? Unternehmen, die diese Phase unterschätzen, erleben unnötige Unruhe - selbst dann, wenn die Migration fachlich sauber gelaufen ist.

Wer mit Festpreis, sauberem Scope und klaren Verantwortlichkeiten arbeitet, hat hier einen echten Vorteil. Genau deshalb setzen spezialisierte Projekte nicht auf Beratersprache, sondern auf belastbare Abläufe ohne Überraschungen. Das ist auch der Grund, warum viele Unternehmen bei einer HANA-Migration lieber mit einem spezialisierten Partner wie RConsult arbeiten als mit einem Generalisten, der SAP Business One nur nebenbei betreut.

Wann mehr Vorbereitung sinnvoll ist - und wann nicht

Nicht jedes Unternehmen braucht vor einer HANA-Migration die gleiche Tiefe. Wenn Eure Systemlandschaft überschaubar ist, kaum Eigenentwicklungen existieren und die Datenqualität ordentlich ist, kann die Vorbereitung kompakt und schnell laufen. Wenn dagegen viele Add-ons, internationale Anforderungen, mehrere Mandanten oder historisch gewachsene Sonderprozesse im Spiel sind, braucht Ihr mehr Vorlauf.

Der Punkt ist nicht, möglichst viel Analyse zu verkaufen. Der Punkt ist, die passende Vorbereitung zu wählen. Zu wenig Vorbereitung führt zu Überraschungen. Zu viel Vorbereitung bremst Euch ohne Mehrwert. Beides ist unnötig.

Wenn Ihr Eure HANA Migration richtig vorbereiten wollt, denkt nicht zuerst an Technikfolien oder Projektpläne. Denkt an Euren echten Betrieb am Montagmorgen nach dem Go-live. Können Eure Teams arbeiten? Stimmen die Zahlen? Laufen die Prozesse? Wenn diese Fragen sauber beantwortet sind, ist die Migration nicht nur geschafft, sondern auch sinnvoll umgesetzt.

Die beste Vorbereitung erkennt man nicht an großen Präsentationen, sondern daran, dass der Wechsel am Ende unspektakulär wirkt - genau so sollte es sein.