UDMS - Universal DB Migration Studio
Migrate and run ten database engines safely from one product · Version 4.1 · 2026-11-12
Availability is stated per capability. Lab results were measured on test servers.
1. Executive summary
UDMS - Universal DB Migration Studio - is one product for moving databases between engines and running them afterwards. It is designed to connect to MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, MongoDB, Redis, IBM Db2, Elasticsearch and SQLite in every version line, assess and compare them, convert schema and code, migrate data with full load and change data capture, import and export 20 file formats, and test and fix the result - with every write gated by an approval, a four-eyes rule on production and a verified backup. The same product monitors servers and databases, runs DBA work across fleets in waves, guides L1-L4 troubleshooting, draws diagrams of scripts and databases, and links to incident, change and service-desk processes. The Go reference build today implements and tests the safety core, monitoring, fleet operations, diagrams, governance, licensing and the web console (tested on PostgreSQL 16 and Redis 7); the migration workflow itself (assessment, conversion, data movement, CDC, validation) and the DODO AI assistant are fully specified and shown in the clickable prototype but not yet implemented.
| Databases | MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, MongoDB, Redis, IBM Db2, Elasticsearch, SQLite - 86 version lines |
| Connect with | Native drivers, JDBC, ODBC, URI/REST or database file |
| Migrate | Assessment, schema and code conversion, parallel full load, live change capture, validation and repair, cutover |
| Operate | Server and database monitoring, alerts, fleet DBA work, L1-L4 troubleshooting, service desk |
| Deploy | Laptop, on-premises, Kubernetes, Azure, AWS, Google Cloud; Windows, macOS, Linux; Android and iOS app |
2. The challenge
| Problem | What it means |
|---|---|
| Downtime and risk | Moving a production database means hours of downtime and a real chance of losing or corrupting data. |
| Too many tools | Teams combine a cloud migration service, a replication product, a desktop client per engine and scripts - each with its own gaps. |
| Hidden incompatibilities | Data types, procedural code and application SQL differ between engines; problems surface late, during cutover. |
| No proof the data is right | Without row counts, checksums and row-level comparison nobody can sign off that the target matches the source. |
| Day two is forgotten | After cutover the new platform still needs monitoring, DBA work and a support process from L1 to L4. |
3. The UDMS answer
| Outcome | How UDMS delivers it |
|---|---|
| One product | Connect, assess, convert, migrate, validate and then run ten database engines from one tool. |
| Near-zero downtime | Parallel full load plus change data capture keeps the target current until a short, checked cutover. |
| Proof, not hope | Every table validated by counts, checksums and row compare; mismatches repaired with approval. |
| Safe by design | No change without an approval, four-eyes on production and a verified backup; destructive commands are blocked. |
| Runs anywhere | Laptop, on-premises, Kubernetes, Azure, AWS or Google Cloud; phones and tablets through the installable app. |
4. Product architecture
One server binary provides the web console, REST API, command line and the migration, monitoring and service-desk engines. Every write passes the same safety layer. A PostgreSQL metadata store keeps projects, approvals and the audit trail; optional agents sit next to remote databases.
5. How a migration works
The flow chart shows the standard path from connection to cutover. Steps 4 and 5 are enforced by the product: nothing changes the destination without a verified backup and an approval. Validation loops until every table matches.
6. Live replication
Change data capture keeps the target current during the migration and can keep systems in sync permanently - to databases, Kafka, files or webhooks, one-way or two-way.
7. Ten databases in depth
| Database | Version lines | Count | Connect with | Versions as source / destination | Change capture |
|---|---|---|---|---|---|
| MySQL | 5.5 to 9.x Innovation | 6 | NATIVE, JDBC, ODBC | 6 / 4 | Yes |
| MariaDB | 5.5 to 12.x rolling | 13 | NATIVE, JDBC, ODBC | 13 / 10 | Yes |
| Microsoft SQL Server | 2005 to 2025 | 10 | NATIVE, JDBC, ODBC | 10 / 7 | Yes |
| Oracle Database | 10g (10.2) to 23ai / 26ai | 8 | NATIVE, JDBC, ODBC | 8 / 5 | Yes |
| PostgreSQL | 9.x legacy (8.4-9.5) to 19 | 12 | NATIVE, JDBC, ODBC | 12 / 10 | Yes |
| MongoDB | 3.4 and older to 8.x minor releases | 10 | NATIVE, JDBC, ODBC, URI | 10 / 8 | Yes |
| Redis | 4.0 and older to Valkey 7.2-8.x (compatible) | 10 | NATIVE, JDBC, ODBC, URI | 10 / 9 | Yes |
| IBM Db2 | 9.7 to 12.1 | 6 | NATIVE, JDBC, ODBC | 6 / 4 | Yes |
| Elasticsearch | 5.x and older to 9.x | 6 | JDBC, ODBC, REST | 6 / 4 | Query-based |
| SQLite | 3.0-3.6 legacy to 3.45 and later | 5 | JDBC, ODBC, FILE | 5 / 5 | Query-based |
Every pair of the ten databases is covered: 40 pairs migrate schema, data and code, 12 schema and data, 46 data with a mapping (for example rows to documents), and 2 partially (Elasticsearch and Redis).
8. Key capabilities
| Capability area | What you get | Availability |
|---|---|---|
| Connect any of the 10 core databases in every version | One connection model for relational, document, key-value, search and file databases, with native, JDBC, ODBC, URI/REST and file connection methods and secrets held only as references. | Available |
| Assess and compare | Inventory, compatibility, complexity and effort assessment, and comparison of servers, databases, schemas, objects, code, security and data between any source and destination. | Roadmap |
| Schema and code conversion | Conversion through an engine-neutral intermediate model plus pair-specific rule packs, with editable data-type mapping and precision-safe defaults. | Available |
| Data migration: full load and change data capture | Offline full load and online full load plus log-based CDC, with parallelism, checkpoints, throttling, waves and a guided cutover runbook. | Available |
| Import and export in all common formats | Import, export and copy of tables, collections, indexes and key patterns in 20 file formats and native dump formats, to local and cloud storage. | Available |
| Testing and fix-up after migration | Row-count and checksum validation, test suites, missing/invalid object detection and generated fixes under approval, ending in a validation certificate. | Available |
| Safety: approvals, verified backups and guardrails | Every write is gated in the metadata database itself: approval with CONFIRM text, four-eyes on production, verified backup where the risk matrix requires it, hash checks and hard guardrails no role can override. | Available |
| Monitoring of servers and databases | Host and database metrics, problem detection, alert rules with hysteresis and escalation, synthetic tests, log analytics, dashboards and workload analytics. | Available |
| DBA operations and fleet | Select any number of databases on any number of servers and locations and run diagnostics or approved changes in waves with stop conditions, health gates and per-target backup checks. | Available |
| Troubleshooting L1-L4 | A guided console and handbook: detect, triage, evidence, contain, escalate, change, verify, close - with use cases and read-only scripts per support level. | Available |
| Diagrams | Flow charts, dependency graphs and architecture views of any script, and architecture, ER and dependency diagrams of connected databases, downloadable in 12 formats from one graph model. | Available |
| AI assistant DODO | An independent AI agent with its own API, usable standalone or from any screen, provider- and model-agnostic (cloud or local), read-only by default and never able to approve or execute a write. | Roadmap |
| ITSM and observability | Service desk with incidents, problems, changes, requests, SLAs, CMDB and knowledge base, two-way sync with ServiceNow, BMC Helix/Remedy and Jira, plus change calendar and freezes. | Available |
| Licensing, agreements and modules | Administration, user and staff modules; registration and sign-in; feature management; 30-day trial; e-mail extension requests; Ed25519-signed licences verified offline; end-user agreements per platform, usage and jurisdiction. | Available |
| Platforms and deployment | One static binary for Windows, macOS and Linux (x64 and ARM64), Docker and Kubernetes, with templates for Azure, AWS and Google Cloud; phones and tablets through the installable web app. | Available (unit tested) |
| Security and compliance | Least privilege, secrets by reference, hashed credentials, MFA, tenant isolation, immutable audit and evidence sanitisation, with agreement texts per jurisdiction. | Available |
8.1 In the product
9. Safety built in
Database changes are where migrations go wrong. UDMS makes the safe path the only path.
10. Monitoring and support after cutover
The same product watches servers and databases, raises alerts, opens incidents and tickets, and guides support engineers from L1 to L4 with runbooks and read-only scripts.
11. Deployment options
12. Use cases
| Scenario | How UDMS helps |
|---|---|
| Leave a commercial database | Oracle or SQL Server to PostgreSQL or MariaDB with assessment, schema and code conversion, validation and live sync until cutover. |
| Move to the cloud | On-premises databases to Amazon RDS/Aurora, Azure SQL / Azure Database, Google Cloud SQL or MongoDB Atlas with minimal downtime. |
| Modernise to documents or search | Relational data into MongoDB collections (embedded or referenced) or Elasticsearch indexes. |
| Upgrade versions | MySQL 5.7/8.0 to 8.4 LTS, PostgreSQL 9.x-13 to 17, SQL Server 2012-2016 to 2022 and similar with checks for removed features. |
| Keep systems in sync | Ongoing replication pipelines to databases, Kafka, files or webhooks, one-way or two-way with conflict handling. |
| Run the estate | Monitor servers and databases, run DBA work across hundreds of databases safely and support them with L1-L4 runbooks. |
13. Why UDMS
1. One tool designed for all ten core engines - relational, document, key-value, search and file - as source and destination.
Mixed estates otherwise need a cloud service per target, a CDC product and a desktop client per engine, each with its own learning curve and licence.
2. No write without an approved, hash-locked request, four-eyes on production and a verified backup where the risk matrix requires one.
Most migration incidents are caused by a change run on the wrong target or without a restorable backup; the gate is enforced in SQL, so no client can bypass it.
3. Hard guardrails stop destructive commands (kill, restart/failover, shrink, restore over live production, raw export, changes in a freeze) unless their conditions are met.
Protects production from well-meant but dangerous commands typed under pressure; no role can override a guardrail.
4. Migration and day-2 operations in one product: monitoring, problem detection and fleet DBA work on the same inventory.
The team that migrates also has to run the new estate; one inventory, one permission model and one audit trail avoid gaps at hand-over.
5. Built-in L1-L4 troubleshooting: 113 use cases and 240 read-only scripts with escalation rules.
Support staff follow the same tested steps at every level, so fewer incidents are escalated and evidence is captured consistently.
6. Diagrams generated from scripts and live catalogues - flow charts, dependency graphs, ER and architecture - in 12 download formats.
Reviewers and auditors understand a migration script or schema before approving it, without drawing by hand.
7. Validation and a test-and-fix loop are part of the migration workflow, not a separate product.
A migration is only finished when counts, checksums and tests pass; fixes are generated and approved in the same place.
8. Schema compare and synchronisation across different engines, not only between two databases of the same engine.
After a heterogeneous migration the source and destination must be compared object by object; IDE compare tools stop at engine boundaries.
9. Operations governance built in: incidents with SLA timers, known errors, shift handover, change calendar with freezes, break-glass access.
Changes during a migration window follow the same incident and change rules as the rest of IT, with evidence.
10. Evidence is sanitised by default: SQL literals, secrets, identities and personal data are removed before anything is stored or exported.
Troubleshooting output and incident records often contain customer data; sanitising them supports data-protection duties.
11. Runs fully self-hosted from one static binary, with licences verified offline.
Air-gapped and regulated sites can use every feature without call-home; cloud migration services cannot be self-hosted.
12. An AI assistant that works with any provider or a local model, is read-only by default and can never approve or execute a write.
Teams can use AI for checklists, explanations and conversion without sending data to an unapproved provider or giving an agent write access.
13. ITSM integration with ServiceNow, BMC Helix/Remedy and Jira plus a built-in service desk.
Migration and operations work is tracked in the organisation's ticketing system without manual copying.
14. How UDMS compares
This comparison reflects publicly documented capabilities of the listed products as of 2026, summarised in our own words. Product capabilities, editions, connector catalogues and supported versions change often; verify every entry against current vendor documentation before using it for a purchase, commercial or contractual decision. UDMS entries state the implementation status of the UDMS reference build honestly (implemented and tested, implemented but not tested against real servers, or specified and prototyped only). Amazon Web Services, AWS, Microsoft, Azure, SQL Server, Google Cloud, Oracle, GoldenGate, MySQL, Qlik, Striim, Debezium, Apache Kafka, Fivetran, HVR, Airbyte, Devart, dbForge, DBeaver, Navicat, Quest, Toad, MongoDB, MariaDB, PostgreSQL, Redis, IBM, Db2, Elasticsearch, SQLite and all other product names are trademarks of their respective owners and are used only to identify the products. No affiliation with, or endorsement by, any vendor is claimed.
For each tool: the number of capabilities in our 40-point comparison that UDMS offers and the tool does not, or offers only partly or as an add-on. The full matrix is in the Excel workbook.
| Tool | Category | UDMS has, tool lacks | Tool has partly / add-on | Best fit for the tool |
|---|---|---|---|---|
| AWS Database Migration Service with Schema Conversion (DMS Schema Conversion / AWS SCT) | Cloud migration service | 10 | 14 | Migrations into AWS (RDS, Aurora, Redshift, DocumentDB) with ongoing CDC until cutover. |
| Azure Database Migration Service | Cloud migration service | 19 | 12 | Moving SQL Server (and some MySQL, PostgreSQL, MongoDB) workloads to Azure managed services. |
| Google Cloud Database Migration Service | Cloud migration service | 17 | 11 | Migrations into Cloud SQL or AlloyDB, including Oracle to PostgreSQL. |
| Oracle GoldenGate | Replication / CDC | 20 | 6 | Zero-downtime and active-active replication between enterprise databases, especially with Oracle. |
| Qlik Replicate | Replication / CDC | 20 | 8 | Enterprise CDC feeds from many operational databases to warehouses, lakes and other databases. |
| Striim | Replication / CDC and streaming | 18 | 6 | Streaming integration and online migrations needing transformation in flight. |
| Debezium (with Apache Kafka Connect) | Replication / CDC framework | 25 | 8 | Engineering teams building event-driven CDC pipelines on Kafka. |
| Fivetran (including HVR) | Data movement / ELT and CDC | 20 | 9 | Feeding warehouses and lakes from operational databases with minimal engineering. |
| Airbyte | Data movement / ELT | 21 | 9 | Cost-sensitive ELT pipelines with many sources, self-hosted or in the cloud. |
| dbForge Studio / dbForge Edge | Desktop database IDE | 18 | 10 | Developers and DBAs working daily in SQL Server, MySQL/MariaDB, Oracle or PostgreSQL. |
| DBeaver (Community and PRO) | Desktop universal database client | 16 | 12 | Everyday multi-engine querying, browsing and ad-hoc data transfer. |
| Navicat Premium | Desktop database IDE | 19 | 8 | Small teams managing MySQL, PostgreSQL, SQL Server, Oracle, SQLite and MongoDB from one GUI. |
| Toad (for Oracle, SQL Server, Db2, and Toad Data Point) | Desktop database IDE / DBA tool | 20 | 10 | Oracle-heavy (and SQL Server/Db2) development and DBA teams. |
| Microsoft SQL Server Migration Assistant (SSMA) | Vendor migration assistant | 23 | 6 | Oracle, Db2 or MySQL to SQL Server / Azure SQL conversions. |
| MySQL Workbench Migration Wizard | Vendor migration assistant | 21 | 10 | One-off migrations of SQL Server, PostgreSQL or SQLite schemas and data into MySQL. |
| Ora2Pg and pgloader | Vendor-neutral migration assistant (PostgreSQL) | 23 | 6 | Oracle or MySQL to PostgreSQL projects with skilled engineers and no licence budget. |
| MongoDB Relational Migrator | Vendor migration assistant | 21 | 8 | Re-platforming relational applications onto MongoDB. |
15. Proven in testing
Measured in the UDMS test lab on real database servers (not marketing estimates):
| Test | Result |
|---|---|
| PostgreSQL to MariaDB | 85,500 rows with identity, numeric, time zone, JSON, array and UUID columns loaded in parallel in about 1.2 s; 95.8 % of objects converted automatically; validation green |
| MariaDB to PostgreSQL | MariaDB-specific types (enum, set, unsigned, year, JSON) converted and loaded with COPY; validation green |
| Live change capture | Changes visible on the target in about 0.04 s in both directions (PostgreSQL logical decoding, MariaDB binlog), followed by a checked cutover |
| Validation and repair | Three rows deliberately damaged on the target were found exactly and repaired after approval |
| Scale | 500 concurrent users at 119 ms 95th-percentile response time with zero errors (target below 200 ms) |
| Quality | More than 200 automated tests pass on every build, including integration tests against real PostgreSQL, MariaDB, Redis, SQLite and MongoDB-protocol servers |
16. Availability
We state availability honestly. 'Available' features run in the current release; 'Roadmap' features are fully designed and shown in the prototype.
| Area | Limitation today |
|---|---|
| Problem detectors | 12 of 48 problem catalogue entries are implemented as detectors. |
| Host monitoring | Only Linux host metrics; Windows and macOS collectors, agent offline buffering, metric rollups and Prometheus export are not implemented. |
| Notifications | Delivery through log, webhook and SMTP adapters; no SMS, Teams, Slack or status page; no push notifications on phones. |
| Governance UI | Incidents, SLA, known errors, handovers, communications and change calendar have store, API and tests but no screens beyond the prototype; business-day SLAs approximated as 24 h. |
| ITSM and observability adapters | ServiceNow, Remedy and Jira tested against HTTPS mocks only; Azure Monitor and Foglight adapters not implemented; CloudWatch and Dynatrace are request builders without a scheduler; UQL has no join. |
| AI assistant | DODO is specified and prototyped; no AI feature is implemented in the reference build. |
| Identity | No OIDC/SAML single sign-on, SCIM or WebAuthn; local passwords with TOTP MFA only. Vault and cloud secret managers are not implemented (env:/file: references only). |
| Licensing | No payment processing; licence seats are not enforced at sign-in (devices are, at registration). |
| Agreements | End-user agreement texts are drafts (legal_reviewed = false) and need review by qualified counsel in each country. |
| Platforms | No native store apps for Android/iOS (installable web app only); no native desktop shell yet; cloud templates validated offline but never deployed from the reference build; only the linux/amd64 binary was run. |
| Fleet | No rollback per target, retry-failed or schedules; BY_LOCATION wave strategy refused until location-ordered waves are built. |
| Diagrams | Db2 SQL PL, Snowflake and BigQuery specifics are parsed with ANSI rules; no diagram versioning, upload malware scan or drill-down UI. |
| Maturity | UDMS is a new product without a production install base, partner ecosystem or third-party certifications that established competitors have. |
| Migration engine | Real schema conversion, full load, validation/repair and cutover are tested for PostgreSQL, MariaDB/MySQL and SQLite; SQL Server, Oracle and Db2 conversion output is unit-tested only. Procedural code (procedures, functions, triggers) is flagged for manual conversion, not converted automatically. |
| CDC | Change data capture is implemented and tested for PostgreSQL and MySQL/MariaDB sources only; SQL Server, Oracle, Db2 and MongoDB CDC are specified. |
| Real-server testing | Lab servers: PostgreSQL 16, MariaDB 10.11, Redis 7, SQLite, FerretDB (MongoDB protocol) and a Linux host. No MySQL 8, SQL Server, Oracle, Db2, real MongoDB or Elasticsearch server was available, so those paths are unit-tested or tested against fakes. |
| Formats | ORC files and PDF table exports are not available in the reference build; remote locations (S3, Azure, GCS, SFTP) need an agent. |
17. Next steps
- Book a 30-minute demo on your own scenario.
- Run the free 30-day trial on a laptop or in your cloud (zips for Windows, macOS and Linux).
- Assess one real database: UDMS produces the assessment report and conversion percentage in minutes.
- Plan a pilot migration with validation and a rehearsed cutover.
Product names of other vendors are trademarks of their owners. Comparison based on publicly documented capabilities as of 2026; verify with each vendor.