agorum® NORA | 360° Systemmigration im Produktivbetrieb, das Ergebnis vorab
Wir haben unseren gesamten Produktivbetrieb von agorum core smart organisation auf NORA | 360° umgestellt. Rund 400.000 Entitäten, gewachsen seit 2012. Die Migration lief an einem Wochenende. Am Montag arbeitete jede Abteilung weiter, es gab kaum Probleme.
Das Wichtigste für Entscheider in Kurzform:
- Umfang: rund 400.000 Entitäten wie Projekte, Aufgaben, Vorgänge, Kundenakten, Partnerakten, Lieferantenakten, Rechnungen, Angebote, Auftragsbestätigungen und Zeiterfassung.
- Historie: seit 2012 gewachsen, inklusive der über die Jahre entstandenen Automatismen.
- Anpassungsaufwand: hunderte Anpassungen an 18 Projekten, tausende Dateien, dazu die Schnittstelle zum ERP odoo.
- Vorbereitungszeit: mehrere Monate, davon drei komplette Durchläufe als Probe.
- Migrationsfenster: Freitag 18 Uhr bis Sonntag 21 Uhr, danach Freigabe für alle User.
- Ergebnis: kaum Störungen in der Woche nach dem Go-live, zwei Wochen später weiterhin ruhiger Betrieb.
- Nutzen: deutlich besserer Überblick und KI-Unterstützung in allen Unternehmensprozessen durch ALBERT | AI und das NORA | 360° AI Plugin.
Wir schreiben das nicht als Erfolgsmeldung. Wir schreiben es, weil sich die Frage, wie eine Systemmigration im Produktivbetrieb ohne Betriebsunterbrechung gelingt, nicht mit einem Werkzeug beantworten lässt, sondern nur mit einem Vorgehen. Dieses Vorgehen haben wir am eigenen laufenden Geschäft geprüft, mit allem, was daran hängt.
Was genau lief bei uns auf smart organisation?
Unser gesamter Unternehmensbetrieb lief auf agorum core smart organisation. Nicht ein Teilbereich, nicht ein Pilotprojekt. Der komplette Betrieb.
Konkret bedeutet das: das gesamte Vertriebsmanagement und CRM, das Projektmanagement, jeder Vorgang und jede Aufgabe, die in den jeweiligen Abteilungen bearbeitet wird. Dazu Kundenakten, Partnerakten und Lieferantenakten, Rechnungen, Angebote, Auftragsbestätigungen und die Zeiterfassung. Insgesamt rund 400.000 Entitäten.
Diese Struktur ist seit 2012 gewachsen. In dieser Zeit sind unheimlich viele Automatismen rund um smart organisation entstanden. Genau das macht eine solche Migration schwierig. Nicht die Datenmenge. Die Datenmenge ist ein Skript. Schwierig ist alles, was über Jahre an diesen Daten gebaut wurde und im Tagesgeschäft stillschweigend funktioniert.
Die Herausforderung lautete deshalb: sämtlichen Code auf die neue NORA | 360° Welt umbauen. Tausende Dateien, verteilt auf 18 Projekte und Plugins. Dazu die Schnittstelle zu unserem ERP odoo, über die Vertriebs- und Rechnungsdaten laufen.
Und der Punkt, der am Ende über Erfolg oder Misserfolg entscheidet: jeder Mitarbeitende musste mitgenommen werden, um nach der Umstellung direkt weiterarbeiten zu können. Eine technisch perfekte Migration, nach der niemand sein System bedienen kann, ist keine erfolgreiche Migration.
Wie sind wir bei der Migration konkret vorgegangen?
Wir haben in acht Schritten gearbeitet. Jeder Schritt hatte eine Aufgabe, und kein Schritt wurde übersprungen.
- Klon des Produktivsystems erstellen. Wir haben eine vollständige Kopie unseres Produktivsystems aufgesetzt. Alles Folgende geschah auf dieser Kopie, nie am laufenden Betrieb.
- Migrationsscript entwickeln. Auf dem Klon entstand das Script, das alle alten smart organisation Objekte in ihre NORA | 360° Äquivalente überführt.
- Umliegende Projekte anpassen und testen. Ebenfalls auf dem Klon haben wir sämtliche Anpassungen an all den umliegenden Projekten und Prozessen durchgeführt und getestet.
- Erster Migrationslauf. Wir haben einen ersten vollständigen Lauf gemacht. Die dabei entstandenen Probleme haben wir aufgenommen und den Code entsprechend angepasst.
- Zweiter Lauf und Generalprobe. Insgesamt haben wir zwei vollständige Migrationsläufe durchgeführt und am Ende noch eine Generalprobe.
- Schulung drei Wochen vor Go-live. Die agorum® Academy hat sämtliche Kollegen intern auf der Klon-Umgebung geschult. Dort konnten sie bereits umfangreich mit ihren realen Daten testen und ausprobieren, wie die neue Umgebung in der Bedienung reagiert.
- Stichtag, ein Freitag. Um 18 Uhr haben wir die Migration begonnen und das Wochenende begleitet. Am Sonntagnachmittag war die Migration fertig, danach liefen die letzten Tests. Sonntagabend um 21 Uhr wurde das System für alle User freigeschaltet, es konnte produktiv gearbeitet werden.
- Woche danach freigehalten. Ich hatte mir die Woche nach dem Go-live bewusst ohne Termine geplant, um für Probleme parat zu stehen. Das Erstaunliche: es gab kaum Probleme, es lief ziemlich reibungslos.
Warum lief die Umstellung so reibungslos?
Vier Gründe, und alle vier sind übertragbar.
1. Extrem gute Vorbereitung auf den Stichtag. Der Stichtag war kein Ereignis, auf das wir gehofft haben. Er war der letzte von mehreren identischen Durchläufen. Wer eine Migration dreimal geprobt hat, kennt am vierten Mal die Reihenfolge, die Dauer und die Stellen, an denen es klemmt.
2. Jeder Kollege wurde mitgenommen und geschult. Drei Wochen vor dem Go-live war die neue Umgebung mit echten Daten verfügbar. Nicht als Präsentation, sondern zum Anfassen. Das nimmt die Unsicherheit aus dem Montag danach.
3. Migration und Umstellung dreimal geprobt. Zwei vollständige Migrationsläufe plus Generalprobe. Jeder Lauf produzierte Probleme, jedes Problem führte zu einer Codeanpassung. Beim dritten Mal war die Liste leer.
4. Umsetzung mit ALBERT | AI. Die gesamte Umstellung des Codes und auch die Migration selbst haben wir mit Hilfe von ALBERT | AI umgesetzt. Tausende Dateien in 18 Projekten von einer Objektwelt in eine andere zu überführen ist Arbeit, bei der Konsistenz mehr zählt als Kreativität. Zusätzlich wurden hunderte automatisierte Tests entwickelt, um wirklich jedes erdenkliche Detail abzudecken.
Der letzte Punkt verdient eine Einordnung. Automatisierte Tests sind bei einer Migration dieser Größe kein Qualitätsbonus. Sie sind das einzige Mittel, um nach einer Codeänderung in Projekt 7 zu wissen, ob Projekt 12 noch funktioniert. Ohne diese Tests hätte jeder Migrationslauf manuell nachgeprüft werden müssen. Das wäre in der verfügbaren Zeit nicht möglich gewesen.
Was hat sich für die Abteilungen nach der Migration verändert?
Zwei Wochen nach der Migration blieb alles weiterhin ruhig. Jede Abteilung arbeitet einfach weiter an den Prozessen, wie seither auch. Das ist der wichtigste Satz dieses Beitrags, denn er beschreibt das eigentliche Ziel einer Systemmigration im Produktivbetrieb.
Gleichzeitig arbeiten nun alle bei agorum® mit dem neuen NORA | 360°. Der Unterschied liegt im Überblick. Wo vorher Informationen zu einem Vorgang zusammengesucht werden mussten, sind Zusammenhänge jetzt sichtbar. Kunde, Projekt, Ticket, Vertrag, Zeiterfassung und Kommunikation liegen im Kontext.
Der zweite Unterschied ist die KI-Unterstützung. Durch ALBERT | AI und das NORA | 360° AI Plugin werden die Kollegen im Rahmen aller Unternehmensprozesse von der KI unterstützt. Nicht in einem separaten Werkzeug, sondern dort, wo die Arbeit stattfindet, und im Rechtekontext des jeweiligen Users.
Wer sich fragt, was das für die eigene Organisation bedeutet: Der Gewinn liegt nicht in einer einzelnen Funktion. Er liegt darin, dass die strukturierte Datenbasis und die KI auf derselben Grundlage arbeiten. Genau deshalb war der Umbau des Codes auf die NORA | 360° Objektwelt der eigentliche Kern dieses Projekts.
Welche Rolle spielte ALBERT | AI bei der Codeumstellung?
Die gesamte Umstellung des Codes und die Migration selbst haben wir mit Hilfe von ALBERT | AI umgesetzt. Das war keine Demonstration, sondern eine Notwendigkeit.
Die Aufgabe bestand darin, tausende Dateien in 18 Projekten von einer Objektwelt in eine andere zu überführen. Solche Arbeit ist wiederholend, aber nicht schematisch. Jede Datei hat ihren eigenen Kontext, und ein Fehler in einer Datei fällt oft erst drei Projekte später auf.
Dazu kamen hunderte automatisierte Tests, die entwickelt wurden, um wirklich jedes erdenkliche Detail abzudecken. Diese Tests sind der Grund, warum wir nach jeder Codeänderung wussten, wo wir stehen. Sie haben aus einem unübersichtlichen Umbau ein prüfbares Vorhaben gemacht.
Für Entscheider ist daran ein Punkt relevant, der über dieses Projekt hinausgeht. Eine Migration dieser Größe wird nicht durch mehr Personen schneller, sondern durch Konsistenz und Prüfbarkeit. Genau dort liegt der wirtschaftliche Hebel von KI-Unterstützung in der Entwicklung. Nicht im Schreiben einzelner Zeilen, sondern im gleichmäßigen Durchziehen einer Änderung über tausende Dateien und im Absichern des Ergebnisses.
Welche Lehren lassen sich auf andere Migrationsprojekte übertragen?
Wir haben diese Migration an uns selbst durchgeführt, mit unserem eigenen laufenden Geschäft als Einsatz. Diese sieben Punkte würden wir in jedem vergleichbaren Projekt wieder so machen.
- Auf einem vollständigen Klon des Produktivsystems entwickeln, nicht auf einem Testsystem mit Beispieldaten.
- Die Migration mehrfach vollständig durchspielen, bis ein Lauf keine neuen Probleme mehr produziert.
- Automatisierte Tests aufbauen, bevor der Umbau beginnt, nicht danach.
- Mitarbeitende vor dem Go-live mit ihren realen Daten in der neuen Umgebung arbeiten lassen.
- Das Migrationsfenster auf ein Wochenende legen und die Dauer aus den Probeläufen ableiten, nicht schätzen.
- Die Woche nach dem Go-live bewusst von Terminen freihalten, auch wenn sie ruhig bleibt.
- Schnittstellen zu Drittsystemen wie dem ERP von Anfang an als eigenen Prüfbereich behandeln.
Was diese Punkte gemeinsam haben: Sie verlagern Aufwand von der Zeit nach dem Stichtag in die Zeit davor. Das ist der ganze Trick. Eine Systemmigration im Produktivbetrieb wird nicht dadurch sicher, dass man am Stichtag besonders sorgfältig arbeitet. Sie wird dadurch sicher, dass am Stichtag nichts mehr Neues passiert.
Über den Autor
Oliver Schulze ist Mitgründer und Geschäftsführer der agorum® Software GmbH sowie Kernentwickler von agorum core. Er verantwortet die technische Entwicklung der Plattform seit der Gründung 1998 und hat die Migration des agorum®-Produktivbetriebs von agorum core smart organisation auf NORA | 360° selbst begleitet, inklusive der Woche nach dem Go-live.
Mehr zu seinem Werdegang und zur Entstehung von agorum core: Unsere Mission.
Zuletzt aktualisiert: 6. August 2026.
agorum® Beratung Du planst eine Systemmigration im Produktivbetrieb?
Unsere Experten zeigen dir in einer kostenlosen Online-Demo, wie NORA | 360° Informationen und Prozesse in agorum core pro vernetzt, wie ALBERT | AI im Rechtekontext deiner Mitarbeitenden arbeitet und wie eine Umstellung im laufenden Betrieb geplant wird. Mit deinen Daten. In deiner Infrastruktur.
Jetzt unverbindlich beraten lassenagorum® FAQ Systemmigration im Produktivbetrieb
-
Wie lange hat die Migration von smart organisation auf NORA | 360° gedauert?
Die Vorbereitung brauchte mehrere Monate. Darin enthalten sind die Entwicklung des Migrationsscripts, hunderte Anpassungen an 18 Projekten, der Umbau der odoo-Schnittstelle, hunderte automatisierte Tests, zwei vollständige Migrationsläufe und eine Generalprobe. Das eigentliche Migrationsfenster lief von Freitag 18 Uhr bis Sonntagabend 21 Uhr.
-
Wie viele Daten wurden migriert?
Rund 400.000 Entitäten. Dazu gehören Projekte, Aufgaben, Vorgänge, Kundenakten, Partnerakten, Lieferantenakten, Rechnungen, Angebote, Auftragsbestätigungen und Zeiterfassungsdaten. Der Datenbestand ist seit 2012 gewachsen.
-
Warum waren mehrere Migrationsläufe nötig?
Jeder Lauf hat Probleme sichtbar gemacht, die vorher nicht bekannt waren. Diese Probleme haben wir genommen und den Code angepasst. Insgesamt haben wir zwei vollständige Läufe und am Ende eine Generalprobe durchgeführt. Am Stichtag war der Ablauf dadurch bekannt, inklusive der zu erwartenden Dauer.
-
Wie wurden die Mitarbeitenden auf die Umstellung vorbereitet?
Drei Wochen vor dem Go-live hat die agorum® Academy sämtliche Kollegen intern auf der Klon-Umgebung geschult. Dort konnten sie umfangreich mit ihren realen Daten testen und ausprobieren, wie die neue Umgebung in der Bedienung reagiert. Das war der Grund, warum am Montag nach der Umstellung direkt weitergearbeitet werden konnte.
-
Welche Rolle hatte ALBERT | AI bei der Migration?
Die gesamte Umstellung des Codes und die Migration selbst wurden mit Hilfe von ALBERT | AI umgesetzt. Es ging um tausende Dateien in 18 Projekten, die von der smart organisation Objektwelt in die NORA | 360° Objektwelt überführt werden mussten. Zusätzlich wurden hunderte automatisierte Tests entwickelt, um jedes erdenkliche Detail abzudecken.
-
Gab es nach dem Go-live Betriebsstörungen?
Es gab kaum Probleme, der Betrieb lief ziemlich reibungslos. Die Woche nach dem Go-live war bewusst von Terminen freigehalten, um für Störungen parat zu stehen. Zwei Wochen nach der Migration blieb es weiterhin ruhig, jede Abteilung arbeitet an ihren Prozessen weiter wie vorher.
-
Was hat sich für die Anwender durch NORA | 360° verändert?
Alle bei agorum® arbeiten jetzt mit NORA | 360° und haben einen wesentlich besseren Überblick, weil Zusammenhänge zwischen Kunde, Projekt, Vorgang, Vertrag und Kommunikation im Kontext sichtbar sind. Zusätzlich werden die Kollegen durch ALBERT | AI und das NORA | 360° AI Plugin im Rahmen aller Unternehmensprozesse von der KI unterstützt.
-
Was ist der wichtigste Faktor für eine Migration ohne Betriebsunterbrechung?
Der Aufwand muss vor den Stichtag verlagert werden. Konkret heißt das: auf einem vollständigen Klon des Produktivsystems entwickeln, die Migration mehrfach komplett durchspielen, automatisierte Tests aufbauen und die Mitarbeitenden vorher mit realen Daten in der neuen Umgebung arbeiten lassen. Am Stichtag selbst sollte nichts Neues mehr passieren.
