How do I migrate data from Oracle to Snowflake?

Convert the schema first, then move the rows, then keep them in sync until you can retire the source. SnowConvert handles the DDL and PL/SQL for free. A log based connector handles the rows. The step most teams skip is checking the type mapping before the first load, because Snowflake publishes two mappings for this route and they disagree about the most common numeric column in an Oracle schema.

What is the best Oracle to Snowflake connector?

Snowflake Openflow is the first-party answer and it is the most likely to stay current. Price its prerequisites before you assume it is the cheap option: it reads through an Oracle XStream Outbound Server, Oracle licenses XStream through GoldenGate, and Enterprise Edition is a prerequisite. If your Oracle estate is Standard Edition, Snowflake states its connector does not support it.

How much does an Oracle to Snowflake migration cost?

Three bills, and the connector license is usually the smallest. You pay for Snowflake warehouse time across the backfill and every reload while the mapping is being corrected, for engineering time converting PL/SQL that no tool converts fully, and potentially for an Oracle entitlement the connector requires. Budget for at least three full reloads, because the first two will be wrong in ways row counts do not reveal.

Can Snowflake pull data from Oracle directly?

Not with a query. There is no Oracle database link you can point at Snowflake and no federated read. Something has to sit between them: Snowflake Openflow, a managed pipeline such as Fivetran or AWS DMS, GoldenGate writing into a stage, or a scheduled export to files that Snowflake loads with COPY INTO. Every option here is that middle piece.

Does Oracle to Snowflake migration need GoldenGate?

Not always, but read the licensing before deciding. Snowflake's own connector reads from an XStream Outbound Server, and Oracle documents that a GoldenGate license includes XStream with Enterprise Edition as a prerequisite. Query based and export based tools avoid XStream entirely at the cost of latency and load on the source. That trade is the real decision on this route.

How does Oracle to Snowflake data type mapping work?

Most types have an obvious target and a non obvious consequence. Oracle DATE has no fractional seconds and arrives with nine. Oracle scale runs from -84 to 127 and Snowflake stops at 37. Anything outside those bounds is stored as text with no error. The table further down gives every mapping and what each one costs you.

What are the main Oracle to Snowflake migration challenges?

PL/SQL is the big one, because packages, triggers and cursors have no direct Snowflake equivalent and conversion is never fully automatic. After that: tables with no primary key, which Snowflake's connector cannot replicate at all, the type edge cases where Snowflake's own two documents disagree, and constraints that Snowflake accepts and does not enforce.

Is there an Oracle to Snowflake converter?

Yes, and Snowflake gives it away. SnowConvert translates Oracle DDL, views, PL/SQL and SQL into Snowflake syntax and costs nothing to run. It converts code, not data, so you still need something to move rows. Treat its output as a first draft: several of its published Oracle type notes need the corrections in the table on this page.

How do I migrate Oracle EBS or Fusion to Snowflake?

Differently, and check the supported list first. Snowflake states its Oracle connector does not support Oracle SaaS offerings including Oracle Fusion and NetSuite, and does not support Oracle Autonomous Database. E-Business Suite running on a database you control is in scope, but the schema is enormous, so scope the extract to the modules you actually report on rather than the whole application.

Should I use AWS DMS or Fivetran for Oracle to Snowflake?

AWS DMS if the Oracle instance already lives in AWS and you are comfortable running and sizing a replication instance that bills by the hour whether or not data moves. Fivetran if you want the pipeline to be somebody else's problem and your volume is predictable, remembering that a migration backfill is the largest active-row month you will ever have.

Oracle to Snowflake Migration Tools, Connector

Which Oracle to Snowflake migration tool should you use?

Convert the schema with SnowConvert, which is Snowflake's own and free, then move the rows with a log based connector so the same mechanism gives you both the backfill and the ongoing sync. Which connector depends on one thing most comparisons never mention: Snowflake Openflow reads through an Oracle XStream Outbound Server, and Oracle documents that Enterprise Edition is "a prerequisite to license and use Oracle Active Data Guard or Oracle XStream". Snowflake also states its connector does not support Oracle Standard Edition. If you are on Standard Edition, or you do not hold a GoldenGate entitlement, look at AWS DMS, Fivetran or an export based load instead. Whichever you pick, override the type mapping before the first load, because Snowflake publishes two mappings for this route and they give an undeclared Oracle NUMBER two different scales.

