Abhängigkeiten aufdecken
Wir werten Datenbankprotokolle aus und sehen so, welche Programme, Makros und Benutzer tatsächlich zugreifen, auch jene, von denen die IT nichts wusste.
Die eigentliche Datenübertragung ist oft der kleinste Teil. Aufwand steckt in Abhängigkeiten, Umstellung von Code und im Nachweis, dass alles vollständig angekommen ist.
Wir werten Datenbankprotokolle aus und sehen so, welche Programme, Makros und Benutzer tatsächlich zugreifen, auch jene, von denen die IT nichts wusste.
Reiner Umzug auf aktuelle Version, Wechsel der Datenbank oder gleichzeitige Ablöse der Anwendung. Wir zeigen Aufwand und Risiko jeder Variante.
Datentypen, Sequenzen, gespeicherte Prozeduren und Trigger werden übersetzt, etwa von PL/SQL nach PL/pgSQL, und mit Tests abgesichert.
Dubletten, verwaiste Datensätze und fehlerhafte Zeichensätze beseitigen wir vor der Migration, damit das neue System nicht mit den alten Problemen startet.
Die Hauptmenge wird vorab übertragen, am Umstellungstag nur noch die Änderungen seit dem letzten Abgleich. So wird aus Tagen oft eine Nacht.
Wichtige Abfragen und Berichte werden vor und nach der Migration gemessen. Wird etwas langsamer, optimieren wir Indizes oder Abfragen, bevor es im Alltag auffällt.
Für die Aufbewahrungspflicht nach BAO bleibt ein lesbarer Bestand erhalten, als schreibgeschützte Datenbank oder als Export in offene Formate.
Ohne Probeläufe keine Umstellung. Wie lange der Stillstand dauert, zeigen erst Messungen mit Ihrer echten Datenmenge.
Inventur von Datenbank, Code und Zugriffen, Wahl des Zielsystems und ein Plan mit Risiken und Kosten.
Schema- und Codekonvertierung, automatische Vergleiche der Datenbestände und Tests der wichtigsten Abläufe durch Ihre Fachabteilungen.
Mindestens zwei vollständige Durchläufe mit Zeitmessung, danach ein fixes Drehbuch für den Umstellungstag.
Umstellung im vereinbarten Fenster, Rückweg in Bereitschaft und einige Wochen verstärkte Betreuung.
Lassen Sie Ihre Fachabteilungen testen, nicht nur die IT. Technische Vergleiche zeigen, dass alle Datensätze angekommen sind. Ob die Monatsauswertung der Disposition noch dieselben Zahlen liefert, merkt nur die Disposition. Planen Sie für jede Abteilung eine kurze Checkliste und einige Stunden Testzeit vor dem Umstellungstermin ein.
Häufig, weil Lizenzkosten entfallen und PostgreSQL bei den meisten Unternehmensanwendungen gleichwertig ist. Nicht lohnend ist es, wenn eine Standardsoftware nur eine bestimmte Datenbank unterstützt. Das prüfen wir als Erstes.
Mit Delta-Abgleich reicht bei vielen Systemen eine Nacht oder ein Wochenende. Die genaue Dauer kennen wir nach dem zweiten Probelauf. Sie bekommen vorab einen Plan mit Uhrzeiten und Entscheidungspunkten.
Das alte System bleibt schreibgeschützt erreichbar, und ein Rückweg ist vorbereitet, solange er sinnvoll ist. Einzelne fehlende Daten lassen sich aus dem Altbestand nachziehen.
Nicht zwingend alles. Häufig ist es sinnvoll, nur die aktiven Jahre zu übernehmen und den Rest in einem Archiv zu belassen, das die Aufbewahrungspflicht erfüllt. Das hält das neue System schlank.
Wo Sie wollen, in Rechenzentren in Österreich oder der EU, etwa bei Exoscale, Anexia oder Hetzner, oder auf Ihrer eigenen Infrastruktur. Mit dem Anbieter schließen Sie einen Auftragsverarbeitungsvertrag.
Welches System oder welche Datenbank soll abgelöst werden, und wie lange darf der Betrieb stehen? Wir beginnen mit einer Analyse.
Ihre Anfrage ist eingegangen
Sie hören spätestens am nächsten Werktag von uns. Haben Sie einen Ausfall gemeldet, der Ihr Team gerade blockiert, kümmern wir uns zuerst darum.
Diese Stadt ist nicht in der Liste. Prüfen Sie die Schreibweise oder wählen Sie die nächstgelegene Landeshauptstadt: Da wir alles per Fernwartung erledigen, ist die Betreuung in jedem Bundesland gleich.