Where the dependencies sit
PL/SQL packages, proprietary data types, database links and application-vendor support can create deeper dependency than the SQL tables.
Map the work before selecting software
Ask each team which functions are essential, which can change and which can be retired. Separate standard processes from custom logic, and document who owns each decision.
Data that needs a migration decision
Map schema, constraints, sequences, large objects, time zones and transaction history. Reconcile financial and operational reports.
Integrations to preserve
Inventory drivers, jobs, reporting tools, ETL and application SQL. Confirm target support with application owners.
Identity and access map
Translate database users, roles, service credentials and audit requirements without carrying excessive privileges forward.
Candidate components
| Component | Role | Licence |
|---|---|---|
| PostgreSQL | Databases | PostgreSQL License |
| MariaDB Server | Databases | GPL-2.0 |
Identity, backup, monitoring and integration design remain part of the architecture. Each component needs its own fit and edition review.
A phased migration path
Discover.
Inventory systems, contracts, data, permissions and business-critical workflows. Record owners and acceptance criteria.Pilot.
Convert one bounded application and replay representative transactions and reports, including concurrency and recovery failures.Rehearse.
Time exports and imports. Reconcile record counts, relationships, attachments and reports against the source.Coexist.
Define the source of truth, prevent duplicate writes and monitor the interfaces between old and new systems.Cut over.
Use an agreed change window, decision owner, communication plan and a clear rollback deadline.Operate.
Train users, document recovery and retain required history before retiring the source.
Risks and security considerations
Semantics, performance and support certification may prevent migration of some workloads. Keep those exceptions and contract assumptions visible.
Protect exports and temporary staging data, restrict migration accounts, use encrypted transport and remove temporary access after acceptance.
Rollback and acceptance
Keep a validated source backup and a record of post-cutover writes. Decide whether rollback restores the old system or replays changes, and rehearse that procedure. Business owners must sign off reconciled data and representative workflows before final retirement.
Implementation effort and ongoing care
The initial effort category is High. It is an editorial screening assessment, not a time or cost quotation. A pilot is required to estimate delivery. Plan for patches, monitoring, integration maintenance, backup restoration and user support.
Common questions
Can one application replace the entire platform?
Sometimes the core use case fits one application, but specialised workflows often require several components. Validate feature gaps before committing.
Can we keep parts of the existing system?
Yes. A hybrid or phased approach can reduce disruption when system boundaries and the source of truth are explicit.
Will open source cost less?
It depends on licensing, migration, infrastructure and operating costs. Compare the same planning period using realistic inputs.
Sources and verification
Policies and features can change. Verify the current terms and your installed edition before implementation.