One scoping note before anything else. Snowflake's connector supports Oracle 11g and later on premises, on Exadata, on OCI and on some AWS RDS configurations, and it explicitly does not support Oracle Autonomous Database or Oracle SaaS applications including Fusion and NetSuite. Check your source against that list before you shortlist anything. For the wider category see data migration tools, and for the continuous load rather than the one time move, Snowflake ETL tools.

Snowflake publishes two Oracle mappings and they disagree

The SnowConvert Oracle translation reference and the Openflow Connector for Oracle data mapping page both describe how an Oracle column becomes a Snowflake column. Both are published by Snowflake. They give different answers for NUMBER with no precision, for negative scale, for DATE, for intervals and for the LOB family, and only one of them lists BOOLEAN or JSON at all. We read both against the Oracle Database 23ai SQL Language Reference on 4 September 2026. The last column is what we would ship.

Column type	What Snowflake's docs say	What the primary source says	What we would ship
NUMBER, no precision	The Openflow connector maps an undefined-precision Oracle NUMBER to NUMBER(38, 19). SnowConvert maps the same column to NUMBER(38, 18), explaining that Snowflake "does not support this functionality".	Oracle states that omitting precision and scale "specifies the maximum range and precision for an Oracle number", which is 38 significant digits with scale from -84 to 127. Snowflake caps precision at 38 and scale at 37. Both Snowflake mappings therefore spend the whole 38 digit budget, and the scale figure alone decides how many digits are left for the integer part: 18 leaves 20 digits, 19 leaves 19. This is the most common numeric column in an Oracle schema.	Measure the real magnitude, then declare NUMBER(38,s) yourself
NUMBER, negative scale	SnowConvert turns NUMBER(5,-2) into NUMBER(5), stating "Snowflake does not allow negative scale, so it is being removed" and warning of functional inequivalence. Openflow says only that out of range precision or scale means "the value is stored as TEXT".	Oracle scale reaches -84, and a negative scale is a rounding rule rather than a formatting choice: NUMBER(5,-2) holds values rounded to the nearest hundred. Removing the scale keeps the digits and drops the rounding. Falling back to text keeps the value and destroys arithmetic. One source column, two different silent failures, depending which Snowflake document your vendor implemented.	Find them first, then decide each one by hand
DATE	The Openflow connector pins Oracle DATE to TIMESTAMP_NTZ. SnowConvert emits a bare TIMESTAMP.	Identical only while a parameter holds its default. Snowflake documents TIMESTAMP as "a user-specified alias associated with one of the TIMESTAMP_* variations", resolved by TIMESTAMP_TYPE_MAPPING, which defaults to TIMESTAMP_NTZ and is routinely set to TIMESTAMP_LTZ by teams that want local time rendering. Set it that way and a converted schema and a replicated schema disagree about the single most common temporal column in Oracle.	Set TIMESTAMP_TYPE_MAPPING at account level, declare TIMESTAMP_NTZ explicitly
INTERVAL types	SnowConvert maps both interval types to VARCHAR(20) and rewrites the value into a shorthand such as "1d, 2h, 3m, 4s". Openflow maps both to unbounded TEXT and leaves the value alone.	Snowflake has no interval column type, so text is the only honest target and both documents are right about that. They are not right about the same string. One format is capped at twenty characters and rewritten, the other is not, so a parser written against one silently returns nulls against the other, and a long duration overruns the cap.	NUMBER of seconds plus a unit column, and rewrite the arithmetic once
LONG, CLOB, BLOB	Openflow maps LONG, CLOB and NCLOB to TEXT with a 16 MB default, and BLOB and LONG RAW to BINARY with an 8 MB default. SnowConvert maps LONG to VARCHAR and notes it must be cast through TO_LOB().	Oracle allows 2 GB in a LONG column and far more in a LOB, and separately tells you "do not create tables with LONG columns" because they exist only for backward compatibility. Snowflake VARCHAR reaches 128 MB. The connector defaults are lower again and are raisable but not raised for you. Three ceilings on one column, and the rows that meet the lowest are your largest documents.	Measure MAX(DBMS_LOB.GETLENGTH(col)) and raise the limit before the load
Extended VARCHAR2 and RAW	SnowConvert marks VARCHAR2 and NVARCHAR2 above 4000 bytes and RAW above 2000 bytes as "Not supported in Snowflake", converts them as ordinary types, and states that MAX_STRING_SIZE is not recognized.	Oracle documents precisely those thresholds: VARCHAR2 and RAW reach 32767 bytes when MAX_STRING_SIZE is EXTENDED against 4000 and 2000 bytes when it is STANDARD. Snowflake TEXT holds far more than either, so the destination is never the constraint. The risk is that the converter has stopped reading the setting that says how wide the source column really is, which makes any generated length assertion unverified.	Read MAX_STRING_SIZE yourself and treat generated lengths as unchecked
BOOLEAN and JSON	The Openflow connector lists BOOLEAN mapping to BOOLEAN and JSON mapping to VARIANT. The SnowConvert built-in type table carries neither row.	A documentation lag rather than a genuine conflict, since Oracle JSON arrived in 21c and BOOLEAN in 23ai. It still costs you, because the connector states that "any Oracle data types not listed in this table are mapped to TEXT by default" and SnowConvert simply has no rule. Follow the older document on a 23ai source and a real boolean lands as a string.	Declare BOOLEAN and VARIANT explicitly; the newer document wins here
Everything unlisted	Openflow is explicit: "Any Oracle data types not listed in this table are mapped to TEXT by default." SnowConvert has no row and no rule.	On an Oracle schema of any age that catch-all does real work, because mature Oracle estates accumulate object types, VARRAYs, nested tables, SDO_GEOMETRY, ANYDATA and ROWID columns that no mapping table covers. Nothing fails. Each one arrives as a string, and the problem surfaces months later as a report that cannot aggregate a column everyone assumed was numeric.	Inventory every non-scalar type in ALL_TAB_COLUMNS during planning

