The Digital Operational Resilience Act (DORA) is not a licensing discussion; it is an ICT risk and third‑party regime for the financial sector. Whether your database is proprietary or open source, you must prove you can manage and recover critical functions when suppliers, software, or infrastructure fail.
Migration requirements that map cleanly to DORA themes
- ICT risk management: inventory critical functions, dependencies, and data flows; open‑source moves should reduce unknowns (config as code, reproducible builds) or they add operational burden—either way, document it.
- Incident reporting and resilience testing: runbooks, playbooks, and tests must cover the new stack; “we compiled it ourselves” is not a substitute for exercised procedures.
- Third‑party concentration: replacing one hyperscaler with another in practice is still concentration; open source can diversify if you engineer portability—multiple regions, multiple support paths, exit clauses with critical vendors.
- Contractual and oversight discipline with ICT service providers remains; self‑hosting shifts responsibility to you—governance must tighten, not relax.
For AI and automation layers, treat orchestration, vector stores, and model endpoints as critical ICT services when they underpin customer channels or decisions. A migration should include resilience targets (RTO/RPO), backup validation, and privileged access reviews on those paths.
Have you linked your open‑source migration milestones to DORA artefacts—risk register updates, exit plans for critical vendors, and tested recovery for the new control plane?