OceanBase Migration Services
Teams moving from MySQL, Oracle, or other relational databases to OceanBase.
Problems we address
- Schema and SQL dialect gaps discovered late in the project
- Cutover windows without rollback planning
- Data validation gaps between source and target
- Application connection routing not tested under failover
Scope
- Migration assessment and compatibility review
- OMS or equivalent CDC planning
- Cutover and rollback runbooks
- Post-cutover validation checklists
Activities
- Source workload profiling
- Schema conversion review (OMA or manual)
- Incremental sync and checksum planning
- Cutover rehearsal support
Deliverables
- Migration plan with phases and validation gates
- Cutover checklist aligned to your maintenance window
- Risk register for dialect and performance gaps
Customer prerequisites
- Source database access for assessment
- Target OceanBase cluster or cloud tenant
- Application owners for connection and SQL review
Engagement process
- Consultation and scope agreement
- Assessment and plan delivery
- Optional cutover-window support
Supported deployment models
- On-premises
- OceanBase Cloud
- Hybrid source-to-target topologies
Limitations
- Migration timelines depend on data volume, change rate, and application complexity.
- We do not guarantee zero-downtime without customer-specific testing.
Related technical material
FAQ
01 Do you use OceanBase Migration Service (OMS)?
OMS is the common path for incremental CDC from supported sources. We plan around OMS capabilities documented for your source and target versions.