None of this makes either document useless, and we would still start with both. It makes the point that a published mapping is a starting position rather than a fact, even when the vendor publishing it owns the destination. The first row is the one to act on today, because NUMBER with no declared precision is the most common numeric column in an Oracle schema and it is the one where the two documents differ. The statement level version, with a query that proves each risky row before you load it, is in Oracle to Snowflake data type mapping.

Oracle to Snowflake migration tools and connectors compared

Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. Oracle publishes no list price for GoldenGate and Snowflake publishes none for Openflow beyond the credit model, so this page says that instead of inventing one. Where a tool is wrong for a job, the last column says so.

Tool	Approach	Best for	Pricing model
Snowflake Openflow	First-party managed connector reading Oracle redo through an XStream Outbound Server	Teams already committed to Snowflake with Oracle Enterprise Edition in place	Snowflake credits, metered as warehouse and service time
SnowConvert AI	Schema, SQL and PL/SQL conversion, not a data mover	Translating DDL, views, packages and procedures before any rows move	Free to run
Oracle GoldenGate	Log based replication from Oracle into a stage Snowflake can load	Estates that already own GoldenGate and already run it in production	Oracle licensing, quoted
AWS DMS	Managed replication with Oracle CDC through LogMiner or Binary Reader	Oracle already inside AWS, on EC2 or a supported RDS configuration	Metered by replication instance hour plus storage
Fivetran	Fully managed ELT with schema drift handling	Teams who want zero pipeline maintenance and have predictable volume	Monthly active rows
Qlik Replicate	Log based CDC with a long history of Oracle sources specifically	Large regulated Oracle estates that want a specialist rather than a generalist	Quoted, enterprise agreement
Striim	Streaming CDC with in-flight transformation	Low latency requirements from Oracle without operating Kafka yourself	By capacity and connector
Airbyte	Open source connector framework, self-hosted or cloud	Engineering teams who prefer to own and patch the pipeline	Free self-hosted, capacity-based in cloud
Matillion	Load plus in-warehouse transformation	Teams who want the modelling layer and the pipeline from one vendor	Credit-based consumption
Informatica	Enterprise data integration with mature Oracle connectivity	Organizations that already run it and have the skills in house	Consumption units, quoted
Hevo Data	Managed no-code pipelines with in-flight transformation	Smaller teams wanting a managed pipeline without enterprise pricing	By events loaded per month
Adapters	Field-level mapping you set once, then scheduled incremental sync	Teams who want the mapping explicit and the bill flat	Flat $49 a month, not metered by rows

