Zu SAP Business One wechseln: Migration Schritt für Schritt

Eine Migration zu SAP Business One ist kein Datenexport mit anschließendem Import. Sie ist ein Projekt, in dem Sie entscheiden, welche Daten des Altsystems im neuen ERP noch etwas wert sind, in welcher Form sie dort gebraucht werden und wie der Betrieb am Tag der Umstellung weiterläuft. Wer von Excel, von einer Buchhaltungssoftware oder von einem gewachsenen Altsystem auf SAP Business One wechseln will, trifft diese Entscheidungen am besten früh – und mit einem Integrator, der den Ablauf schon mehrfach begleitet hat.

Diese Seite behandelt zwei Fälle: den Wechsel zu SAP Business One und den Wechsel zwischen Versionen von SAP Business One. Beide folgen unterschiedlichen Regeln, die Sorgfalt ist dieselbe.

Woher kommen Sie? Die typischen Ausgangslagen

Der Aufwand einer Migration hängt weniger vom Zielsystem ab als vom Zustand der Quelle.

Wer aus einem alten ERP kommt, unterschätzt meist die implizite Logik: Preisregeln, die nur in den Köpfen einzelner Mitarbeiter existieren, Sonderkonditionen, handgepflegte Listen neben dem System. Diese Dinge tauchen in keinem Export auf. Ein Workshop vor dem Projekt, in dem Fachabteilungen ihre tatsächlichen Abläufe zeigen, spart später Nacharbeit.

Was die Methodik von SAP vorsieht

SAP beschreibt die Datenübernahme aus dem Altsystem als Bestandteil der Realisierungsphase eines Einführungsprojekts und stellt dafür unter den Werkzeugen der Implementierungsmethodik einen Leitfaden zur Datenmigration bereit. Das ist die Grundlage, auf der ein seriöser Integrator arbeitet: Die Migration wird nicht am Ende „nebenbei“ erledigt, sondern ist ein eigener Arbeitsstrang mit Verantwortlichen, Terminen und Abnahme.

Wie sich dieser Strang in den Gesamtablauf einfügt, beschreiben wir auf der Seite zur Einführung von SAP Business One. Allgemein zum Vorgehen bei einem Systemwechsel finden Sie Hinweise im Ratgeber ERP-Migration.

Reihenfolge der Datenübernahme: erst die Stammdaten

Die Reihenfolge ist keine Geschmacksfrage, denn Bewegungsdaten bauen auf Stammdaten auf.

Stammdaten

Zuerst kommen Geschäftspartner (Kunden und Lieferanten), Artikel, Stücklisten, Lager, Preislisten und der Kontenplan. Hier lohnt sich das Aufräumen am meisten: Jeder Datensatz, den Sie jetzt nicht übernehmen, müssen Sie später nicht pflegen. Typische Bereinigungen sind:

• inaktive Kunden und Lieferanten ohne Bewegung ausschließen,
• Dubletten zusammenführen, etwa dieselbe Firma mit unterschiedlicher Schreibweise,
• Artikelnummern vereinheitlichen und veraltete Artikel archivieren,
• Zahlungsbedingungen, Steuerkennzeichen und Mengeneinheiten auf eine saubere Liste bringen,
• UID-Nummern und Adressen prüfen, weil sie später in Belegen, Meldungen und der E-Rechnung wieder auftauchen.

Offene Posten und Salden

Danach folgen offene Debitoren- und Kreditorenposten sowie die Eröffnungssalden der Sachkonten. Hier arbeiten Buchhaltung und Steuerberater mit: Die Summen im neuen System müssen zum letzten abgeschlossenen Stand der alten Buchhaltung passen. Wie der Finanzbereich in SAP Business One aufgebaut ist, zeigt die Seite zu Buchhaltung und Finanzen.

Offene Belege und Bestände

Offene Aufträge, Bestellungen und Lagerbestände übernehmen Sie so, dass der Betrieb am ersten Arbeitstag nahtlos weiterläuft. Für Handel und Lager sind die Bestände der heikelste Punkt: Eine Inventur zum Stichtag ist meist sauberer als die Übernahme rechnerischer Bestände. Mehr dazu unter Lager und Einkauf.

Wie viel Historie gehört ins neue System?

Das ist die Frage, an der Projekte am häufigsten streiten. Eine pauschale Antwort gibt es nicht, aber eine brauchbare Faustregel: Ins ERP gehört, womit Sie täglich arbeiten. Der Rest gehört ins Archiv.

