Das System wurde vor Jahren individuell programmiert, die ursprünglichen Entwickler sind weg, die Geschäftslogik ist nirgends dokumentiert — und jedes Jahr steigt das Risiko. Dreher Consulting begleitet den Wechsel anbieterneutral: dokumentierte Bestandsaufnahme, belastbares Migrationskonzept, kontrollierter Parallelbetrieb und Cut-over. Über 1.200 Projekte seit 1992.
Bei einem ERP-Wechsel wird ein System außer Betrieb genommen, auf das Ihr Unternehmen nach wie vor angewiesen ist – oft handelt es sich dabei um eine individuell programmierte Lösung, die seit fünfzehn oder zwanzig Jahren mit dem Unternehmen gewachsen ist. Der Vorgang erfolgt als kontrollierter Übergang: Die Funktionen des Altsystems werden dokumentiert, eine Nachfolgelösung ausgewählt, die Daten migriert und beide Systeme parallel betrieben, bis sich das neue System bewährt hat.
Unserer Erfahrung nach liegt das Risiko selten bei der neuen Software – sondern bei der alten: undokumentierte Geschäftslogik, Datenqualität, die niemand gemessen hat, Schnittstellen, an die sich niemand heranwagt. Deshalb beginnt der Wechsel mit einer dokumentierten Bestandsaufnahme und nicht mit einer Anbieter-Demo. Die Auswahl des Nachfolgesystems selbst erfolgt im Rahmen einer strukturierten ERP-Auswahl mit Longlist, Shortlist und Bewertungsmatrix. Und wenn Ihr Anliegen nicht ein veraltetes System ist, sondern eine bereits in Schwierigkeiten geratene Implementierung, handelt es sich um einen anderen Auftrag: ERP-Projektrettung.
Möchten Sie eine ehrliche Einschätzung darüber erhalten, wie hoch das Risiko ist, das Ihr Altsystem birgt?
Mit uns den Wechsel Ende-zu-Ende planen →Lesen Sie sich das kurz durch, bevor Sie eine Besprechung dafür aufwenden. Wenn das meiste davon auf Ihre Situation zutrifft, lohnt es sich, eine Erneuerung in Betracht zu ziehen – sollte dies nicht der Fall sein, werden wir Ihnen das mitteilen.
Die undokumentierten Regeln wurden rekonstruiert und schriftlich festgehalten.
Die Geschäftslogik ist ausschließlich im Code und in den Köpfen einiger weniger Personen verankert. Wenn diese das Unternehmen verlassen, geht auch das Wissen verloren – und das System kann nicht mehr sicher geändert oder ersetzt werden.
Zugriff auf den Quellcode und das Datenbankschema, sofern verfügbar, auf die Berichte, die das Unternehmen tatsächlich nutzt, sowie Zeit mit den Mitarbeitern, die noch wissen, wie sich das System verhält.
Analysieren Sie die Systemlandschaft und die Geschäftsregeln aus mehreren Blickwinkeln gleichzeitig – Schema, Code, Live-Berichte und strukturierte Interviews – und halten Sie diese schriftlich fest.
Ein Dokument zur Systemarchitektur und Geschäftslogik: Die bisher undokumentierten Regeln, Schnittstellen und Abhängigkeiten werden in einer Form festgehalten, auf der das Nachfolgeprojekt aufbauen kann.
Es erfasst die Logik, die nur im Code und in den Köpfen der Menschen existiert – sodass die Ersetzung nun von beidem unabhängig ist.
Jede geschäftskritische Regel und Schnittstelle ist dokumentiert und bis zu ihrer Quelle zurückverfolgbar; es gibt keine Regel mehr, die nur eine einzige Person erklären kann.
Was die Daten wert sind und wie sie sich entwickeln.
Niemand weiß, welchen Wert die Altdaten tatsächlich haben – wie viel sich problemlos migrieren lässt, wie viel noch bearbeitet werden muss und wie viel auf keinen Fall übernommen werden sollte.
Lesezugriff auf die Produktionstabellen, die geltenden Aufbewahrungsregeln und die Liste der Prozesse, die die Daten nach der Umstellung unterstützen müssen.
Erstellen Sie ein Profil der tatsächlichen Tabellen, klassifizieren Sie die Datensätze als „migrieren“, „bereinigen“ oder „archivieren“ und entwerfen Sie eine schrittweise Migration mit Testladungen und Abgleichzahlen.
Ein Bericht zur Datenqualität und ein Migrationskonzept, die anhand realer Tabellen erstellt wurden und in denen der Migrationspfad sowie der Abgleichansatz dargelegt sind.
Darin wird festgelegt, was migriert, was bereinigt und was archiviert wird – noch bevor jemand einen Implementierungsvertrag unterzeichnet.
Die Datenqualität wird anhand der tatsächlichen Tabellen gemessen und nicht nur angenommen; für jede Tabelle liegt eine dokumentierte Entscheidung zur Migration, Bereinigung oder Archivierung vor.
Standard-ERP, Umstellung auf eine neue Plattform oder Beibehaltung – bereit für die Vorstandssitzung.
Der Vorstand muss entscheiden, ob das System ersetzt, auf eine neue Plattform umgestellt oder beibehalten werden soll – doch ohne festgelegte Kriterien hängt die Entscheidung letztlich vom Bauchgefühl oder vom Druck der Anbieter ab.
Die Ergebnisse der Bestandsaufnahme und die Daten aus der Bewertung, die Kostenentwicklung des derzeitigen Systems sowie die funktionalen Prioritäten des Unternehmens.
Wägen Sie Wissensrisiken, funktionale Eignung und Kosten anhand festgelegter Kriterien ab und stellen Sie die Nachfolgeoptionen mit ihren jeweiligen Konsequenzen dar.
Ein vor dem Vorstand vorlegbarer Entscheidungspfad für die Nachfolge: Standard-ERP, Plattformwechsel oder Beibehaltung – wobei die Systemauswahl an „ERP Selection“ übergeben wird.
Das Ergebnis ist eine Entscheidung, die der Vorstand vertreten kann; die Systemauswahl wird an „ERP Selection“ übergeben, nicht an eine Auswahlliste von Anbietern.
Die Empfehlung lässt sich auf klare Kriterien zurückführen, die der Vorstand begründen kann; die Entscheidung wird auf der Grundlage von Fakten getroffen, nicht aus dem Bauch heraus.
Wie die Umstellung erfolgt – mit schriftlich vereinbarten Kriterien für eine Rücknahme.
Gerade bei der Umstellung auf das neue System scheitern die Ersetzungen – und die während des Umstellungswochenendes improvisierten Rollback-Regeln bieten keinen Schutz.
Das Migrationskonzept, die Geschäftszyklen, in denen sich der Nachfolger bewähren muss, und die Einigung darüber, wer die Entscheidung über „Go“ oder „No-Go“ trifft.
Planen Sie den Parallelbetrieb und die Umstellung: Welche Zyklen müssen durchlaufen werden, wie lange laufen die Systeme parallel, und welche Kriterien gelten für den Ausstieg und den Rollback – alles schriftlich festhalten.
Ein Plan für die Umstellung und den Parallelbetrieb mit Ausstiegs- und Rollback-Kriterien, der vor der Inbetriebnahme schriftlich vereinbart wurde.
Die Kriterien für die Rückführung werden vor der Inbetriebnahme schriftlich festgelegt – sie werden nicht erst am Umstellungswochenende ausgehandelt.
Die Kriterien für den Ausstieg und die Rücknahme werden vor der Inbetriebnahme schriftlich vereinbart; das Nachfolgesystem wird anhand vollständiger Geschäftszyklen, einschließlich eines vollständigen Monatsabschlusses, getestet.
Was muss für die Wirtschaftsprüfer lesbar bleiben (GoBD), was wird ausgeblendet?
Nach der Inbetriebnahme bleibt das alte System bestehen – seine Wartung ist kostspielig, seine Abschaltung birgt Risiken, und es unterliegt Aufbewahrungsvorschriften, die niemand erfasst hat.
Die geltenden gesetzlichen Aufbewahrungsfristen, die steuerrelevanten Daten im Altsystem sowie die Freigabe des Lesezugriffs, den die Prüfer benötigen. de
Legen Sie fest, welche Daten in welcher Form und wie lange lesbar bleiben sollen, und legen Sie ein Löschdatum fest, zu dem die Aufbewahrungs- und Leserechtspflichten erfüllt sind.
Ein Konzept für die Stilllegung und Aufbewahrung: Was bleibt für die Wirtschaftsprüfer lesbar (GoBD), was wird abgeschaltet und wann.
Es umfasst die Zeit nach Abschluss des Projekts: Aufbewahrungsfristen, Lesezugriff für Prüfer und einen Termin für die Abschaltung, der tatsächlich eintritt.
Steuerrelevante Daten bleiben während der gesetzlich vorgeschriebenen Aufbewahrungsfristen (GoBD) lesbar und maschinell auswertbar; für jede Altkomponente ist ein festgelegtes Abschaltdatum vorgesehen.
Bewerten, entscheiden, migrieren, umstellen – das Altsystem bleibt so lange in Betrieb, bis sich das Nachfolgesystem bewährt hat. In jeder Phase wird ein Dokument erstellt, auf dem die nächste Phase aufbaut, sodass die Entscheidung zu jedem Zeitpunkt nachvollziehbar ist.
Bei der Bestandsaufnahme wird das Altsystem als eine Quelle betrachtet, aus der man Informationen entnehmen kann, und nicht als eine Komponente, die einfach ausgetauscht werden muss. Wir kombinieren die Informationen, die sich noch aus der Datenbank und dem Code entnehmen lassen, mit dem Wissen, über das nur erfahrene Anwender verfügen.
Die Bewertung liefert die Grundlage für eine fundierte Entscheidung: Wie hoch ist das Wissensrisiko des Unternehmens, inwieweit ist die tägliche Arbeit dem System entwachsen und was kostet es tatsächlich, das System am Laufen zu halten?
Die Migration wird erst einmal simuliert, nicht tatsächlich durchgeführt. Im Rahmen von Testläufen werden die Daten in das Nachfolgesystem übertragen, und Abgleichszählungen belegen, dass die aus dem Altsystem übertragenen Daten vollständig angekommen sind.
Beide Systeme laufen parallel, bis sich das Nachfolgesystem über mehrere vollständige Geschäftszyklen hinweg bewährt hat – wobei die Ausstiegskriterien vor Beginn des Parallelbetriebs schriftlich vereinbart werden.
Der Umfang einer Umstellung richtet sich nach der Komplexität und nicht nach einer festgelegten Dauer – entscheidend sind die Anzahl der Prozesse, Datenobjekte und Schnittstellen sowie der Grad der Dokumentation und der Umfang der Informationen, die ausschließlich bei Schlüsselpersonen vorliegen. Vorrang haben dabei die Regeln, Daten und Schnittstellen, deren Verlust direkte Auswirkungen auf die Produktion, die Abrechnung, die Compliance oder den Kundenservice hätte.
Der Aufwand und die Dauer hängen von der Anzahl der Prozesse, Datenobjekte und Schnittstellen sowie vom Umfang der Dokumentation und der Verfügbarkeit der Personen ab, die sich mit dem System auskennen.
Vorrang haben dabei Regeln, Daten und Schnittstellen, deren Verlust die Produktion, die Abrechnung, die Einhaltung gesetzlicher Vorschriften oder den Kundenservice unmittelbar gefährdet.
Die Bestandsaufnahme könnte ergeben, dass eine Modernisierung oder der weitere Betrieb wirtschaftlicher ist als eine vollständige Erneuerung.
Eine ehrliche Bestandsaufnahme kann zeigen, dass eine Modernisierung oder die Beibehaltung des bestehenden Systems wirtschaftlicher ist als eine vollständige Erneuerung. Wenn dies das Ergebnis ist, sagen wir es auch – selbst wenn das bedeutet, dass das Mandat endet, bevor überhaupt Software angeschafft wird. So oder so: Sie entscheiden auf der Grundlage dokumentierter Fakten, nicht aufgrund einer Anbieter-Demo.
Die 12 entscheidenden Punkte beim Austausch eines maßgeschneiderten ERP-Systems.
Möbelhersteller
ProblemEin über Jahre hinweg entwickeltes maßgeschneidertes System wickelte den gesamten Auftragsfluss der Variantenfertigung ab – die Regeln waren im Code verankert, nichts war schriftlich festgehalten. Ohne diese Grundlage war weder ein Systemwechsel noch eine fundierte Investitionsentscheidung möglich.
EngagementBestandsaufnahme und Bewertung von mehr als 200 Prozessen im gesamten Werksnetzwerk, zusammengefasst in einer vorlegungsreifen Form: Was lässt sich standardisieren, was bleibt unverändert und welcher Weg ist der richtige für die Zukunft?
200+
Prozesse dokumentiert, zuvor keine · im Konzept berechnet
>20 %
Kostensenkung · im Konzept berechnet
~25 %
Aufwandsoptimierung · im Konzept berechnet
Das Konzept wurde gemeinsam mit dem Unternehmen entwickelt – die Umsetzung erfolgte intern. Kein Umsetzungsauftrag, keine Software-Provision.
Ehrliche Antworten zum Parallelbetrieb, zu undokumentierten Systemen und dazu, was mit den alten Daten geschieht – die Fragen, die bei fast jedem ersten Gespräch über eine Erneuerung aufkommen.
Antworten von
Dr. Harald Dreher
Gründer · Dreher Consulting
Seit 1992 begleitet er mittelständische Unternehmen bei der Ablösung selbst entwickelter ERP-Systeme. Er berät herstellerunabhängig und erhält von keinem Softwareanbieter Provisionen.
LinkedIn · Zuletzt aktualisiert: 21. Juli 2026
Ja – genau dafür ist der Parallelbetrieb gedacht. Das Altsystem bleibt während der Bewertung, Migration und Testphase das produktive System; das Nachfolgesystem übernimmt erst bei einer geplanten Umstellung, die in der Regel in einem zeitlichen Fenster mit geringem Betriebsaufkommen erfolgt. Solange die Ausstiegskriterien des Parallelbetriebs nicht erfüllt sind, wird nichts abgeschaltet, und ein schriftlicher Rollback-Plan regelt die Umstellung selbst.
Aus mehreren Richtungen gleichzeitig: dem Datenbankschema und, sofern zugänglich, dem Quellcode; den Berichten, die das Unternehmen tatsächlich nutzt; sowie strukturierten Interviews mit den Personen, die am längsten mit dem System gearbeitet haben. Jede gefundene Geschäftsregel wird schriftlich festgehalten und mit tatsächlichen Transaktionen abgeglichen, bis die Dokumentation das Verhalten des Systems genau wiedergibt. Das Ergebnis ist Wissen auf Papier – und nicht mehr nur Wissen im Kopf einer einzelnen Person.
Lang genug, um die Nachfolgesystemlösung über vollständige Geschäftszyklen hinweg zu testen – in der Regel mindestens einen vollständigen Monatsabschluss und alle Prozesse, auf die das Unternehmen angewiesen ist, von der Bestellung bis zur Rechnung. Die ehrliche Antwort lautet: Die Dauer ergibt sich aus den vereinbarten Ausstiegskriterien und nicht aus dem Kalender: Der Parallelbetrieb endet, wenn die Abstimmungswerte übereinstimmen, und nicht zu einem festgelegten Datum.
In den meisten Fällen ja, in lesbarer Form. Die deutschen Aufbewahrungsvorschriften (GoBD) verlangen, dass steuerrelevante Daten während der gesetzlichen Aufbewahrungsfristen lesbar und maschinell auswertbar bleiben – das Abschalten des Servers hebt diese Verpflichtung nicht auf. Das Stilllegungskonzept legt fest, wie dies geschehen soll: eine schreibgeschützte Instanz, eine Archivauskopplung oder die Aufbewahrung im neuen System, jeweils mit einem festgelegten Enddatum.
Nach Kriterien, nicht nach Instinkt. Bei der Entscheidungsfindung werden das Wissensrisiko (wer kann das System noch warten?), die funktionale Eignung (inwieweit ist die tägliche Arbeit darüber hinausgewachsen?), die Kostenentwicklung für den Weiterbetrieb sowie die Abhängigkeit von einer einzelnen Person oder einem einzelnen Anbieter abgewogen. Eine Modernisierung ist manchmal die richtige Lösung – das Ergebnis ist in jedem Fall eine vorlegungsreife Entscheidung für den Vorstand, keine ausgemachte Sache.
Sie werden im Rahmen der Bestandsaufnahme erfasst und einzeln klassifiziert: entweder durch das Standardsystem ersetzt, an die neuen APIs angepasst oder außer Betrieb genommen, da die entsprechenden Ausgaben nicht mehr genutzt werden. Jede Schnittstelle wird während des Parallelbetriebs getestet – keine Verbindung wird deaktiviert, bevor ihr Nachfolger Echtdatenverkehr verarbeitet hat.
Einblick
In Brief: The risk of a wrong ERP decision rarely lies in the software itself — it lies in unclear decision criteria, co…
Einblick
Key Points at a Glance The greatest risks associated with an ERP migration are organizational, not technical: underestim…
Einblick
The companies that will fail with AI in ERP in the next five years will not fail because of SAP Joule, Microsoft Copilot…
Das vollständige erste Gespräch. Inklusive einer ersten SCOReX®-Einordnung Ihrer ERP-Situation.
Gespräch buchen →Noch nicht bereit für das vollständige Gespräch? Ein kurzes Gespräch, um zu klären, ob wir die richtige Beratung für Sie sind.
Kurzgespräch buchen →Schreiben Sie uns kurz, wo Sie stehen – wir antworten mit einem klaren nächsten Schritt, nicht mit einem Verkaufsgespräch.
Schreiben Sie uns →