Snowflake Openflow

Snowflake

Where it loses: The connector is Snowflake's, the prerequisite is Oracle's. XStream is licensed through GoldenGate with Enterprise Edition as a prerequisite, and Snowflake states Oracle Standard Edition is not supported for licensing compliance reasons.

SnowConvert AI

Snowflake

Where it loses: It converts code and does not move a single row, and several of its published Oracle type notes need the corrections in the table above before you ship its output.

Oracle GoldenGate

Oracle

Where it loses: Excellent at the Oracle half and not a Snowflake product, so you still build and operate the delivery into Snowflake. Only obviously right if the license is already paid for.

AWS DMS

Amazon

Where it loses: The instance bills whether or not data is flowing, and its Oracle type conversion defaults are a third mapping to audit rather than a tie-breaker between the two Snowflake ones.

Fivetran

Where it loses: A migration backfill is the largest active-row month you will ever have, and every reload while you correct the mapping bills again at that scale.

Qlik Replicate

Qlik

Where it loses: Priced and sold as enterprise software, so it is the wrong shape for a single schema. No public price, which makes budgeting a conversation rather than a calculation.

Striim

Where it loses: You are buying a streaming platform. If the requirement is a nightly warehouse load, most of what you are paying for will never be switched on.

Airbyte

Where it loses: Self-hosting moves the cost from a license to your on-call rota, and Oracle CDC failure modes are among the least pleasant to diagnose at two in the morning.

Matillion

Where it loses: The transformation layer is the product. If you only need Oracle rows in Snowflake you are paying for a great deal you will not use.

Informatica

Where it loses: Capability is not the question and time to first value is. Wrong shape unless the platform and the people are already there.

Hevo Data

Hevo

Where it loses: Event metering behaves like row metering during a backfill, which is exactly the moment your volume spikes and your mapping is still wrong.

Adapters

Where it loses: We do not convert PL/SQL, we are not the right tool for a pure one-time bulk lift of a decade of history, and we do not do in-warehouse modelling.

Oracle to Snowflake data type mapping, and what each conversion costs you

The target column is what the two Snowflake documents produce between them. The last column is what that mapping does to your data, which is the part neither mapping table carries. Read it before the first load, not after the first reconciliation meeting.

