DNA Solutions plant und führt Oracle-Migrationen für europäische Unternehmen durch: Versionsupgrades, selektive Wechsel zu PostgreSQL und Cloud-Datenbanken sowie Lizenzumfänge, zugeschnitten auf das, was Sie tatsächlich nutzen. Unsere Gründer haben Oracle-Umgebungen jahrelang produktiv administriert, bevor sie begannen, sie zu migrieren. Jeder Plan, den wir vorschlagen, hat den Kontakt mit einer echten Systemlandschaft also bereits überstanden.
Versionen fallen aus dem Premier Support, während der lizenzierte Umfang weiter wächst: Optionen, die niemand abgeschaltet hat, Prozessorzahlen für Lastspitzen, die es nicht mehr gibt, Umgebungen, geklont für Projekte, die vor Jahren endeten. DNA Solutions behandelt beide Probleme in einem Plan: Wir aktualisieren die Workloads, die auf Oracle bleiben sollten, verlagern die übrigen auf neue Plattformen und verkleinern den lizenzierten Perimeter auf das, was tatsächlich gebraucht wird.

Wir entwickeln Technologie, die auf Ihr Ergebnis einzahlt. Europäische Unternehmen vertrauen uns extreme Datenvolumen und kritische Finanzpipelines an.
Kundenergebnisse ansehenDurch die Optimierung von Softwarelizenzkosten für mehrere europäische Organisationen haben wir über 1 Mio. € an jährlichen Einsparungen erzielt.
Wir haben eine von Deloitte auditierte Billing-Plattform gebaut und betreiben sie: 300 Mio. € an auditierten Transaktionen jeden Monat.
Ein Senior-Team aus Ingenieuren und Consultants in ganz Europa.
T-Systems, Satellic, Europäische Kommission: Unsere längsten Engagements halten, weil wir liefern.

Jedes Engagement deckt vier Disziplinen ab. Lässt man eine davon aus, wird aus einer Oracle-Migration ein Ausfall mit Projektnummer.
Landschaften, die noch 11g, 12c oder 18c fahren, tragen Extended-Support-Gebühren und einen wachsenden Sicherheitsrückstand. Wir bringen sie auf ein unterstütztes Release wie 19c, mit vorab definierten Patch-Baselines und getestetem Optimizer-Verhalten vor der Umschaltung, denn ein Upgrade kann Ausführungspläne verändern, selbst wenn das Schema identisch bleibt. Upgrades werden auf einer geklonten Umgebung gegen Ihren echten Workload geprobt und dann über Standby-Datenbanken stufenweise ausgerollt, sodass das Produktionssystem weiter Traffic bedient, während sich das neue Release beweist.
Bevor etwas umzieht, inventarisieren wir, wofür Sie tatsächlich zahlen: Optionen und Management Packs gegen die reale Nutzung, Prozessorzahlen gegen die aktuelle Hardware, Named-User-Metriken gegen aktive Konten und Nicht-Produktionsumgebungen, die still als lizenzierte Deployments zählen. Das Ergebnis ist eine Karte des Perimeters, den Sie aufgeben können, ohne ein einziges Feature zu verlieren, von dem Ihre Anwendungen abhängen. Diese Disziplin hat für mehrere europäische Organisationen jährliche Softwarelizenzkosten von bis zu 1 Mio. € abgebaut, und das Audit bemisst Ihre eigene Zahl vor jeder Festlegung.
Verlässt ein Workload Oracle in Richtung PostgreSQL oder einer verwalteten Cloud-Datenbank, hält logische Replikation Quelle und Ziel synchron, während beide live bleiben. Anwendungen werden einzeln umgehängt, erst nachdem der Abgleich zwischen beiden Datenbanken sauber zurückkommt. Bis zu diesem Moment bleibt das Oracle-System die Quelle der Wahrheit. Ein Rollback ist damit eine Konfigurationsänderung statt einer Recovery-Operation: Die ursprüngliche Datenbank hat nie aufgehört zu laufen. Für transaktionskritische Landschaften gibt es eine geprobte Rollback-Prozedur für jeden Cutover-Schritt.
Eine migrierte Datenbank muss sich wie das Original verhalten, und diese Aussage braucht Belege. Wir vergleichen Schemata Objekt für Objekt, gleichen Zeilenzahlen und Prüfsummen über den gesamten Datenbestand ab und erfassen Abfragepläne und Latenz-Baselines auf der Quelle, damit derselbe Workload gegen das Ziel wiederholt werden kann. Stored Procedures und PL/SQL-Logik, die für die neue Engine umgeschrieben wurden, werden gegen aufgezeichnete Produktionseingaben getestet. Die Abnahme erfolgt, wenn das Ziel die Baseline erreicht oder übertrifft, mit den Messwerten auf dem Tisch.
Für eine Oracle-Landschaft gibt es nicht die eine richtige Antwort. Wir bewerten Workload für Workload und kombinieren dann drei Routen zu einem Programm, mit Kontinuität als fester Rahmenbedingung.
Migration planenFür Workloads, die auf Oracle gehören, bringen wir alternde Releases auf eine unterstützte Baseline, geprobt auf geklonten Umgebungen und gestuft über Standby-Datenbanken, damit die Produktion weiter Traffic bedient.
Workloads ohne harte Oracle-Abhängigkeiten ziehen unter kontinuierlicher Replikation auf PostgreSQL oder Cloud-Datenbanken um, mit Abgleich als Nachweis für jeden einzelnen, bevor seine Anwendungen umgehängt werden.
Ein Audit von Optionen, Packs, Prozessorzahlen und Umgebungen identifiziert den lizenzierten Umfang, den Sie aufgeben können, ob ein Workload umzieht oder nicht. Einsparungen werden vor jeder Entscheidung an Ihren Verträgen bemessen.
Eine Billing-Datenbank und eine Mauterfassungs-Datenbank laufen beide auf Oracle, und doch sehen ihre Migrationskalender völlig verschieden aus. Regulierung, Audit-Zyklen und Verkehrsmuster bestimmen die Sequenz.
Rating- und Billing-Datenbanken tragen Revenue-Assurance-Pflichten. Cutover werden deshalb um Abrechnungszyklen herum sequenziert, und jedes migrierte Segment stimmt auf den Cent ab, bevor es endgültig umzieht.
Mauterfassungs-Datenbanken sammeln rund um die Uhr. Die Replikation läuft deshalb kontinuierlich, Umschaltungen landen in verkehrsarmen Fenstern, und die Oracle-Quelle bleibt als Fallback, bis sich das Ziel bewiesen hat.
Zwei Engagements, in denen alternde Oracle- und Legacy-Infrastruktur ersetzt oder neu gebaut wurde, während die Plattform für ihre Nutzer live blieb.

