MariaForge field guide
Before you move a single table.
A practical starting checklist for source inventory, business intent and acceptance criteria.
Read the guideResources
A little clarity.
A better next decision.
Practical planning guides, useful tools and clearly attributed MariaDB documentation. Built for the questions that come before a migration.
6 resources
MariaForge field guide
A rehearsal is more than a dry run.
Think through cutover, validation, rollback and the ownership of every decision.
Read the guideInteractive planning tool
Explore the migration economics.
Model the current platform, target operations and one-time investment using your own inputs.
Open the cost modelInteractive planning tool
Build your migration brief.
Turn a few workload choices into a downloadable discovery conversation starter.
Build your briefOfficial MariaDB resource
Oracle mode: know the boundaries.
MariaDB’s official reference for the supported Oracle SQL and PL/SQL compatibility subset.
Read the documentationOfficial MariaDB resource
The Oracle migration journey.
An official MariaDB perspective on assessment, conversion and compatibility considerations.
Read the MariaDB articleNo resources match your search. Try another keyword or choose “All resources”.
External resources are published by MariaDB and are not MariaForge case studies or endorsements. Verify current product behavior against the target release.
MARIAFORGE FIELD GUIDE / 01
Before you move a single table.
A useful assessment starts with the decisions you need to make, not the tools you want to use.
1. Define the business reason.
Record the drivers: cost, flexibility, platform strategy or operational improvement. Separate desired outcomes from constraints such as contract dates and change windows.
2. Inventory the actual estate.
Include versions, schemas, data volumes, growth, application owners, connectors, jobs, reports and integrations. Identify Oracle-specific packages, routines and operational dependencies.
3. Choose representative tests.
Do not select only the easiest queries. Include business-critical transactions, complex routines, realistic data, peak concurrency and recovery scenarios.
4. Agree what “correct” means.
Define data and business reconciliation, application acceptance, performance objectives, downtime allowances and recovery requirements with the responsible owners.
5. Produce a decision, not just a report.
The result should distinguish suitable candidates, remediation work, unresolved risks and workloads that may be better retained on the source platform.
Turn these questions into a briefMARIAFORGE FIELD GUIDE / 02
A rehearsal is more than a dry run.
The purpose is to expose uncertainty while you still have room to change the plan.
Time the whole sequence.
Include change freezes, final synchronization, data checks, application restart, business validation and the decision to reopen service—not only the data transfer.
Prove the exit path.
Define the latest safe rollback point, how writes are handled, who can authorize reversal and how the restored service is verified. A written rollback plan alone is not evidence.
Make the decision observable.
Keep a runbook with owners, dependencies, checkpoints and escalation contacts. Record actual timings and exceptions, and revisit assumptions before production approval.
These guides are planning aids. They do not replace workload-specific engineering, security or compliance review.
Explore the complete migration approachLET’S BUILD WHAT’S NEXT
Your next chapter starts
with a better question.
What would your data platform look like if you could build it around your business, not your constraints?