Oracle type	Snowflake target	What it costs you
NUMBER, no precision	NUMBER(38,19) or NUMBER(38,18)	The row where Snowflake contradicts itself. Nineteen integer digits under one document, twenty under the other, and nothing tells you which side your data sits on.
NUMBER(p,s)	NUMBER(p,s)	Clean while scale is 37 or under. Oracle allows scale to 127, Snowflake stops at 37, and past that the connector stores the value as text.
NUMBER(p,-s)	NUMBER(p) or TEXT	A negative scale is a rounding rule. One tool removes it and keeps the digits, the other gives up and stores text. Neither preserves the meaning.
BINARY_FLOAT	FLOAT	Widens from 4 bytes to 8, since Snowflake stores all floating point as 64 bit. Harmless, except that sums stop matching a source that kept 4 byte arithmetic.
BINARY_DOUBLE, FLOAT	FLOAT	Clean. Snowflake still warns that floating point operations carry small rounding errors, so keep currency out of these columns.
DATE	TIMESTAMP_NTZ	Oracle DATE has no fractional seconds and no time zone. It arrives carrying nine fractional digits it never had, so equality comparisons behave differently.
TIMESTAMP(n)	TIMESTAMP_NTZ	Oracle defaults to 6 fractional digits and Snowflake to 9. Nothing is lost, but a column that looked precise to a microsecond now looks precise to a nanosecond.
TIMESTAMP WITH TIME ZONE	TIMESTAMP_TZ	A genuinely clean mapping that both Snowflake documents agree on. The offset is preserved, as it was in Oracle.
TIMESTAMP WITH LOCAL TIME ZONE	TIMESTAMP_LTZ	Also clean and also agreed. Values normalize to the session zone on both sides, so set the Snowflake TIMEZONE parameter deliberately.
INTERVAL YEAR TO MONTH	TEXT or VARCHAR(20)	Snowflake cannot define a column as INTERVAL. Every duration becomes a string, in one of two different formats, one of them capped at twenty characters.
INTERVAL DAY TO SECOND	TEXT or VARCHAR(20)	Same story, and every query that added an interval to a date or summed elapsed time needs rewriting against a number of seconds instead.
CHAR(n), NCHAR(n)	TEXT	Oracle pads fixed length values, Snowflake CHAR is only a synonym for VARCHAR. Padding survives in the data and stops being handled by the type.
VARCHAR2, NVARCHAR2	TEXT	Clean under 4000 bytes. Above that, SnowConvert marks the extended form unsupported and stops reading MAX_STRING_SIZE, so declared lengths are unverified.
CLOB, NCLOB	TEXT	The connector default accepts 16 MB against Oracle LOBs measured in gigabytes. Raisable, but not raised for you, and the affected rows are your largest documents.
BLOB, LONG RAW	BINARY	Default ceiling of 8 MB. Same problem, sharper, because binary payloads are usually bigger than text ones and nobody eyeballs them after a load.
LONG	TEXT	Oracle allows 2 GB here, Snowflake 128 MB, the connector 16 MB. Oracle also says do not use this type at all, so the migration is a good moment to retire it.
RAW(n)	BINARY	Clean. Extended RAW above 2000 bytes is treated as ordinary RAW, which is fine because Snowflake BINARY is wider than either.
JSON	VARIANT	The one place Snowflake is genuinely better. Access members with the colon operator rather than a dot, and rewrite the JSON_VALUE calls.
XMLTYPE	TEXT	Becomes a string. XPath expressions, XMLTABLE and every schema validation Oracle was doing for you stop existing.
BOOLEAN (23ai)	BOOLEAN	Clean, and only one of the two Snowflake documents mentions it. Read the other one and you get a string instead.
ROWID, UROWID	TEXT	Physical addresses that identify nothing in Snowflake. Drop these columns rather than carry them, and rebuild any logic that used them.
ANYDATA, object types, VARRAY	TEXT	SnowConvert states ANYDATA is not supported, and the connector maps anything unlisted to TEXT. Old Oracle schemas are full of these and nothing warns you.

The numeric rows are the ones worth arguing about internally. Oracle allows a scale of -84 to 127 and Snowflake allows 0 to 37, so the parts of that range Snowflake cannot express do not fail loudly, they arrive as text. For the statement level version of this table, with the query that proves each risky row before you load it, see Oracle to Snowflake data type mapping, and for the code side of the same project, converting Oracle PL/SQL.

Eight failures that report success

None of these raise an error. Every one produces a green pipeline, a matching row count and a problem you find weeks later. Five of them are documented by Snowflake itself, in the pages describing the connector you would be buying. The last one is the only entry here that can damage your Oracle production database rather than your warehouse.