• Für die laufende Arbeit zählen offene Vorgänge, aktuelle Preise und die jüngere Umsatzhistorie, etwa für Auswertungen im Vertrieb (CRM und Vertrieb).
• Ältere Belege müssen Sie weiterhin aufbewahren und auf Verlangen vorlegen können. Das verlangt die Aufbewahrungspflicht nach Unternehmens- und Abgabenrecht. Ein lesbares Archiv des Altsystems oder ein Export in ein revisionsfähiges Format genügt dafür oft – ein Import jedes historischen Belegs ist nicht nötig.
• Klären Sie die Aufbewahrung ausdrücklich mit Ihrem Steuerberater, bevor das Altsystem abgeschaltet wird. Ein Server, der „irgendwann“ heruntergefahren wird, ist ein klassischer Fehler.

Gerade in Österreich gilt: Wer ein Registrierkassensystem im Einsatz hat, muss die Anbindung an das ERP vor der Umstellung klären, denn Kassendaten und Belegkreise dürfen nicht abreißen. Die Anforderungen beschreibt die Seite zur Registrierkassenpflicht (RKSV) im ERP.

Die Umstellung: Stichtag und Strategie

Es gibt im Kern zwei Wege, den Betrieb vom alten auf das neue System zu heben.

Bei kleinen und mittleren Unternehmen ist die Stichtagsumstellung der Normalfall, weil eine Übergangszeit mit zwei parallelen Systemen mehr Aufwand erzeugt, als sie spart. Als Stichtag bietet sich ein Monats- oder Jahreswechsel an, damit die Eröffnungssalden auf einem abgeschlossenen Zeitraum stehen. Meiden Sie Zeiten, in denen Inventur, Jahresabschluss oder saisonale Spitzen anstehen.

Läuft in Ihrem Unternehmen mehr als ein Standort, lohnt ein Blick auf die regionale Verfügbarkeit von Integratoren – etwa in Wien, der Steiermark oder in Oberösterreich –, weil Schulung und Hypercare am besten vor Ort stattfinden.

Testen: ohne Probelauf keine Umstellung

Eine Migration wird nicht in einem Lauf entwickelt, sondern in mehreren Durchgängen verbessert. Bewährt hat sich folgendes Muster:

1. Probemigration: Die Daten werden in ein Testsystem geladen. Fehlerhafte Datensätze, Formatprobleme und fehlende Pflichtfelder fallen sofort auf.
2. Fachliche Prüfung: Die Anwender prüfen nicht „ob geladen wurde“, sondern ob die Ergebnisse stimmen – Salden, offene Posten, Bestände, Preise.
3. Prozesstest mit echten Fällen: Ein Auftrag von der Anfrage bis zur Rechnung, ein Wareneingang bis zur Eingangsrechnung, ein Zahlungslauf. Dabei gehören auch die gesetzlichen Pflichten dazu, etwa die E-Rechnung.
4. Generalprobe: Der komplette Ablauf der Umstellung wird zeitlich durchgespielt, damit am Stichtag niemand improvisiert.
5. Abnahme: Die Verantwortlichen in Buchhaltung, Lager und Vertrieb geben die Daten schriftlich frei.

Wichtig ist, dass die Prüfung gegen vorher definierte Kriterien läuft. „Sieht gut aus“ ist kein Abnahmekriterium. Fixieren Sie vorab, welche Summen übereinstimmen müssen und welche Abweichungen toleriert werden.

Rückfallplan: Was, wenn es hakt?

Jede Umstellung braucht einen Plan für den Fall, dass sie scheitert. Dieser Plan wird vor dem Stichtag geschrieben, nicht währenddessen.

• Altsystem unverändert erhalten: Bis zur Freigabe bleibt der alte Stand lesbar und im Notfall weiterführbar.
• Sicherung vor dem Stichtag: Vollständige Sicherung des Altsystems und des Zielsystems vor dem finalen Ladevorgang.
• Entscheidungsregel: Wer entscheidet bis wann, ob zurückgegangen wird, und anhand welcher Befunde?
• Nacherfassung: Wenn in der Übergangszeit im Altsystem weitergearbeitet wurde, muss klar sein, wie diese Buchungen nachgeführt werden.

Ein Rückfallplan, der nie ausgesprochen wurde, existiert im Ernstfall nicht. Besprechen Sie ihn mit der Geschäftsführung, bevor das Projekt in die heiße Phase geht.

Migration zwischen Versionen von SAP Business One

Wer SAP Business One bereits nutzt, steht vor einer anderen Frage: Wie kommt die bestehende Installation auf einen unterstützten Stand? Hierzu liegen Aussagen von SAP vor, die wir hier einordnen.

