Heterogeneous migration
Schema, code and data converted from commercial databases to open source.
- Oracle → PostgreSQL
- Tibero → PostgreSQL
- SQL Server → PostgreSQL / MySQL
- Oracle → MySQL / MariaDB
Data Migration
Data migration you can verify
From Oracle, Tibero and SQL Server to PostgreSQL, MySQL and MariaDB; from on-premises to the cloud. A 7-phase methodology, consistency checks and rollback plans keep risk under control.
Scenarios
Migration scenarios
On-premises → cloud
Self-hosted databases moved to cloud VMs or managed databases.
- RDS · Aurora
- Azure flexible server
- Cloud SQL · AlloyDB
- NCP Cloud DB
Like-for-like & upgrades
Major-version upgrades and server moves within the same engine.
- PostgreSQL major upgrades
- MySQL 5.7 → 8.x
- MariaDB LTS moves
- InfluxDB version transitions
Consolidation & split
Several databases merged, or split by business domain.
- Schema consolidation
- Domain separation
- Read-only analytics replicas
- Archive separation
Methodology
A 7-phase methodology
Each phase has deliverables and a gate for moving on.
1. Assessment
Inventory objects, data volume, transaction patterns and dependent applications; estimate automatic-conversion coverage and manual effort.
2. Design
Target architecture, data-type mapping, character set, approach (bulk or CDC) and downtime target.
3. Conversion
Convert schema, PL/SQL, views, triggers and sequences; fix the scope of application SQL changes.
4. Migration
Initial load, then catch up with CDC; rehearsals measure actual durations.
5. Verification
Compare row counts, checksums, aggregates and business query results; run performance tests.
6. Cutover
Stop writes → final sync → verify → switch connections, with a Go/No-Go decision.
7. Stabilization
Close monitoring of performance and errors right after cutover, tuning, then handover to operations.
Migration flow
Migration flow
Oracle · Tiberosource
SQL Serversource
MySQL · PostgreSQLon-premises
Convert · load
Schema conversionora2pg · DMS SC · SCT · DMS conversion workspace
Initial loadpgloader · mydumper · DMS full load
Sync changes
CDC syncDebezium · DMS CDC · native replication
GoldenGatesource-side CDC if already licensed
Cutover
PostgreSQL · MySQL · MariaDBVM / on-premises
Managed DBRDS · Aurora · flexible server · Cloud SQL · AlloyDB · Cloud DB
Consistency checksPerformance testsRollback path kept
Tools
Migration tools
Tools are combined for the job; no single tool is assumed.
| Tool | Use | Notes |
|---|---|---|
| ora2pg | Oracle → PostgreSQL schema, code and data conversion | Open source · migration report for effort estimates |
| AWS DMS · DMS Schema Conversion · AWS SCT | Heterogeneous and homogeneous moves to AWS, full load + CDC | SCT is a desktop tool; DMS SC is managed |
| Azure Database Migration Service | MySQL → Azure Database for MySQL and similar | No Oracle → PostgreSQL — use ora2pg etc. |
| Migration service in Azure Database for PostgreSQL | PostgreSQL → Azure flexible server | Online/offline |
| Google Database Migration Service | Homogeneous MySQL/PostgreSQL; Oracle and SQL Server → Cloud SQL for PostgreSQL / AlloyDB | Conversion workspaces · CDC |
| NCP Database Migration Service | Moves into NAVER Cloud Cloud DB | Check supported paths in official docs |
| pgloader | Loading MySQL, SQL Server and others into PostgreSQL | Custom type-casting rules |
| mysqldump · mydumper/myloader | Logical backup and parallel load for MySQL/MariaDB | mydumper for large volumes |
| Debezium (CDC) | Change data capture → Kafka-based sync | Minimal downtime, parallel run |
| Oracle GoldenGate | Source-side CDC (where you already own it) | Based on your existing licenses |
Tibero is Oracle-compatible but is not an officially supported source for ora2pg. We confirm connectivity and conversion coverage with a PoC in your environment first, and track objects that do not convert automatically as a manual-conversion list.
Validation
Consistency verification
Not “we moved it” but “it is the same”.
- Row counts per table
- Chunked checksum / hash comparison
- Aggregates (sum, min, max)
- Key business query results
- Constraints, indexes and current sequence values
- Character-set conversion losses (e.g. KO16MSWIN949/EUC-KR → UTF-8)
- Date, time zone and numeric precision differences
- Oracle's empty-string-as-NULL behaviour
- LOB and binary data
- Response times against the performance baseline
Downtime & rollback
Minimal downtime and rollback plans
Minimizing downtime
- Initial load + CDC so only deltas remain at cutover
- Phased migration by business domain
- Cutover rehearsals to measure durations
- Read-only windows announced in advance
Rollback plan
- Source database preserved for an agreed period after cutover
- Reverse replication to keep the source in sync if needed
- Go/No-Go criteria and decision makers named in advance
- Point of no return documented
Deliverables
Deliverables
- Assessment report (effort and risks)
- Data-type and object mapping
- Conversion results and manual-work list
- Migration runbook (commands and timings)
- Consistency verification report
- Cutover and rollback plan
- Performance test results
- Operations handover documents
FAQ
Frequently asked questions
Can you migrate with zero downtime?
CDC usually shortens downtime substantially, but a brief write freeze for the final sync and connection switch is generally required. The target is fixed from rehearsal results.
We have a lot of PL/SQL. Is conversion feasible?
During assessment we use reports from ora2pg and similar tools to estimate automatic and manual scope, and base schedule and cost on that.
Do you support Tibero?
Tibero is Oracle-compatible but is not an officially supported source for ora2pg. We confirm connectivity and conversion coverage with a PoC in your environment first, and track objects that do not convert automatically as a manual-conversion list.
Can you run it after migration?
Yes, through Cloud MSP and open-source database support.
Shall we start by reviewing your cloud and databases as they are today?
Tell us your clouds, database versions, topology and concerns, and we will propose an assessment scope and approach.