Failure	What you see	What it actually costs
A numeric column that arrives as text	Precision or scale sits outside what Snowflake can represent, and the load succeeds.	The connector documents the behavior directly: when precision or scale exceeds Snowflake limitations "the value is stored as TEXT". Row counts reconcile perfectly. Every aggregate over that column now needs a cast, and it sorts as a string, so 100 comes before 20.
A type nobody mapped	An object type, VARRAY, SDO_GEOMETRY or ANYDATA column loads without complaint.	Snowflake states plainly that "any Oracle data types not listed in this table are mapped to TEXT by default". No warning is raised at any point. The failure surfaces months later, in a report nobody could aggregate, on a column everyone assumed was structured.
A table that was never replicated at all	The pipeline is green and that table simply is not in Snowflake.	Snowflake requires that each replicated table have "a primary key, a qualifying unique constraint, a qualifying unique index, or a user-declared logical key". Legacy audit, staging and history tables frequently have none, and they are often the largest tables in the schema.
A key change nobody noticed	Someone drops or alters a primary key or unique index on the source.	Snowflake states the connector "doesn't detect at runtime when you drop or modify the primary key, unique constraint, or unique index". The key gates whether replication may start and then stops being watched, so a routine DDL change quietly invalidates the merge logic.
A TRUNCATE that did not travel	Someone truncates a source table and the warehouse copy keeps every row.	Snowflake states that "the connector doesn't support the truncate table operation". The source is empty, the target is not, and the two only disagree on tables somebody truncates as routine housekeeping, which is exactly where nobody looks.
A partial LOB update that never arrived	An application updates part of a large object and the row looks synced.	Snowflake documents that updates modifying only part of a LOB value through certain DBMS_LOB procedures are not supported. The row version advances, the content does not, and byte-for-byte comparison is the only check that would have caught it.
Constraints accepted and ignored	Your primary keys and foreign keys are created in Snowflake without complaint.	Snowflake does not enforce PRIMARY KEY, UNIQUE or FOREIGN KEY on standard tables. Only NOT NULL and CHECK are always enforced. Coming from Oracle, which enforced all of it for twenty years, this is a larger change than it sounds.
An archive log that filled the disk	The pipeline is paused or lagging and nobody is watching the source.	The connector needs ARCHIVELOG mode and supplemental logging on all columns, so the source generates far more redo than before, and archived logs must be retained long enough for the consumer. This is the failure that damages your Oracle production database rather than your warehouse.

Six numbers that decide this migration

Every figure below was read from primary vendor documentation on 4 September 2026 and is sourced under the card. Where a vendor publishes no number, this page says so rather than inventing one.

38,19 vs 38,18

Two Snowflake documents, one Oracle NUMBER with no declared precision, two different target scales. Nineteen integer digits under one, twenty under the other.

Openflow Connector for Oracle data mapping and SnowConvert Oracle data types, read 4 September 2026

-84 to 127

The scale range Oracle NUMBER accepts. Snowflake allows 0 to 37, and out of range values are stored as TEXT rather than rejected.

Oracle Database 23ai SQL Language Reference and Snowflake numeric data types, read 4 September 2026

0

Fractional seconds and time zones in an Oracle DATE. Oracle states it "does not have fractional seconds or a time zone", yet it lands in a Snowflake type carrying nine fractional digits.

Oracle Database 23ai SQL Language Reference, read 4 September 2026

11g

The oldest Oracle version Snowflake's connector supports. It does not support Oracle Autonomous Database, Oracle SaaS such as Fusion and NetSuite, or Oracle Standard Edition.

About Openflow Connector for Oracle, read 4 September 2026

16 MB / 8 MB

Default connector ceilings for CLOB and for BLOB, against Oracle LOBs measured in gigabytes. Both are raisable and neither is raised for you.

Openflow Connector for Oracle data mapping, read 4 September 2026

Enterprise Edition

The Oracle edition required behind Snowflake's connector. It reads through XStream, and Oracle documents Enterprise Edition as "a prerequisite to license and use Oracle Active Data Guard or Oracle XStream".

Oracle GoldenGate Licensing Information, read 4 September 2026

How to migrate Oracle to Snowflake in six steps

01

Price the Oracle side before you pick a Snowflake tool

This is the step that reorders the shortlist. Snowflake's first-party connector reads from an XStream Outbound Server. Oracle's licensing document states that a GoldenGate license "also includes a license to Oracle Active Data Guard and Oracle XStream", with Enterprise Edition as a prerequisite, and Snowflake separately states that Oracle Standard Edition is not supported by its connector. If your estate is Standard Edition, the first-party option is out before you compare a single feature.
02

Inventory the types that actually differ

One query against ALL_TAB_COLUMNS, grouping every data type outside the ordinary scalar set. On most Oracle schemas that returns a handful of types across a few dozen columns out of several hundred, and those columns carry essentially the whole semantic risk of the project. Everything else is a plain table that every tool on the list converts correctly.
03

Find the tables that cannot be replicated

Snowflake requires a primary key, a qualifying unique constraint, a qualifying unique index or a declared logical key on every replicated table. Query ALL_TABLES against ALL_CONSTRAINTS and list the ones with none. In a mature Oracle estate this list is longer than anybody expects and it is dominated by big append-only audit and history tables. Each needs a declared logical key or a different loading strategy.
04

Convert the code with SnowConvert, then read what it produced