Ein europäischer Transportbetreiber fuhr Analysen, die über fragmentierte Datenbanken Tage dauerten, mit hartem Oracle-Lock-in. Wir haben einen cloudnativen Data Lake auf AWS entworfen.
Abfragelatenz: Tage → Stunden
Das größte audiovisuelle Portal der Kommission lief auf zehn Jahre altem AngularJS und bediente 34–36 Mio. Aufrufe pro Jahr. Wir haben es über ein sechsjähriges Engagement mit einem Echtzeit-, Mobile-First-Stack neu gebaut.
34–36 Mio. Aufrufe/JahrSenior-Entscheider zu den Infrastruktur-, Maut- und Finanzplattformen, die wir modernisiert haben.
"DNA unterstützt uns dabei, digitale Systeme in großem Maßstab bereitzustellen, damit wir unsere Kunden digital bedienen können. Das Team reagiert schnell auf Anfragen und bringt zugleich proaktiv eigene Ideen und Vorschläge ein."
"Die Qualität der Menschen, mit denen ich zusammengearbeitet habe, und die Ernsthaftigkeit im Projektmanagement haben herausgestochen. DNA hat ein Backend und eine App für ein Autobahn-Mautsystem entwickelt, und die menschliche Seite des Unternehmens ist wirklich bemerkenswert."
"Ich habe den partnerschaftlichen Umgang und den Einsatz für eine zuverlässige Lösung im vernünftigen Budgetrahmen geschätzt. Das schrittweise Vorgehen mit einer Demo vor dem Deployment hat den entscheidenden Unterschied gemacht."
Was DBA-Manager und Infrastrukturverantwortliche uns fragen, bevor sie sich auf einen Plan festlegen.
Nein, und die meisten unserer Kunden sollten das auch nicht. Wir bewerten die Landschaft Workload für Workload. Systeme mit tiefer PL/SQL-Logik, RAC-Abhängigkeiten oder Herstellersoftware, die nur gegen Oracle zertifiziert ist, bleiben in der Regel: aktualisiert auf ein unterstütztes Release und bereinigt um ungenutzte lizenzierte Optionen. Workloads, die die Datenbank als einfachen relationalen Speicher nutzen, sind die natürlichen Kandidaten für PostgreSQL oder eine verwaltete Cloud-Engine, wo die Lizenzkosten vollständig entfallen. Das Ergebnis unseres Assessments ist eine Empfehlung pro Workload mit beiden durchgerechneten Szenarien: was es kostet, ihn sauber auf Oracle zu halten, und was es kostet, ihn zu verlagern. Manchmal schlägt ein Versionsupgrade plus Lizenzbereinigung eine Migration auf jeder Achse, und wenn das so ist, sagen wir es.
Durch kontinuierliche logische Replikation zwischen der Oracle-Quelle und der Zieldatenbank. Beide Systeme bleiben während des gesamten Übergangs live: Die Quelle bedient weiter die Produktion, während jede Änderung, die sie verarbeitet, nahezu in Echtzeit auf das Ziel repliziert wird. Anwendungen werden in kleinen Gruppen umgehängt, jede erst, nachdem der automatisierte Abgleich bestätigt, dass beide Datenbanken über die Daten dieser Anwendung übereinstimmen. Weil das Oracle-System bis zur finalen Umschaltung die Quelle der Wahrheit bleibt, heißt ein Rollback, einen Connection String auf eine Datenbank zurückzudrehen, die nie aufgehört hat zu laufen. Für transaktionskritische Landschaften proben wir diesen Rollback vor jedem Cutover-Schritt, damit die Prozedur unter Druck eine ist, die das Team bereits ausgeführt hat.
Das Audit gleicht Ihre Oracle-Verträge mit dem ab, was tatsächlich läuft: aktivierte Optionen und Management Packs gegen die reale Feature-Nutzung, Prozessorlizenzen gegen aktuelle Core-Zahlen und Virtualisierung, Named-User-Metriken gegen aktive Konten und die Test- oder Standby-Umgebungen, die öfter als lizenzierte Deployments zählen, als Teams erwarten. Daraus identifizieren wir Umfang, den Sie ohne Funktionsverlust aufgeben können, Workloads, deren Wechsel zu PostgreSQL ihre Lizenzkosten beendet, und Konsolidierungen, die den Fußabdruck des Verbleibenden verkleinern. Diese Arbeit hat für mehrere europäische Organisationen jährliche Softwarelizenzkosten von bis zu 1 Mio. € abgebaut. Ihre eigene Zahl hängt vollständig von Ihren Verträgen und Ihrer Nutzung ab. Wir bemessen sie deshalb im Audit und legen sie vor, bevor Sie sich auf irgendetwas festlegen.
Mit Messwerten, erfasst auf beiden Seiten. Die Schemakonvertierung wird Objekt für Objekt verifiziert, dann werden die Daten selbst über Zeilenzahlen und Prüfsummen über den gesamten Bestand abgeglichen statt über eine Stichprobe. Bei der Performance erfassen wir Abfragepläne, Latenzverteilungen und Durchsatz auf der Oracle-Quelle unter realer Produktionslast, spielen denselben Workload dann gegen das Ziel ab und vergleichen. Stored Procedures und PL/SQL-Logik, die für die neue Engine umgeschrieben wurden, werden gegen aufgezeichnete Produktionseingaben und erwartete Ausgaben getestet. Die Abnahme wird vor Beginn der Migration numerisch definiert: Das Ziel muss die Baseline der Quelle auf den vereinbarten Metriken erreichen oder übertreffen. Regressiert eine Abfrage, wird sie getunt, oder der Cutover für diesen Workload wartet.
Das hängt von der Route ab. Ein Versionsupgrade auf einer einzelnen Landschaft läuft typischerweise wenige Wochen von der Probe bis zur Produktionsumschaltung. Ein selektives Replatforming zu PostgreSQL ist ein Programm über mehrere Monate, weil jeder Workload Replikation, Abgleich und Performance-Validierung durchläuft, bevor seine Anwendungen umgehängt werden, und die risikoärmsten Workloads zuerst umziehen, um Vertrauen auf echten Daten aufzubauen. Ein vollständiger Ausstieg aus einer großen Landschaft erstreckt sich über gestufte Schritte über ein Jahr oder mehr. Was wir nie vorschlagen: diese Sequenz für ein transaktionskritisches System in einen einzigen Wochenend-Cutover zu pressen. Der Kalender kauft Ihnen Umkehrbarkeit, und Umkehrbarkeit ist es, was eine Migration davon abhält, zu einem Incident zu werden.