Ein ERP-System (Enterprise Resource Planning) ist das digitale Rückgrat eines Unternehmens: Es verbindet Finanzwesen, Einkauf, Produktion, Vertrieb, Lager und oft auch Personalwirtschaft in einem gemeinsamen Datenmodell. Weil in diesem System die geschäftskritischen Prozesse und die zentrale Wahrheit über Bestände, Aufträge und Buchungen liegen, hat jeder Wechsel unmittelbare Auswirkungen auf das Tagesgeschäft. Genau das unterscheidet die ERP-Migration von vielen anderen IT-Projekten: Ein Fehler betrifft nicht ein Randsystem, sondern potenziell die Fähigkeit, überhaupt Rechnungen zu stellen, Ware auszuliefern oder Löhne zu zahlen.
Der Begriff Migration wird dabei häufig in zwei Bedeutungen verwendet, die man auseinanderhalten sollte. Im engeren Sinne meint Migration die Datenmigration: die Überführung von Stamm- und Bewegungsdaten aus dem Altsystem in das neue System. Im weiteren, in diesem Artikel gebrauchten Sinne meint ERP-Migration das gesamte Vorhaben des Systemwechsels — von der Strategie über die Prozessgestaltung bis zum stabilen Betrieb. Die Datenmigration ist dann ein wichtiger Teilaspekt, aber eben nur einer von mehreren.
Ein ERP-Wechsel geschieht selten aus Lust an der Veränderung, sondern hat konkrete Auslöser. Am häufigsten steht die Ablösung eines Altsystems im Vordergrund: Die vorhandene Lösung ist technologisch veraltet, wird vom Hersteller nicht mehr weiterentwickelt oder gepflegt (Wartungsende), lässt sich nicht mehr sinnvoll erweitern oder findet keine Fachkräfte mehr, die sie beherrschen. Solche Systeme werden mit den Jahren zum Risiko — funktionsfähig, aber immer schwerer wartbar und ein wachsendes Hindernis für neue Anforderungen.
Ein zweiter großer Anlass ist der Umzug in die Cloud. Viele Unternehmen betreiben ihr ERP noch klassisch im eigenen Rechenzentrum (On-Premise) und wollen — oder müssen — auf ein Cloud- oder SaaS-Modell wechseln, um Betriebsaufwand zu reduzieren, ortsunabhängig zu arbeiten oder überhaupt aktuelle Releases zu erhalten. Der Cloud-Umzug ist dabei nicht automatisch trivial: Datenhoheit, Schnittstellen, Anpassungen und Betriebsverantwortung verschieben sich, was eigene Planung erfordert.
Weitere Anlässe sind Wachstum und Internationalisierung (das alte System skaliert nicht mehr, kann keine weiteren Gesellschaften oder Sprachen abbilden), Unternehmenszusammenschlüsse und Ausgründungen (mehrere Systeme sollen konsolidiert oder getrennt werden), veränderte gesetzliche Anforderungen sowie der schlichte Wunsch, veraltete, über Jahre gewachsene Prozesse im Zuge eines Neuanfangs zu bereinigen. Häufig treffen mehrere dieser Treiber zusammen — und genau das macht die saubere Zielklärung zu Beginn so wichtig.
Nicht jeder Systemwechsel ist eine Migration im vollen Sinne, und die Begriffe werden oft vermischt. Ein Upgrade bezeichnet den Wechsel auf eine neuere Version desselben Systems, bei dem Datenmodell und Grundstruktur weitgehend erhalten bleiben — technisch anspruchsvoll, aber in der Regel weniger tiefgreifend. Eine Neueinführung (Implementierung) meint das erstmalige Einführen eines ERP-Systems in einem Unternehmen, das bislang keines oder nur Insellösungen hatte. Die Migration liegt dazwischen und verbindet beide Welten: Es gibt ein Bestandssystem mit Daten und eingespielten Prozessen, und dieses wird durch ein anderes ersetzt.
Diese Abgrenzung ist mehr als Wortklauberei, weil sie den Aufwand und die Risiken prägt. Wo ein Upgrade vor allem technische Sorgfalt verlangt, muss eine Migration zusätzlich die Frage beantworten, wie die alten Daten und Prozesse in eine womöglich völlig andere Struktur passen. Und wo eine Neueinführung auf der grünen Wiese startet, muss die Migration die Kontinuität des laufenden Betriebs sichern — das Unternehmen kann während des Wechsels nicht einfach anhalten.
Dieser Beitrag ordnet die ERP-Migration herstellerneutral und produktunabhängig ein — er behandelt bewusst kein einzelnes System, sondern das Vorgehen als solches. Nach den Grundlagen (Kapitel 01) folgen die Migrationsstrategien (Kapitel 02), die Datenmigration als Kerndisziplin (Kapitel 03), das Projektvorgehen mit seinen Phasen (Kapitel 04), Rollen, Team und Change Management (Kapitel 05), Risiken und typische Fehler (Kapitel 06), Test, Go-Live und Hypercare (Kapitel 07), Aufwand und Erfolgsfaktoren im Mittelstand (Kapitel 08), Kosten sowie DSGVO und Datenhoheit (Kapitel 09) und schließlich häufige Fragen (Kapitel 10). Ziel ist eine belastbare Orientierung, keine Werbung für einen bestimmten Weg.
Die erste Achse betrifft den Umschaltzeitpunkt. Beim Big-Bang-Ansatz wird das neue System zu einem festgelegten Stichtag scharf geschaltet, und das Altsystem wird zeitgleich abgelöst — alle Bereiche, Standorte oder Gesellschaften wechseln gemeinsam. Der Vorteil liegt im klaren Schnitt: Es gibt keinen langwierigen Parallelbetrieb zweier Systeme, keine komplizierten Übergangsschnittstellen und einen eindeutigen Zeitpunkt, ab dem alle im neuen System arbeiten. Der Preis ist ein hohes Konzentrationsrisiko: Läuft am Stichtag etwas schief, ist potenziell das gesamte Unternehmen betroffen, und ein Zurück ist schwierig. Big Bang verlangt daher besonders gründliche Tests und einen belastbaren Rückfallplan.
Beim stufenweisen Ansatz (auch phasenweise oder Rollout genannt) wird das neue System schrittweise eingeführt — etwa nacheinander pro Standort, Gesellschaft, Modul oder Prozessbereich. Das Risiko je Schritt ist kleiner, man kann aus frühen Phasen lernen und nachjustieren, und ein Fehler bleibt lokal begrenzt. Der Nachteil ist die längere Gesamtdauer und die anspruchsvolle Übergangsphase: Solange alte und neue Welt parallel laufen, müssen Daten und Prozesse zwischen beiden Systemen konsistent gehalten werden, was temporäre Schnittstellen und zusätzlichen Aufwand bedeutet. Welcher Weg passt, hängt von Unternehmensgröße, Risikoappetit, Komplexität und der Frage ab, ob ein Parallelbetrieb überhaupt praktikabel ist.
Die zweite Achse betrifft die inhaltliche Tiefe des Wechsels. Beim Greenfield-Ansatz wird das neue ERP auf der grünen Wiese neu aufgesetzt: Prozesse werden anhand von Standards und Best Practices neu modelliert, und nur bewusst ausgewählte Stammdaten und Salden werden übernommen. Der Charme liegt im sauberen Neuanfang — Altlasten, obsolete Prozesse und über Jahre gewachsene Sonderlocken fallen weg, das System startet standardnah und bleibt gut wartbar. Der Preis ist ein höherer Aufwand im Prozess-Redesign und im Change Management, weil sich die Organisation auf neue Abläufe einlassen muss. Greenfield passt besonders, wenn die Altprozesse ohnehin reformbedürftig sind.
Beim Brownfield-Ansatz wird das Bestandssystem so weit wie möglich übernommen und technisch überführt: Prozesse, Anpassungen und historische Daten bleiben weitgehend erhalten, die Umstellung konzentriert sich auf Architektur und Plattform. Vorteil ist die größere Kontinuität und der oft kürzere Zeitraum, weil das Rad nicht neu erfunden wird. Nachteil ist, dass man Altlasten mitnimmt — technische Schulden, nicht mehr benötigte Anpassungen und veraltete Prozesse wandern mit ins neue System. Brownfield passt, wenn die bestehenden Prozesse tragfähig sind und ein Neuaufbau unverhältnismäßig wäre.
In der Praxis mischen viele Projekte beide Ansätze und wählen einen selektiven Mittelweg: Man setzt neu auf, übernimmt aber gezielt bewährte Prozesse und Daten. Entscheidend ist weniger das Etikett als die zugrunde liegende Frage — wie viel Erneuerung will und braucht die Organisation, und wie viel Kontinuität ist geschäftskritisch? Eine ehrliche Bestandsaufnahme steht deshalb vor der Methodenwahl, nicht danach.
Die passende Kombination folgt aus mehreren Faktoren, die gemeinsam betrachtet werden sollten: der Komplexität und Größe der Systemlandschaft, dem Risikoappetit des Unternehmens, der Qualität und dem Alter der bestehenden Prozesse, der Datenmenge und -qualität, der Verfügbarkeit interner Kapazitäten sowie der Frage, ob und wie lange ein Parallelbetrieb überhaupt tragbar ist. Ein kleiner, überschaubarer Betrieb mit sauberen Prozessen fährt oft gut mit einem Big-Bang-Greenfield; ein internationaler Konzern mit vielen Gesellschaften tendiert zum stufenweisen Rollout. Diese Entscheidung sollte dokumentiert und begründet werden — sie ist später nur mit erheblichem Aufwand revidierbar und prägt Kosten und Risiko über die gesamte Projektlaufzeit.
Am Anfang steht eine oft übersprungene Frage: Welche Daten sollen eigentlich migriert werden? Nicht alles, was im Altsystem liegt, muss ins neue System. Grob unterscheidet man Stammdaten (Kunden, Lieferanten, Artikel, Konten — die stabilen Grundlagen), Bewegungsdaten (Aufträge, Buchungen, Belege — das laufende Geschäft) und historische Daten (abgeschlossene Vorgänge früherer Perioden). Eine bewährte Haltung ist, so viel wie nötig und so wenig wie möglich zu migrieren: offene Posten und aktive Stammdaten werden meist übernommen, während für abgeschlossene Historie häufig ein Archiv genügt, statt sie in das neue System zu pressen. Diese bewusste Auswahl reduziert Aufwand, Risiko und spätere Altlasten erheblich.
Der Wechsel eines ERP-Systems legt gnadenlos offen, wie es um die Datenqualität bestellt ist. Über Jahre sammeln sich Dubletten, veraltete Datensätze, uneinheitliche Schreibweisen, unvollständige Felder und Karteileichen an. Die Datenbereinigung — das Identifizieren, Zusammenführen, Korrigieren oder Aussortieren solcher Datensätze — ist regelmäßig aufwendiger als geplant und wird oft als lästige Nebenarbeit unterschätzt. Dabei ist sie der wichtigste Hebel für den Erfolg: Saubere Daten machen das neue System leistungsfähiger, während übernommene Altlasten das architektonische Potenzial verschenken und im schlimmsten Fall falsche Bestände, Buchungen oder Auswertungen erzeugen.
Ein wichtiger Grundsatz lautet daher: Die Bereinigung gehört an den Anfang und sollte möglichst früh und getrennt vom eigentlichen Umschalten laufen. Idealerweise beginnt sie schon im Altsystem, lange bevor migriert wird — je sauberer die Ausgangsdaten, desto einfacher und risikoärmer der spätere Transfer. Wer sie ans Ende schiebt, steht kurz vor dem Go-Live unter Zeitdruck vor einem Berg an Datenproblemen, die dann nur noch notdürftig gelöst werden.
Selten passen die Datenstrukturen von Alt- und Neusystem eins zu eins zusammen. Das Mapping beschreibt die Zuordnungsregeln: Welches Feld im Altsystem entspricht welchem Feld im neuen System, wie werden Codes und Schlüssel umgesetzt, wie werden mehrere alte Felder auf eine neue Struktur verdichtet oder umgekehrt aufgeteilt? Diese Zuordnung ist oft kleinteilig und fachlich anspruchsvoll, weil sie tiefes Verständnis beider Systeme und der zugrunde liegenden Prozesse verlangt — sie ist keine reine IT-Aufgabe, sondern erfordert die Fachbereiche.
Nach der Übertragung folgt die Validierung: die systematische Prüfung, ob die Daten korrekt, vollständig und konsistent im neuen System angekommen sind. Dazu gehören Abgleiche von Summen und Salden (stimmt die Summe der offenen Posten überein?), Stichproben einzelner Datensätze, Vollständigkeitsprüfungen (ist die erwartete Anzahl an Kunden vorhanden?) und fachliche Plausibilitätskontrollen durch die Anwender. Bewährt hat sich, die Migration in mehreren Testläufen zu proben (Probemigrationen), bevor sie produktiv geschieht — so entdeckt man Mapping-Fehler und Datenprobleme, solange sie noch folgenlos korrigierbar sind.
Ein verbreitetes Missverständnis ist, die Datenmigration sei Sache der IT oder des Dienstleisters. Technisch werden die Werkzeuge dort bedient, doch die Entscheidung, welche Daten korrekt, relevant und bereinigungswürdig sind, kann nur der Fachbereich treffen — er kennt die Bedeutung der Datensätze. Erfolgreiche Projekte machen die Datenverantwortung deshalb früh explizit: Für jeden Datenbereich wird benannt, wer für Qualität, Bereinigung und fachliche Abnahme zuständig ist. So wird aus einer diffusen technischen Aufgabe eine steuerbare, mit Verantwortlichen hinterlegte Teildisziplin.
Für das Vorgehensmodell gibt es keinen Dogmatismus. Ein klassisch-sequenzielles Vorgehen (Phase für Phase, mit definierten Meilensteinen und Freigaben) gibt Planungssicherheit und passt gut, wenn Anforderungen früh klar sind und ein fester Stichtag existiert. Ein agiles oder iteratives Vorgehen (in kurzen Zyklen, mit regelmäßigem Feedback und schrittweiser Verfeinerung) hilft, wenn Anforderungen unsicher sind und man früh sichtbare Ergebnisse braucht. In der Praxis überwiegen hybride Modelle: Der Gesamtrahmen ist grob geplant, einzelne Bereiche werden iterativ ausgestaltet. Wichtiger als das Etikett ist, dass Meilensteine, Verantwortlichkeiten und Freigaben klar geregelt sind.
Die häufigste und teuerste Fehlerquelle im Projektvorgehen ist eine falsche Reihenfolge. Strategie, Prozessdesign und Datenqualität gehören an den Anfang, nicht ans Ende. Wer zuerst konfiguriert und erst spät über die Prozesse und die Datenmigration nachdenkt, baut auf Sand: Änderungen am Konzept werden mit fortschreitendem Projekt immer teurer, und ungelöste Datenprobleme türmen sich bis kurz vor den Go-Live auf. Ein gutes Projekt investiert bewusst früh in Klärung und Vorbereitung — die vermeintlich langsamere erste Phase zahlt sich in der späteren Umsetzung um ein Vielfaches aus.
Ein tragfähiges Migrationsteam vereint mehrere klar benannte Rollen. Die Projektleitung steuert Zeit, Budget, Umfang und Risiken und ist die zentrale Entscheidungsinstanz auf operativer Ebene. Ein Lenkungsausschuss (Steering Committee) aus Geschäftsführung und Bereichsleitung trifft die großen Weichenstellungen, gibt Ressourcen frei und löst Konflikte, die das Team nicht lösen kann — sichtbares Engagement der Leitung ist erfahrungsgemäß einer der stärksten Erfolgsfaktoren. Die Key User aus den Fachbereichen bringen das Prozesswissen ein, testen, definieren Anforderungen und werden später zu Multiplikatoren und ersten Ansprechpartnern für ihre Kolleginnen und Kollegen.
Hinzu kommen technische und fachliche Rollen: Berater und Implementierungspartner bringen Systemwissen und Methodik mit, ersetzen aber weder die Entscheidungen noch das Prozesswissen des Unternehmens. Datenverantwortliche kümmern sich um Qualität, Bereinigung und Abnahme je Datenbereich (siehe Kapitel 03). Interne oder externe Technik- und Integrationsfachleute verantworten Konfiguration, Schnittstellen und Betrieb. Wichtig ist, dass diese Rollen ausdrücklich besetzt und mit Zeit ausgestattet werden — nicht als Zusatzaufgabe nebenbei, sondern mit echter Freistellung vom Tagesgeschäft.
Ein weit verbreiteter Trugschluss lautet, ein externer Dienstleister könne die Migration weitgehend allein stemmen. Externe Beratung kann viel abnehmen, aber die geschäftskritischen Entscheidungen, das Prozesswissen und die Datenverantwortung bleiben im Unternehmen. Fachbereiche müssen Prozesse beschreiben, Daten bewerten, testen und neue Abläufe lernen — parallel zum laufenden Betrieb. Wer diese Kapazität nicht plant und freistellt, finanziert sie unsichtbar über Überstunden, verschobene Aufgaben und sinkende Qualität. Eine ehrliche Ressourcenplanung, inklusive der Frage, ob das Projekt jetzt überhaupt stemmbar ist, gehört an den Anfang.
Ein ERP-Wechsel verändert Arbeitsweisen, Oberflächen und Verantwortlichkeiten — und Menschen reagieren auf Veränderung oft mit Skepsis oder Widerstand. Change Management bedeutet, diesen menschlichen Faktor systematisch zu begleiten: früh und ehrlich kommunizieren, warum der Wechsel nötig ist und was er den Anwendern bringt; Betroffene einbinden statt zu überrumpeln; rechtzeitig und praxisnah schulen; und in der Anfangsphase spürbare Unterstützung anbieten. Projekte, die Schulung und Kommunikation als Nebensache behandeln, ernten nach dem Go-Live Produktivitätseinbrüche, Workarounds und Frust. Technik lässt sich projektieren — Akzeptanz muss man verdienen, und zwar von Beginn an.
Bestimmte Fehler tauchen in gescheiterten oder entgleisten Projekten immer wieder auf. Zu den häufigsten gehören:
Ein besonders tückisches Risiko entsteht aus Zeitdruck — etwa durch ein nahendes Wartungsende des Altsystems oder einen fixen Stichtag. Druck ist zunächst legitim und kann helfen, ein Projekt überhaupt zu starten. Gefährlich wird er, wenn er dazu führt, Vorbereitung, Datenbereinigung, Tests oder Change Management zu überspringen. Ein überstürzter Go-Live ohne saubere Datenbasis ist fast immer teurer als ein etwas späterer, gut vorbereiteter Start. Sinnvoll ist deshalb, frühzeitig zu planen, sich Puffer und gegebenenfalls verlängerte Wartungsoptionen als Sicherheitsnetz zu erhalten und den Stichtag an der Reife des Projekts auszurichten — nicht umgekehrt.
Die gute Nachricht: Nahezu alle genannten Risiken sind durch bewusste Planung adressierbar. Ein aktives Risikomanagement benennt die Gefahren früh, bewertet ihre Wahrscheinlichkeit und Wirkung und hinterlegt Gegenmaßnahmen. Konkret heißt das: die Datenmigration früh und ernsthaft angehen, ein klares Zielbild dokumentieren, Standard vor Individualität stellen, Change Management und Tests von Anfang an einplanen, interne Kapazitäten freistellen, einen belastbaren Rückfallplan definieren und realistisch mit Puffern kalkulieren. Keine dieser Maßnahmen ist spektakulär — ihre konsequente Anwendung unterscheidet aber die gelungenen von den entgleisten Projekten.
Tests sind kein Formalismus, sondern die günstigste Gelegenheit, Fehler zu finden, bevor sie im Produktivbetrieb Schaden anrichten. Sinnvoll ist ein mehrstufiges Vorgehen: Funktionstests prüfen, ob einzelne Funktionen und Prozesse korrekt arbeiten. Integrationstests stellen sicher, dass das Zusammenspiel mit Umsystemen und über Prozessgrenzen hinweg funktioniert — oft die eigentliche Schwachstelle. End-to-End-Tests bilden komplette Geschäftsvorfälle vom Anfang bis zum Ende ab (etwa vom Auftrag bis zur Rechnung). Ergänzend prüfen Last- und Performancetests, ob das System auch unter realer Belastung trägt. Besonders wertvoll ist der Anwendertest (User Acceptance Test), bei dem die Fachbereiche das System an realen Fällen prüfen und abnehmen.
Der Produktivstart sollte an klar definierten Go-Live-Kriterien hängen, nicht allein an einem Kalenderdatum. Typische Kriterien sind: Die kritischen Tests sind bestanden, die Datenmigration ist validiert, die Anwender sind geschult, die Berechtigungen sind eingerichtet, der Betrieb ist vorbereitet, und es gibt einen Rückfallplan für den Fall, dass etwas Grundlegendes schiefgeht. Ein gutes Projekt definiert diese Kriterien früh und trifft die Go-Live-Entscheidung bewusst in einer gemeinsamen Freigabe (Go/No-Go), statt den Stichtag blind durchzudrücken. Ebenso wichtig ist die Wahl eines geeigneten Zeitpunkts — häufig ein ruhigeres Geschäftsfenster oder ein Perioden- beziehungsweise Jahreswechsel, sofern die Umstände es zulassen.
Mit dem Go-Live ist das Projekt nicht beendet, sondern tritt in seine sensibelste Phase ein. In der Hypercare-Phase — der intensiven Begleitung unmittelbar nach dem Produktivstart — laufen erfahrungsgemäß viele Fragen und Fehler auf, weil erst der echte Betrieb alle Details ans Licht bringt. Erfolgreiche Projekte planen diese Phase bewusst: Ansprechpartner sind gut erreichbar, Fehler werden priorisiert und schnell behoben, Anwenderfragen werden ernst genommen, und Prozesse werden bei Bedarf nachjustiert. Diese Wochen prägen maßgeblich, wie die Belegschaft das neue System wahrnimmt — wer hier präsent und lösungsorientiert ist, gewinnt Vertrauen; wer die Anwender allein lässt, riskiert dauerhafte Ablehnung.
Nach der Stabilisierung folgt der geordnete Übergang in den Regelbetrieb: Das Altsystem wird kontrolliert abgeschaltet oder für Archivzwecke in einen Nur-Lese-Zustand überführt, die Verantwortung wandert vom Projektteam in die Linienorganisation, und der Erfolg wird an den anfangs definierten Zielen gemessen. Erst jetzt lässt sich seriös beurteilen, ob die Migration ihre Ziele erreicht hat — und welche Optimierungen als Nächstes anstehen.
Mittelständische Unternehmen haben in der Regel keine große IT-Abteilung, kein eigenes Projektbüro und keine Mitarbeiter, die man monatelang vollständig für ein Projekt freistellen kann. Zugleich sind ihre Prozesse oft historisch gewachsen und stark individualisiert, weil sie als Wettbewerbsvorteil verstanden werden. Diese Kombination — begrenzte Kapazität bei gleichzeitig hoher Prozessindividualität — macht die Migration heikel: Der Aufwand für Anpassung und Betreuung übersteigt schnell das, was intern zu leisten ist. Erfolgreiche Mittelstandsprojekte begegnen dem mit Fokus und Standardorientierung statt mit dem Versuch, jedes Detail nachzubilden.
Hier liegt der wichtigste Hebel. Jede beibehaltene Eigenheit erhöht Aufwand, Kosten und Betriebsrisiko und erschwert künftige Updates. Erfolgreiche Projekte trennen deshalb konsequent zwischen den wenigen Prozessen, die wirklich differenzieren und eine individuelle Lösung rechtfertigen, und der großen Mehrheit der Prozesse, die sich ohne Schaden standardisieren lassen. Diese Übung ist unbequem, weil sie lieb gewonnene Gewohnheiten infrage stellt — aber sie ist der eigentliche Schlüssel zu einem bezahlbaren und wartbaren System. Ein guter Partner rät konsequent zum Standard und hinterfragt Sonderwünsche kritisch, statt jeden Wunsch zu erfüllen.
Über viele Mittelstandsprojekte hinweg zeigen sich einige wiederkehrende Faktoren, die den Ausschlag geben:
Der Aufwand einer ERP-Migration lässt sich seriös nicht pauschal beziffern — er hängt von Umfang, Strategie, Datenmenge, Anpassungstiefe und interner Reife ab und reicht von vergleichsweise schlanken, standardnahen Wechseln bis zu mehrjährigen Vorhaben. Verlässlich ist nur, dass er regelmäßig unterschätzt wird, vor allem beim internen Anteil. Eine belastbare Schätzung entsteht erst nach einer ehrlichen Bestandsaufnahme; jede Zahl davor ist im Einzelfall zu prüfen und mit Vorsicht zu genießen.
Der häufigste Kalkulationsfehler besteht darin, die Software- oder Lizenzkosten für die Gesamtkosten zu halten. Tatsächlich ist die Software oft der kleinere Posten — die Transformation drumherum dominiert die Rechnung. Exakte Zahlen lassen sich seriös nicht pauschal angeben (sie sind im Einzelfall zu prüfen), aber die relevanten Kostenblöcke sind gut bekannt:
Eine belastbare Betrachtung trennt einmalige Projektkosten von laufenden Betriebskosten und blickt über einen realistischen Zeithorizont von mehreren Jahren. Cloud-Modelle verschieben das Verhältnis von hohen Anfangsinvestitionen hin zu planbaren, aber dauerhaften Abokosten — über die Jahre summiert sich das. Echte Sparhebel liegen weniger im Drücken der Software-Konditionen als in guter Vorbereitung: saubere Daten verkürzen die Migration, konsequente Standardnutzung senkt Projekt- und Betriebskosten. Falsch gespart wird typischerweise an Tests, Schulung und Change Management — genau dort rächen sich unterlassene Investitionen später.
Eine ERP-Migration verarbeitet in aller Regel personenbezogene Daten — von Kunden, Lieferanten und häufig auch Beschäftigten. Damit greift die Datenschutz-Grundverordnung (DSGVO), und zwar nicht erst im Betrieb, sondern schon während der Migration selbst. Grundsätze wie Datenminimierung und Zweckbindung bedeuten konkret: Es sollten nur die Daten migriert werden, die im neuen System wirklich gebraucht werden, und nicht pauschal der gesamte Altbestand. Die Migration ist damit auch ein guter Anlass, sich von Daten zu trennen, die ohnehin nicht mehr benötigt werden — sofern keine Aufbewahrungspflichten entgegenstehen.
Konkret gehören zur datenschutzkonformen Migration unter anderem: die frühzeitige Einbindung der oder des Datenschutzbeauftragten, ein Löschkonzept für Altdaten (was wird migriert, was archiviert, was gelöscht — und wann), die vertragliche Absicherung mit Dienstleistern über einen Auftragsverarbeitungsvertrag (AVV), die Klärung des Datenstandorts und der Datenhoheit (vor allem bei Cloud-Umzügen: Wo liegen die Daten, wer hat Zugriff, gilt EU-Recht?), ein sauberes rollenbasiertes Berechtigungskonzept nach dem Prinzip der Datensparsamkeit sowie der sichere Umgang mit Test- und Migrationsdaten, die häufig Kopien echter personenbezogener Datensätze enthalten.