• Direkte Versions-Upgrades sind nur zwischen aufeinanderfolgenden Versionen unterstützt, etwa von 9.3 auf 10.0. Liegt Ihre Version weiter zurück, führt der Weg über mehrere Schritte.
• Die Standardwartung ist begrenzt. SAP sichert pro Versionsfamilie mindestens fünf Jahre Standardwartung ab dem Erscheinen der Hauptversion zu. Nach Angaben von SAP ist Version 10.0 bis zum 31. Dezember 2028 in der Standardwartung, wobei die Termine Änderungen unterliegen. Die Versionen 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 und 9.3 haben diese Phase bereits beendet.
• Eine Nachfolgeversion ist angekündigt, ohne Termin: Die Wartungsseite vermerkt lediglich, dass Version 11 auf Version 10 folgt.
• Seit Version 10.0 (April 2020) liefert SAP Neuerungen laufend über kumulative Feature Packages, die auch Korrekturen, Sicherheitsfixes und rechtliche Aktualisierungen enthalten. Die Schnittstellen bleiben zwischen Hauptversion und Feature Packages stabil.
• Upgrades sind mit gültigem Wartungsvertrag kostenfrei. Für ältere Feature Packages, Support Packages, Patches oder Hotfixes liefert SAP dagegen keine Korrekturen und keine Sicherheitsupdates mehr.

Für die Praxis folgt daraus: Eine Installation auf einer ausgelaufenen Version ist kein Komfort-, sondern ein Sicherheits- und Rechtsthema, denn rechtliche Aktualisierungen – in Österreich etwa rund um Umsatzsteuer und E-Rechnung – kommen nur in unterstützten Ständen an. Eine Übersicht zu Ständen und Editionen finden Sie unter Versionen und Editionen.

Was beim Versionswechsel geprüft werden muss

Das Upgrade selbst ist technisch der kleinere Teil. Aufwendiger ist meist die Umgebung:

• Erweiterungen und Eigenentwicklungen: Laufen sie auf der Zielversion? Dazu mehr unter Individualentwicklung.
• Schnittstellen zu Webshop, Kasse, Banking oder Steuerberater, siehe Schnittstellen.
• Berichte und Formulare, die auf alte Strukturen zugreifen.
• Betriebsumgebung: Datenbank, Server und Clients. Bei einem Betrieb beim Dienstleister klären Sie den Zeitplan mit dem Anbieter, siehe Hosting und Cloud.
• Schulung: Neue Oberflächen und Funktionen brauchen eine kurze Einweisung, siehe Schulung.

Ein Upgrade wird, wie eine Erstmigration, zuerst auf einer Kopie des Produktivsystems durchgespielt. Erst wenn Berichte, Schnittstellen und Kernprozesse dort bestanden haben, wird das Produktivsystem angefasst. Ist die Installation über die Jahre unübersichtlich geworden, hilft vorab ein Audit und eine Projektübernahme.

Häufige Fehler bei der Migration

• Alles übernehmen wollen. Wer jeden Datensatz importiert, importiert auch jeden Altfehler.
• Datenbereinigung auf später verschieben. Danach ist niemand mehr zuständig, und die Fehler leben im neuen System weiter.
• Keine fachliche Verantwortung für die Daten. Die IT kann laden, aber nur die Fachabteilung weiß, ob ein Preis stimmt.
• Steuerberater zu spät einbinden. Eröffnungssalden, Kontenplan und Archivierung sind Fragen der Buchhaltung, nicht der Technik.
• Die Generalprobe überspringen. Die erste echte Umstellung ist dann zugleich der erste Test.
• Das Altsystem zu früh abschalten. Bis Abnahme und Archivierung abgeschlossen sind, bleibt es erhalten.
• Versionspfade ignorieren. Wer Upgrades jahrelang aufschiebt, braucht später mehrere Schritte statt eines.

Kosten und Aufwand einordnen

Wie aufwendig eine Migration wird, hängt vom Datenzustand, vom Umfang der Historie, von der Zahl der Schnittstellen und von der Zahl der Anwender ab. Eine verlässliche Zahl ohne Kenntnis Ihrer Ausgangslage wäre unseriös. Den Rahmen für Lizenz und Projekt erläutern wir auf der Seite zu den Preisen von SAP Business One; der Aufwand der Datenübernahme wird im Angebot eines Integrators üblicherweise als eigener Posten ausgewiesen. Fragen Sie danach ausdrücklich.

Den passenden Integrator für die Migration finden

Die Migration ist der Teil eines ERP-Projekts, bei dem Erfahrung am meisten zählt. Fragen Sie Interessenten gezielt nach ihrem Vorgehen bei der Datenübernahme, nach Testläufen und nach dem Rückfallplan – und danach, wie sie mit österreichischen Besonderheiten wie RKSV, E-Rechnung und der Abstimmung mit dem Steuerberater umgehen. Tipps zur Auswahl finden Sie unter Integrator wählen. Wie unsere kostenlose Vermittlung abläuft, steht unter So funktioniert es. Wer noch unsicher ist, ob SAP Business One überhaupt das richtige Ziel ist, sieht sich die Alternativen zu SAP Business One an.

Die genannten Softwarenamen sind Marken der jeweiligen Hersteller und dienen ausschließlich der Information. Diese Website ist unabhängig und steht in keiner Verbindung zu den Herstellern.