It is free, it is Snowflake's own, and it handles the bulk of DDL, views and PL/SQL. Treat the output as a first draft rather than a result. Its Oracle type notes need the corrections in the table above, and anything it flags as manual will genuinely be manual, because packages, autonomous transactions and cursor heavy procedures have no clean Snowflake equivalent.
05

Override the mapping before the first load, not after

Write the target DDL by hand for the columns your inventory flagged: an explicit scale for every undeclared NUMBER, a decision on every negative scale, TIMESTAMP_NTZ spelled out rather than left to the TIMESTAMP alias, a number of seconds instead of every interval, and raised size limits for any LOB that needs one. Let the tool generate the rest. This is a day of work that removes most of the reloads.
06

Reconcile on values, never on row counts

Per table, compare the row count, the SUM of every numeric column, MIN and MAX of every date, a count grouped by day, and a hash of the business keys. Row counts reconcile perfectly on a load that turned three numeric columns into text, gave every DATE nine fractional digits and skipped two tables entirely for want of a key.

Who moves Oracle into Snowflake, and why

Getting out from under Oracle licensing

The most common reason this gets funded, and the one with a number attached. Note the irony on this route: the first-party Snowflake connector needs an Oracle entitlement, so the cheapest path off Oracle is not always the Snowflake-branded one.

Reporting that has outgrown the OLTP database

Analysts running wide scans against a transactional Oracle instance, and an Oracle DBA who has been asking for it to stop for two years. Columnar storage solves this properly rather than by adding indexes.

Joining Oracle to SaaS data already in Snowflake

The warehouse already holds Salesforce, Stripe or NetSuite data, and the Oracle application is the last source that cannot be compared with the rest of the business.

Retiring Exadata at a hardware refresh

The refresh quote is the forcing event, and the migration business case gets written against it. Snowflake supports Exadata as a source, so the extract itself is not the hard part.

Consolidating several Oracle instances

Estates grown by acquisition often run four or five Oracle databases with overlapping schemas. Snowflake becomes the first place they can be queried together without a federated query layer.

Keeping both systems live indefinitely

The outcome nobody plans for and most Oracle shops reach, because the application is not going anywhere. The one time move quietly becomes an ongoing sync somebody has to operate for years.

Five jobs where you should not pick us

A comparison page that never says the competition wins is an advert. These are the cases where we are the wrong answer and something on the list above is the right one.

Converting PL/SQL packages, triggers and cursor heavy procedures. SnowConvert is built for it and free to run. We do not do it and would be worse at it.
A pure one time lift of twenty years of history with no ongoing sync. Export to Parquet and use COPY INTO. That is what it is for and it costs less than we do.
Air gapped environments with no outbound network. We are a hosted service. If nothing may leave your network, this is the wrong shape of product entirely.
Sub-second replication latency from Oracle across dozens of schemas. That is the streaming CDC market and the specialists there earn their license fee.
Teams who need heavy in-warehouse modelling as well as the pipeline. Land the data with us if you like, but the transformation layer belongs in dbt or Matillion.

Four questions to ask any vendor on this list

Which of the two Snowflake mappings do you follow?

A fair question with no comfortable answer, because Snowflake publishes two and they differ. Any vendor selling this route should know that and have chosen deliberately. Ask specifically what they do with an undeclared NUMBER, with Oracle DATE, and with intervals, and whether the answer came from the SnowConvert reference or the Openflow connector documentation.

What Oracle licensing does your connector require?

The question that changes budgets on this route and almost never gets asked. A log based connector reading through XStream carries an Oracle entitlement, since Oracle documents that a GoldenGate license includes XStream and that Enterprise Edition is a prerequisite. Query based and export based approaches avoid it and pay in latency instead. Get the answer in writing before the pilot.

What happens to tables with no primary key?

Snowflake's own connector will not replicate them without a key or a declared logical key, and mature Oracle schemas are full of keyless audit and history tables. Ask how the vendor handles them, then ask them to run the query against your catalog rather than describe the answer in general terms. The list is usually longer than either of you expects.

What does the backfill cost, separately from steady state?

A migration backfill is not a normal month. On row or event based pricing it is the largest month you will ever have, and on credit based pricing it is a sustained spike in warehouse time. Ask the vendor to price the backfill plus two reloads, because there will be reloads while the type mapping is corrected.

