Migration ELOoffice nach NGX

ELO Office wurde ja mit 31.12.2026 abgekündigt. Die letzte Version war hier ELOoffice 11 mit einer Initialversion aus dem Jahr 2017 und einem letzten Update aus dem Jahr 2020 (Stand per 25.01.2026). Im Grunde kann zwar eine alte Version durchaus noch länger laufen, aber es stellen sich hier natürlich mehrere Fragen:

• Wie lange wird man eine 11er Version noch aktivieren können, da hier ja ein Aktivierungsprozess dahinter steht
• Funktioniert die OCR mit Windows 11 oder später noch (teilweise kommen hier ja Fehlermeldungen)
• Soll man mit dem System weitermachen, es migrieren, oder es trennen? (bspw. bis 2027 ELOoffice, danach ein anderes System)

Im Zuge einer internen Analyse und einer Kundenanfrage rund um Alternativen zu ELOOffice und ELOprofessional sowie enterprise haben wir hier einmal gesagt, geben wir hier Paperless NGX einmal eine Chance. Die Haptik ist bei einem Kaltstart hier ja wenig aufzwingend, man bekommt hier ja ein absolut nacktes System ohne Demodaten. Man muss hier schon einmal überlegen, wie man hier die speziellen Themen auch mit Paperless gebacken bekommt. Allzu schwierig ist es hier allerdings nicht, einmal eine grundlegende Übersicht über das System zu bekommen. 3-4 Tage ist man hier aber auch einmal gut und gerne auf dem Weg, vor allem wenn man hier einmal beginnt mit der API zu spielen und die Grenzen des Systems einmal auszuloten.

Bei Migrationen gibt es hier allen voran immer die Notwendigkeit die Migrationsschritte zu planen. Allzu schwer ist das im Normalfall nicht. Aufwändig ist es aber meist immer. Bei ELOoffice stellen sich hier folgende Themen:

• Dokumentenmasken: die Migration geht hier einmal von einer Übernahme von Dokumentmasken nach dem Prinzip Verwendung hin zu einem Dokument aus. Sprich es wird die Objekte-Tabelle einmal gruppiert (objmask-Feld), die IDs der verwendenten Masken entnommen. Danach werden Dokumententypen in Paperless gleichnamig angelegt.
• Felder: hier ist das selbe Prinzip wie bei den Dokumentenmasken, verwendete Felder werden hier in Paperless als Custom-Felder angelegt. Eine Binding Feld zu Dokumenttyp gibt es hier allerdings nicht. Somit geht diese Information damit verloren. Gleichwertig können aber in NGX auch Automatisierungen angelegt werden, die hier die Custom-Felder wieder „zuordnen“ sobald ein neues Dokument von dem Typ im Storage auftaucht. Bei den Feldern muss man hier dazu sagen, dass hier gleichnamige Felder mit abweichendem Feldtyp zu einem Fehler führen.
• Benutzer: noch keine Behandlung vorgesehen, ließe sich aber ebenfalls mit einer Überführung in den Paperless NGX Benutzerstamm abdecken.

Da Paperless NGX ja keine Ordner unterstützt ist es hier notwendig Dokumente zu übernehmen. Ordnerstrukturen lassen sich ggf. wieder in Custom-Feldern abbilden (Haupt/Nebenkategorie, Ebene1/2/3 etc.). Dabei ist zu erwähnen:

• verschlüsselte Dokumente müssen vorher über den ELO-Export exportiert werden
  • die Export-Pfade müssen der Routine bekannt gegeben werden
• die Datenverzeichnisse müssen für die Migrationsroutine zugänglich sein
  • diese müssen der Export-Routine ebenfalls zur Verfügung gestellt werden
• NGX unterstützt per Default nur Dateitypen für die auch ein Consumer/Parser hinterlegt ist
• NGX macht mit aktiviertem Tika eine Prüfung des Contents. Sprich liegt hinter einem PDF Dokument bspw. eine Text-Datei, dann wird diese wahrscheinlich auch als Text-Datei gewertet und als solche geparst und abgelegt. Liegt hier ein JSON-String dahinter, dann wertet Tika dies als JSON-Datei, dafür gibt es keinen Handler und es führt nach erfolgreichem Upload in NGX zu einem Verarbeitungsfehler.

Wie verfährt die Migrationsroutine mit den Dokumenten: rein generell werden hier die Dokumentenpfade einmal auf Dateien durchforstet, die nicht mit der Endung ESW (Verschlagwortungsdatei) enden. Hier wird jede Dokumentdatei auf einen Hex-Wert überprüft und es wird versucht diesen Hex-Wert in eine Zahl zu bringen (ELO-Dokumenten-ID).