Why Oracle estates are moving
Three forces are converging: Oracle licensing economics, a shrinking pool of engineers who know PL/SQL, and cloud strategies that expect interoperability with cloud-native ML tooling. Year one is rarely a cash-savings story, since you absorb the migration cost and run two systems in parallel. The real savings start in year two. Sometimes the right answer is to keep Oracle, for example for small, stable workloads under about 1 TB, and an honest conversation about whether to migrate comes first. The numbers are in the Oracle to Snowflake playbook.
What gets migrated, and what does not
Discovery inventories every schema, table and PL/SQL object, traces hidden consumers and flags Oracle-specific features that have no Snowflake equivalent. The output is a migration inventory with risk scores, a dependency graph and a list of items to refactor or retire instead of port. That list has never been less than 15% of the original Oracle estate.
Schema redesign and PL/SQL conversion
A one-to-one DDL translation carries forward years of accumulated workarounds, so the schema is redesigned instead: indexes are dropped, partitioning is reconsidered against Snowflake clustering keys, and data types are reviewed. PL/SQL packages are typically split three ways: most of the logic is transformation that belongs in dbt, orchestration moves to Airflow, and only a small residual becomes a Snowflake stored procedure. Sequences, date and timestamp semantics, materialised views and CONNECT BY hierarchical queries each need individual handling.
Cutover and validation
Data moves from Oracle through Data Pump or external tables to cloud storage and into Snowflake with COPY INTO. The cutover strategy is chosen deliberately: a parallel run, a staged cutover by domain, or analytical workloads first. Validation covers row-count parity, aggregate parity, sample-row diffs and consumer-side checks, and it is the phase that must not be cut when the project runs late.
Fixed-fee readiness assessment
Before committing to a full programme, the Snowflake Migration Readiness Assessment delivers a migration inventory, dependency map, do-not-migrate list, Oracle TCO versus cloud cost-benefit model and a phased roadmap in two to three weeks. It costs £9,000 fixed, credited in full against your migration if you proceed within 60 days. For the general service, see Snowflake migration.
Frequently asked questions
Can PL/SQL packages be converted to Snowflake?
Not line for line. Most packages are mostly transformation logic that belongs in dbt, with orchestration moving to Airflow and a small residual becoming a Snowflake stored procedure.
How long does an Oracle to Snowflake migration take?
The five phases are discovery (2–3 weeks), schema redesign (3–4 weeks), data movement (2–8 weeks), pipeline rebuild (4–6 weeks) and cutover and validation (1–2 weeks). Data movement runs in parallel with pipeline rebuild.
Is migrating from Oracle always the right call?
No. Small, stable workloads under about 1 TB, applications deeply tied to Oracle quirks, and periods of regulatory audit are cases where deferring or keeping Oracle can be the better decision.
What does the readiness assessment cost?
£9,000 fixed for a two-to-three week diagnostic, credited in full against your migration if you proceed within 60 days.
How do I get in touch?
Email hello@ak-datageek.com. AK-DataGeek is now booking Q1 2027, one or two engagements at a time.