Related migration and warehouse guides

Oracle is one route into Snowflake among several. These cover the neighboring sources, the other destination Oracle teams price against Snowflake, the ongoing load case, and the cost model behind a migration program.

Questions buyers ask about Oracle to Snowflake migration

How do I migrate data from Oracle to Snowflake?: Convert the schema first, then move the rows, then keep them in sync until you can retire the source. SnowConvert handles the DDL and PL/SQL for free. A log based connector handles the rows. The step most teams skip is checking the type mapping before the first load, because Snowflake publishes two mappings for this route and they disagree about the most common numeric column in an Oracle schema.
What is the best Oracle to Snowflake connector?: Snowflake Openflow is the first-party answer and it is the most likely to stay current. Price its prerequisites before you assume it is the cheap option: it reads through an Oracle XStream Outbound Server, Oracle licenses XStream through GoldenGate, and Enterprise Edition is a prerequisite. If your Oracle estate is Standard Edition, Snowflake states its connector does not support it.
How much does an Oracle to Snowflake migration cost?: Three bills, and the connector license is usually the smallest. You pay for Snowflake warehouse time across the backfill and every reload while the mapping is being corrected, for engineering time converting PL/SQL that no tool converts fully, and potentially for an Oracle entitlement the connector requires. Budget for at least three full reloads, because the first two will be wrong in ways row counts do not reveal.
Can Snowflake pull data from Oracle directly?: Not with a query. There is no Oracle database link you can point at Snowflake and no federated read. Something has to sit between them: Snowflake Openflow, a managed pipeline such as Fivetran or AWS DMS, GoldenGate writing into a stage, or a scheduled export to files that Snowflake loads with COPY INTO. Every option here is that middle piece.
Does Oracle to Snowflake migration need GoldenGate?: Not always, but read the licensing before deciding. Snowflake's own connector reads from an XStream Outbound Server, and Oracle documents that a GoldenGate license includes XStream with Enterprise Edition as a prerequisite. Query based and export based tools avoid XStream entirely at the cost of latency and load on the source. That trade is the real decision on this route.
How does Oracle to Snowflake data type mapping work?: Most types have an obvious target and a non obvious consequence. Oracle DATE has no fractional seconds and arrives with nine. Oracle scale runs from -84 to 127 and Snowflake stops at 37. Anything outside those bounds is stored as text with no error. The table further down gives every mapping and what each one costs you.
What are the main Oracle to Snowflake migration challenges?: PL/SQL is the big one, because packages, triggers and cursors have no direct Snowflake equivalent and conversion is never fully automatic. After that: tables with no primary key, which Snowflake's connector cannot replicate at all, the type edge cases where Snowflake's own two documents disagree, and constraints that Snowflake accepts and does not enforce.
Is there an Oracle to Snowflake converter?: Yes, and Snowflake gives it away. SnowConvert translates Oracle DDL, views, PL/SQL and SQL into Snowflake syntax and costs nothing to run. It converts code, not data, so you still need something to move rows. Treat its output as a first draft: several of its published Oracle type notes need the corrections in the table on this page.
How do I migrate Oracle EBS or Fusion to Snowflake?: Differently, and check the supported list first. Snowflake states its Oracle connector does not support Oracle SaaS offerings including Oracle Fusion and NetSuite, and does not support Oracle Autonomous Database. E-Business Suite running on a database you control is in scope, but the schema is enormous, so scope the extract to the modules you actually report on rather than the whole application.
Should I use AWS DMS or Fivetran for Oracle to Snowflake?: AWS DMS if the Oracle instance already lives in AWS and you are comfortable running and sizing a replication instance that bills by the hour whether or not data moves. Fivetran if you want the pipeline to be somebody else's problem and your volume is predictable, remembering that a migration backfill is the largest active-row month you will ever have.

For the people cost that dominates every migration program, read what a data migration really costs. For the neighboring warehouse route from a different source, see SQL Server to Snowflake migration tools, and for the wider vendor landscape, the best data integration tools.

Oracle to Snowflake migration tools, connectors and data type mapping compared, including the Oracle license behind Snowflake's own connector