Migrate Oracle to SQL Server

Beta — live-tested path

Migrating from Oracle (Oracle Database, the long-standing enterprise standard) to SQL Server (Microsoft's enterprise relational database) means every table, column type, key, index and row has to survive two engines' different opinions about data. DBShifts converts the schema with deterministic rules, transfers data in parallel batches, and validates the result with per-table row counts and type-aware checksums.

Start Oracle → SQL Server Migration

Free tier · no credit card

Oracle vs SQL Server

Oracle

Oracle Database, the long-standing enterprise standard.

SQL Server

Microsoft's enterprise relational database.

How the migration works

Connect

Point DBShifts at your source and target. Credentials stay encrypted; SSH tunnels supported for private databases.

Analyze

Automatic schema introspection produces a migration plan: what converts automatically, what migrates with warnings, what needs human review.

Migrate

Schema is created on the target, data transfers in parallel batches with constraints deferred, indexes rebuilt after load.

Validate

Per-table row counts, type-aware checksums on both sides, FK integrity — plus a fidelity report listing anything lossy.

Oracle to SQL Server data type mapping

Pulled directly from DBShifts's own conversion rules — not a general reference table, this is what actually runs.

Oracle	SQL Server	Note
NUMBER(10)	BIGINT	Oracle NUMBER carries precision and scale; the width chosen here follows the declared precision.
NUMBER(19)	DECIMAL(19,0)
NUMBER(10,2)	DECIMAL(10,2)
VARCHAR2(255)	NVARCHAR(255)
NVARCHAR2(255)	NVARCHAR(255)
CHAR(10)	NCHAR(10)
CLOB	NVARCHAR(MAX)	Unbounded character data.
NCLOB	NVARCHAR(MAX)
BLOB	VARBINARY(MAX)
DATE	DATETIME2
TIMESTAMP	DATETIME2	Timezone behaviour differs per engine — a naive target shifts the instant rather than failing.
BINARY_FLOAT	FLOAT
BINARY_DOUBLE	FLOAT(53)
RAW	VARBINARY(MAX)	Oracle RAW is binary, not text — a text target would corrupt it.
LONG	NVARCHAR(MAX)

Example: Oracle to SQL Server schema conversion

Oracle

CREATE TABLE orders (
  id            NUMBER(10) GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  customer_id   NUMBER(10) NOT NULL,
  total         NUMBER(10,2) NOT NULL,
  notes         CLOB,
  reference     VARCHAR2(255),
  placed_at     TIMESTAMP NOT NULL
);

SQL Server

IF OBJECT_ID(N'orders', 'U') IS NULL
CREATE TABLE [orders] (
    [id] BIGINT NOT NULL,
    [customer_id] BIGINT NOT NULL,
    [total] DECIMAL(10,2) NOT NULL,
    [notes] NVARCHAR(MAX),
    [reference] NVARCHAR(255),
    [placed_at] DATETIME2 NOT NULL,
    CONSTRAINT [PK_orders] PRIMARY KEY ([id])
);

Sequences transfer directly here, unlike most Oracle routes

SQL Server has had real sequence objects since 2012, so Oracle's CREATE SEQUENCE has a genuine counterpart rather than needing to be rewritten as an identity column. Cache sizes, increments and cycling all carry over. This makes SQL Server an easier target than MySQL for schemas that lean on sequences shared between tables, which is a common Oracle pattern and has no clean MySQL equivalent.

What does not carry is the trigger-plus-sequence idiom used for auto-numbering before Oracle 12c. Those become either a DEFAULT NEXT VALUE FOR on the column or an IDENTITY, and the two behave differently on explicit inserts, so pick based on whether the application ever supplies the key itself.

Packages are the work; the tables are not

Estimate this migration by counting PL/SQL, not tables. SQL Server has no package construct — no grouping of related procedures behind a shared specification, and crucially no package-level variables persisting for the session. A package that caches lookup values in a package variable between calls has no direct translation, and the usual rewrite is a temporary table or a session context, both of which have different lifetime and concurrency behaviour.

CONNECT BY has no T-SQL equivalent and becomes a recursive common table expression. The rewrite is mechanical for simple hierarchies and genuinely difficult where CONNECT BY NOCYCLE, LEVEL and SYS_CONNECT_BY_PATH are combined. Budget for it explicitly rather than treating it as a syntax substitution.

NUMBER without precision has no exact target

Oracle's NUMBER can be declared with no precision at all, in which case it stores up to 38 significant digits with whatever scale each value happens to carry. SQL Server has no equivalent — DECIMAL requires a fixed precision and scale at definition time.

So an unconstrained NUMBER column has to be given bounds that did not previously exist, and whatever is chosen is a guess unless the real values are inspected first. Query MAX, MIN and the maximum observed scale on the Oracle side before converting. Choosing DECIMAL(38,10) as a blanket default wastes storage on every row and still truncates a value that happened to carry eleven decimal places.

Oracle → SQL Server conversion notes

Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.

NUMBER columns are fetched as exact decimals (38 digits), not lossy floats.
Identifier case differences (Oracle uppercases unquoted names) are reconciled automatically during transfer.
Empty string = NULL semantics are accounted for in validation so comparisons stay honest.
IDENTITY_INSERT is managed per table so explicit IDs from the source load correctly, then counters are reseeded with DBCC CHECKIDENT.
Binary columns always carry an explicit length — bare VARBINARY (which means 1 byte) never reaches the target.
TRUNCATE falls back to DELETE on FK-referenced tables automatically.

Frequently asked questions

Is Oracle to SQL Server migration production-ready in DBShifts?

Oracle to SQL Server is a live-verified beta pair: it passed the same certification suite as every other pair — a real migration with edge-case data validated by row counts and checksums — and ships with a post-migration fidelity report you can audit before cutover.

How does DBShifts verify the Oracle to SQL Server migration was correct?

Three layers: per-table row counts on both sides, an order-independent type-aware checksum of row data (canonicalized so engine representation differences don't false-alarm), and FK integrity checks on the target. Rows that fail to insert are quarantined with the exact error — never silently dropped — and can be fixed and retried from the UI.

What happens to Oracle types that SQL Server doesn't have?

They convert by deterministic rules with a recorded decision: a native equivalent where one exists, a portable fallback (TEXT/JSON/DECIMAL) where one doesn't. Every lossy conversion appears in the migration plan before you run and in the fidelity report after. You can override any mapping per column.

Can I keep Oracle and SQL Server in sync after the initial migration?

Yes. DBShifts supports incremental sync (UPSERT-based delta transfers on a sync key) and, for supported sources, real-time change data capture so the target stays current until you cut over.

Do I need to write any SQL or scripts for Oracle to SQL Server?

No. Connect both databases, review the generated migration plan (what's automatic, what migrates with warnings, what needs manual review — typically triggers and stored procedures), and run. Procedural code is transpiled best-effort and queued for human review rather than auto-applied.

What's the hardest part of moving Oracle to SQL Server?

Type-system mismatches that fail silently rather than loudly — Oracle's edge-case types (3 engine-specific rules apply) converting into SQL Server's nearest equivalent. DBShifts's deterministic mapping records every downgrade in the fidelity report, so a value that clips, rounds, or widens is visible before cutover, not after.

Which Oracle data types change when moving to SQL Server?

4 of the mapped types convert to something that cannot represent exactly the same range or constraint. The clearest cases are NUMBER(10) to BIGINT, CLOB to NVARCHAR(MAX), TIMESTAMP to DATETIME2. The full table above lists every mapping the converter performs, and analysis flags each one on your actual schema before any data moves.

Go deeper

How We Live-Certified All 49 Migration Paths

The certification harness behind this page's claims.

Why Row Counts Aren't Enough

How type-aware checksum validation works.

Reference

Compared with other tools

Errors you may hit

Related migration paths

MySQLSQL Server MariaDBSQL Server PostgreSQLSQL Server SQL ServerSQL Server OracleMySQL OracleMariaDB

Ready to move Oracle to SQL Server?

Set up in under two minutes. Validation and rollback included.

Start Free Migration