Legacy-ERP ablösen, ohne Datenverlust und ohne Blindflug im Abschluss

Wann sich ein Wechsel lohnt und wann nicht

Dieser Abschnitt ist absichtlich in beide Richtungen geschrieben. Nutzen Sie ihn als Selbsttest, bevor Sie mit irgendeinem Anbieter sprechen, auch mit uns.

Vier Risiken, die aus dem Herstellerverhalten kommen

Nicht das Alter eines Systems entscheidet, sondern wer über die Entwicklungsreihenfolge bestimmt. Die folgenden Punkte sind belegt und ohne Wertung formuliert. Sie sind Beispiele für Muster, die in vielen Auswahlverfahren auftauchen, und keine Aussage über die Qualität eines Produkts.

Datenmigration aus einem System ohne Schnittstelle

Diesen Teil erledigen die meisten Angebote mit einer Zeile. Dabei wohnt hier der größte Teil des Projektrisikos. Wir arbeiten mit vier Ebenen und beginnen immer mit der günstigsten.

1. Ebene 1: der Export des Herstellers

   Fast jedes gewachsene System erzeugt eine Datei für die Buchhaltung, eine CSV- oder XML-Ausgabe, manchmal eine alte, aber funktionierende ODBC-Sicht. Das ist der günstigste Kanal, niemand widerspricht, und Ihr Vertrag bleibt unberührt. Der Nachteil: Diese Exporte sind meist auf den Finanzkern zugeschnitten. Eigene Felder im Artikelstamm, abweichende Lieferadressen und die Auftragshistorie passen selten hinein.

2. Ebene 2: eine lesende Kopie der Datenbank

   Hier beginnt die eigentliche Arbeit. Wir stellen die tägliche Sicherung auf einem separaten Server wieder her und lesen von dort, die Produktivumgebung trägt also keine zusätzliche Last. Auf Microsoft SQL Server über eine wiederhergestellte Kopie oder eine lesbare Replik, auf PostgreSQL über logische Replikation, auf Oracle über einen Data-Pump-Export, auf Firebird über gbak oder nbackup. Das Schema zu verstehen ist Handarbeit: abgekürzte Tabellennamen, oft in der Sprache des Herstellers, ohne Dokumentation. Bei einem mittelgroßen System dauert es zwei bis drei Wochen, bis von 600 Tabellen die 40 gefunden sind, in denen die betriebswirtschaftliche Wahrheit steht.

3. Ebene 3: Daten, die das Haus bereits verlassen haben

   Der selten genutzte Trick. Belege, die an eine Behörde, an ein Rechnungsportal oder an die Steuerberatung übermittelt wurden, liegen dort in strukturierter Form vor und lassen sich zurückholen. Diese Menge ist eine unabhängige Gegenprobe zu Ihrem eigenen Export. Decken sich die beiden nicht, liegt das Problem nicht an der Migration, sondern an den Ausgangsdaten, und das erfährt man besser in Woche drei als beim ersten Abschluss.

4. Ebene 4: Robotik, und wirklich erst zuletzt

   Kommt ein Datum auf keinem anderen Weg heraus, steuern wir den Desktop-Client maschinell: anmelden, Liste öffnen, filtern, Exportknopf. Das ist langsam, zerbrechlich, und jedes Update kann es kaputtmachen. Bei uns ist es nie der Hauptkanal, sondern das Nachreichen von ein bis zwei fehlenden Feldern, meist mit einem einzigen Lauf. Wer eine vollständige Migration darauf aufbaut, legt das Projektrisiko an die schlechtestmögliche Stelle.

Eines prüfen wir immer vor Projektbeginn: was Ihr Softwarevertrag zum direkten Datenbankzugriff sagt. Mancherorts ist er genehmigungspflichtig. Dann fordern wir den Export beim Hersteller an und arbeiten statt mit Ebene 2 mit einer Kombination aus Ebene 1 und 3. Das ist langsamer, aber sauber.

Was am Datenbestand gemessen wird, bevor jemand umstellt

Eine Migration ist fertig, wenn sie sich mit Zahlen belegen lässt. Die folgenden Prüfungen laufen in jedem Projekt, und das Protokoll unterschreibt auch die Buchhaltung.

• Datensatzzahlen je Tabelle auf Quell- und Zielseite. Weichen sie ab, sind logisch gelöschte Zeilen die häufigste Ursache. Gewachsene Systeme setzen gern ein Statusfeld, statt wirklich zu löschen.
• Summen je Steuersatz und Periode. Entscheidend ist nicht die Endsumme, sondern die Aufteilung, denn unterschiedliche Rundungslogik schlägt genau dort durch.
• Zeichenkodierung. In fünfzehn Jahre alten Datenbanken ist gemischte Kodierung Normalität, sichtbar zuerst an Umlauten und am Eszett in Partnernamen. Das gehört ins Migrationsskript und nicht in eine nachträgliche Handkorrektur.
• Versteckte Geschäftslogik in Freitextfeldern. Wenn Kolleginnen und Kollegen seit zehn Jahren Kürzel ins Bemerkungsfeld schreiben, sind das echte Daten. Sie herauszulösen und in richtige Felder zu überführen, gehört zur Migration.
• Offene Posten getrennt behandeln. Offene Debitoren und Kreditoren, Bestandsmengen und Kontokorrentsalden werden im Moment der Umstellung übernommen und nicht zusammen mit der Historie.

Parallelbetrieb und Umstellung

Die Reihenfolge ist wichtiger als der Kalender. Die folgende Aufteilung gilt für ein mittleres Projekt mit fünf bis sieben Modulen. Die genauen Zeiträume legen wir nach dem Erstgespräch fest, weil sich der Zustand der Datenschicht vorher nicht schätzen lässt.

1. Migrationsanalyse

   Schema aufnehmen, Sicherung wiederherstellen, Stichproben ziehen, fehlende Datenkanäle benennen. Am Ende wissen Sie, was herauskommt und was nicht. Stellt sich dabei heraus, dass die Ablösung überflüssig ist, sagen wir das.

2. Historie laden

   Erst Stammdaten, dann Bewegungsdaten. Wir schreiben die Ladeskripte idempotent, damit sie beliebig oft neu laufen können, denn in der Praxis werden daraus fünf bis sechs Durchläufe.

3. Schattenbetrieb

   Das neue System bekommt dieselben Tagesbuchungen, führend bleibt das alte. Täglicher automatischer Abgleich, der Abweichungsbericht liegt morgens vor.

4. Ein vollständiger Monatsabschluss in beiden Systemen

   Das ist die eigentliche Prüfung. Summen- und Saldenliste, Basisdaten der Umsatzsteuer-Voranmeldung, Bestandsbewertung. Die Toleranz wird vorher schriftlich festgelegt, und solange sie nicht eingehalten ist, findet keine Umstellung statt.

5. Umstellung und die Zeit danach

   Offene Posten werden an einem stillgelegten Wochenende übernommen, danach geht das neue System produktiv. Das Altsystem bleibt lesbar, und die Möglichkeit zur Rückkehr halten wir bis zum ersten Abschluss offen.

Warum ein Team aus Budapest

Eine Migration ist Handarbeit an Ihren Daten, und dafür brauchen Sie Menschen, die in Ihrer Zeitzone erreichbar sind und im gleichen Rechtsraum arbeiten. Budapest liegt rund zwei Flugstunden entfernt, Ungarn ist EU-Mitgliedstaat, ein Drittlandtransfer entsteht also nicht. Der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO wird vor Projektbeginn geschlossen, Standardvertragsklauseln und ein Transfer Impact Assessment entfallen. Wir liefern als Werkvertrag mit definierter Abnahme, wo das Ergebnis beschreibbar ist.

Zur Einordnung der Kosten, mit benannten Quellen statt mit Behauptungen: Der Freelancer-Kompass 2026, eine Panelbefragung unter IT-Freelancern im DACH-Raum, veröffentlicht am 02.07.2026, nennt einen Medianstundensatz von 95 EUR, in der Softwareentwicklung 90 EUR und bei SAP und ERP 120 EUR. Für Nearshore-Sätze gibt es keine vergleichbare repräsentative Erhebung, mehrere deutsche Branchenquellen aus 2026 nennen übereinstimmend 30 bis 50 Prozent Ersparnis gegenüber Onshore. Wir rechnen ohnehin nicht nach Stunden, sondern als Festpreisspanne je Projekt, und diese Spannen stehen öffentlich auf unserer Preisseite.

Zum Thema Datenhaltung eine Zahl, die deutsche Einkäufer inzwischen mitbringen: Im Cloud Report 2026 des Bitkom, veröffentlicht am 17.06.2026 auf Basis von 603 befragten Unternehmen ab 20 Mitarbeitenden, halten 98 Prozent die Herkunft des Anbieters für wichtig, und 68 Prozent würden einen Anbieter aus der EU bevorzugen. Wir betreiben in der EU und legen die Unterauftragsverarbeiter offen. Wo Daten das Haus nicht verlassen dürfen, läuft der Betrieb bei Ihnen.

Ein Satz zur Erfahrung mit lokalen Meldepflichten, weil er erklärt, warum wir das Thema E-Rechnung nüchtern behandeln: In Ungarn liefern wir seit Jahren die Echtzeitmeldung von Ausgangsrechnungen an die Steuerbehörde, samt Nachziehen jeder Schemaversion im Wartungsvertrag. Technisch ist eine XRechnung-Schnittstelle dieselbe Bauart mit anderem Format.