DNI — From Legacy Technical Debt to Technical Death

Why enterprises still clinging to Oracle, Teradata, IBM Netezza, SQL Server and SSAS are not preserving stability — they are slowly writing their own analytical obituary. And the clock is ticking faster than most of them realize.

Abstract

Legacy DWH platforms — Oracle, Teradata, IBM Netezza, Microsoft SQL Server, and yes lets not forget Microsoft SSAS — they were state-of-the-art maybe in 2005. In 2026 they are costing enterprises between $100K and $2M+ per year in licensing alone, burning engineering weeks on tuning cycles that produce zero business value, and — what frustrates me most — blocking every credible AI initiative at the data layer. I see this every week in my customer conversations across the DACH region. The organizations that run Exasol are 97% faster on data load, 164× faster on reporting, and 50–80% cheaper to operate. The rest are still renewing Oracle Enterprise contracts and calling it “risk management”. I call it DNI — Do-Nothing-Inc. — and this blog is my attempt to put the real numbers on the table. Five legacy platforms, three verified customer stories (bank99, Helsana, OTTO), the open-source exasol/database-migration tooling, which makes the move a standard engineering exercise, and Exasol’s AI-to-Data UDF framework that turns a passive data store into an active AI participant. DNI is not a strategy. It is a slow-motion business obituary.

1. The DNI Trap

The DNI Problem — Why “Do Nothing” Is Still a Decision

Let me be direct. In almost every customer engagement I do across DACH, I encounter the same enterprise archetype: the organization that spent two decades building its analytical backbone on Oracle or Teradata, and is now spending more on keeping those systems alive then on the actual analytics they were supposed to deliver. We may call this archetype DNI — Do-Nothing-Inc.

The argument from DNI always sounds reasonable. “We have too much invested to switch.” “Our DBAs know this system inside out.” “The migration risk is too high.” And yes, I understand — migrations are not trivial, and nobody wants a failed cutover on a Monday morning. But while DNI is carefully calculating its risk-aversion strategy, the market is moving. Emerging AI analytics providers — Pinecone, StarTree, Yellowbrick, SQream — and most critically Exasol — are redefining what a data warehouse can and should do in 2026. The enterprises that modernize will accelerate. The ones that don’t — the DNIs — will find themselves competing with organizations running 164× faster analytics on 50% of the budget. That is not a risk. That is a structural competitive disadvantage.

What Goes Wrong at DNI

💰 Per-core and per-TB licensing that penalizes every growth milestone Oracle per-core option packs and Teradata per-TB pricing mean that every business success — more data, more users, more workloads — becomes simultaneously a license bill increase. Exasol’s capacity-based flat-rate breaks this spiral completely. It’s one of the most underappreciated advantages of switching.

⏳ Engineering weeks consumed by tuning cycles that deliver nothing Oracle AWR/ASH analysis, Teradata COLLECT STATISTICS runs, SQL Server columnstore/rowstore complexity, SSAS cube reprocessing windows — senior data engineers at DNI spend the majority of their week keeping the lights on. Not building AI features. Not delivering business value. Just maintenance.

🔒 Hardware and vendor lock-in with zero cloud exit path IBM Netezza is the most extreme case — FPGA hardware evolution has been discontinued, there is no cloud migration path whatsoever, and every day that passes increases the operational risk of running on a dead-end vendor stack. SSAS OLAP cubes are a close second: MDX is a dying skill, and the cube processing architecture fundamentally cannot support real-time analytics.

🚫 No path to AI-native analytics — full stop Every legacy platform in this list shares the same architectural flaw in an AI era: they move data to compute. Export to Python, load to Spark, ship to a GPU cluster somewhere. The result is pipeline complexity, latency, governance gaps and — ultimately — AI initiatives which stall permanently at the data layer since they can never get clean, fast access to the data they need.

📉 6-hour data loads blocking the morning BI cycle This is not hyperbole. bank99 — the bank of the Austrian Postal Service — was running daily data loads of up to 6 hours on their SAS + Oracle + SQL Server stack. Business users could not trust data that was half a day old. BI consumption suffered. Regulatory reporting became stressful. This is what DNI looks like at 7 AM on a Monday.

2. The Five Legacy Sinners

Platform-by-Platform: Where the Pain Really Lives

Not all legacy platforms are equal in their failure modes. From years of migration conversations across the DACH enterprise market, here is how each of the five major DWH legacy platforms actually behaves as technical debt — and what the primary migration risk is for each.

3. The Migration Economics

What the Numbers Actually Say — No Sugarcoating

We built the Exasol ROI & Impact Calculator specifically because customer conversations always stall on the same question: “OK but what does it actually cost, and when do we see return?” So here are the numbers — mid-market to large enterprise ranges, sourced from real engagement data. Your specific environment will be different, but the direction never is. Note that IBM Netezza is highlighted separately since every additional day on a dead-end EOL vendor stack adds operational risk that goes well beyond the licensing cost discussion.

Legacy Platform	Annual License / TCO	Migration Timeline	SQL Effort	Est. Exasol Savings	ROI Payback
Oracle — Per-core + Enterprise Options	$500K – $2M+ / yr	3–9 months	Medium	50–80%	12–24 mo
Teradata — Per-TB active data pricing	$300K – $1.5M / yr	2–5 months	Low	55–75%	12–18 mo
IBM Netezza ⚠ EOL — EOL hardware + IBM maintenance	$200K – $800K / yr	1.5–3 months	Lowest	60–80%	6–12 mo
MS SQL Server — Enterprise + CALs + hardware	$150K – $500K / yr	3–7 months	Medium	40–65%	12–24 mo
MS SSAS — OLAP platform + MDX toolchain	$100K – $400K / yr	3–6 months	Specialist	45–70%	12–18 mo

The license numbers above are only the starting point — and in my experience they are the most visible part of a much larger iceberg. Add the DBA time consumed by AWR analysis, COLLECT STATISTICS and tempdb tuning — at $150–$250/hr fully loaded rate that is easily another $300K–$600K per year at mid-market scale. Then add the engineering opportunity cost of teams maintaining legacy pipelines rather than building the AI features your business is actually asking for. True TCO is typically 2–3× the licensing number when you count all the labor honestly.

And on the Exasol side, the structural advantage is this: flat-rate capacity-based pricing means that as your data volumes grow, Exasol gets relatively cheaper. With Oracle and Teradata it goes exactly the other direction — success becomes expensive. That fundamentally is an unsustainable model for any growing enterprise.

4. The Migration Toolchain

exasol/database-migration: This Is Already Bread-and-Butter Stuff

One thing that surprises many customers when we first start talking about migration: the tooling already exists, it’s open source, and it covers all five legacy platforms we discussed. The exasol/database-migration repository on GitHub contains ready-to-run SQL scripts for 18+ source systems. This is not a prototype or a side project — it has been in production use across Exasol customer migrations for years.

The workflow is three steps: create a JDBC connection to your source, test connectivity with a simple SELECT statement, then run the migration script. It queries your source system’s metadata catalog, auto-generates schema-aligned IMPORT statements with correct data type mapping, and handles everything automatically. Delta import scripts exist for parallel-run synchronization during the cutover window. Post-load optimization scripts reduce storage footprint.

This is what I mean when I say migration to Exasol is textbook standard — the engineering heavy lifting is already done, and it is freely available on GitHub.

Note on Open Source: The exasol/database-migration repository is community-maintained under MIT licence — it is not officially supported by Exasol AG.

5. The Shift-Left Angle

Shift-Left with Exasol: Bringing AI to the Data, Not Data to AI

In my previous Exasol blog post on Shift-Left and Medallion architectures, I wrote about moving validation, enrichment and governance upstream to eliminate pipeline complexity. The same principle applies here — but now we are talking about a fundamentally more transformative step: not just simplifying pipelines, but replacing the entire analytical foundation.

Every legacy platform I described in Section 2 shares the same architectural flaw in an AI-first world: they move data to compute. Extract to Python. Load to Spark. Ship to a GPU cluster somewhere. The result is pipeline fragility, latency tax, and governance gaps that kill AI initiatives before they even start.

Exasol inverts this completely. Through its UDF (User Defined Function) framework, Python, R, Java and Lua scripts run inside the Exasol engine, co-located with the actual data. A machine learning inference cycle that used to require a 30-minute export-transform-predict-reload loop on Oracle now runs as an Exasol UDF in seconds — directly on the analytical cluster, without any data movement at all.

	❌ Old Way — Legacy DWH	✅ Shift-Left — Exasol AI-to-Data
Compute model	Export data to external compute environment for ML	Python / R / Java UDFs execute inside the DB engine
Latency	Spark / Python pipeline adds latency and failure points	ML inference at warehouse speed — zero data movement
BI freshness	BI tools query pre-aggregated cubes or stale extracts	DirectQuery: BI tools query live Exasol data in real time
AI foundation	AI initiatives stall permanently at the data movement layer	AI runs on governed, compliant and always-fresh data
Engineering focus	Engineers maintain pipelines, not AI features	Engineers build models and features, not maintenance tickets
Data load	6-hour data loads mean BI is always half a day behind	Sub-10-minute loads — morning BI always current, always trusted

The Shift-Left / AI-to-Data Architecture Stack

Layer	Technology	Function
🏢 SOURCE SYSTEMS — Legacy platforms being replaced	Oracle · Teradata · Netezza · SQL Server · SSAS	Migrated via exasol/database-migration scripts. Schema and data land in Exasol with automatic type mapping and distribution key optimisation. Old system enters parallel-run phase until cutover.
🔄 MIGRATION LAYER — Automated toolchain	exasol/database-migration · JDBC / OCI / Teradata JDBC · Delta import scripts	Three-step automated migration. Connection → schema metadata extract → IMPORT statement generation. Delta scripts maintain synchronisation during the parallel-run window before hard cutover.
⚡ EXASOL ENGINE — In-Memory MPP + UDFs + ESL	Exasol 8 · SaaS / on Azure / on AWS · Python · R · Java UDFs · Exasol Semantic Layer (ESL)	Sub-second analytical queries on TB-scale data · 100+ concurrent users · In-database ML via UDFs · ESL replaces SSAS OLAP cubes entirely · Self-tuning — zero DBA tuning overhead
📊 BI & AI CONSUMERS — DirectQuery + ML features	Power BI · Tableau · Looker · Jupyter · Kestra · Custom APIs	Live DirectQuery on always-fresh Exasol data. ML feature engineering 50× faster on governed, pre-validated data. Self-service BI enabled accross the entire organisation — no MDX expertise required.

6. Proof, Not Promises

Three Enterprises That Got Out — and What It Actually Looked Like

I am aware that every vendor blog is full of transformation stories that look suspiciously perfect. So let me be specific about what these three case studies actually represent: all outcome figures come directly from published Exasol customer references at exasol.com/customer-stories. Nothing is estimated or directional here — these are verified results.

Starting Point: What DNI Looks Like at Scale

bank99 (before Exasol): SAS on Oracle plus Microsoft SQL Server — daily data loads of up to 6 hours, completely blocking the morning BI cycle. No real-time reporting. Regulatory historization was manual and error-prone. Austrian Post AG subsidiary with stringent compliance requirements and zero flexibility in the existing architecture.

Helsana (before Exasol): Switzerland’s largest health insurer running Legacy DWH with 26-hour nightly load cycles and quarterly — yes, quarterly — data refreshes. Fragmented BI across multiple systems with different versions of truth. No AI readiness whatsoever. High Legacy DWH licensing and maintenance costs ate into the IT budget every year.

OTTO (before Exasol): Germany’s largest e-commerce platform with a legacy DWH, SSAS OLAP cubes requiring MDX specialists for every change, cube processing blocking data freshness, and BI delivery cycles of 6–8 weeks per new request. At 52,000 employees and 3 million products, that delivery velocity was simply not acceptable.

The Transformation: Quantified Business Impact

Metric	Before (Legacy / DNI State)	After (Exasol)	Improvement
🏦 bank99 — Data Load Time	Up to 6 hours daily (SAS + Oracle + SQL Server)	~10 minutes	→ 97% reduction
🏦 bank99 — BI Data Freshness	Half-day lag; real-time reporting impossible	DirectQuery — always live	→ Real-time
🏥 Helsana — Load Window	26 hours (Legacy DWH nightly load cycle)	4 hours	→ 85% reduction
🏥 Helsana — Data Refresh Cadence	Quarterly	Daily	→ 12× more frequent
🏥 Helsana — Platform Cost	Legacy DWH licensing + maintenance + fragmented BI tools	Unified Exasol hub	→ ~65% cost reduction
🛒 OTTO — Reporting Speed	Legacy DWH performance baseline	164× faster	→ 164× acceleration
🛒 OTTO — Platform Cost	Legacy DWH + SSAS total cost of ownership	Exasol + ESL	→ 50% savings
🛒 OTTO — Code Complexity	MDX cube logic + overlapping ETL pipelines	Exasol Semantic Layer (ESL)	→ 90% complexity reduction

A Special Word on the SSAS Exit — Why ESL Changes Everything

SSAS migration deserves its own callout since its outcome is architecturally the most transformative of the five platforms. The Exasol Semantic Layer (ESL) replaces every SSAS cube with a governed semantic model that all standard BI tools can consume natively — Power BI, Tableau, Looker — via standard SQL and DAX connectors. No MDX. No cube processing windows. No specialist redeployment cycle for every business logic change.

As OTTO demonstrated, the numbers speak for themselves: 90% code complexity reduction, zero cube administration overhead, and business users who can access insights completely independently without any MDX knowledge. One migration project delivers two things simultaneously — analytical speed from Exasol’s engine, and business agility from ESL, replacing the SSAS bottleneck. Refer to the OTTO Semantic Layer case study for the detailed outcomes.

7. Why Exasol Breaks the Cost Spiral

Four Capabilities That Legacy Platforms Fundamentally Cannot Deliver

I want to be clear that this is not a general “modern is better than old” argument. The four capabilities below are specific, technical, and architecturally impossible on the legacy platforms I described. They are not features that Oracle or Teradata could add in a patch release. They require a completely different architecture.

8. Your Legacy Exit Roadmap

Five-Phase Migration Methodology — From Discovery to Decommission

The migration is not a rip-and-replace. It is a phased, automation-first engineering programme with quantified checkpoints at every stage. I want to repeat what I said earlier: this is not a theoretical framework — it is the Technical Migration Playbook which has been built from real field engagements and which includes source-specific SQL compatibility tables, the exasol/database-migration script gap analysis, pre-screen SQL for all unhandled source types, and the 7 critical gotchas that I guarantee will come up in every serious migration project if you are not prepared for them.

Phase 1: Discovery & Pre-Screen (Weeks 1–2)

• Run pre-screen SQL queries against the source system to flag all unhandled types — ST_GEOMETRY, NVARCHAR, ROWVERSION, BINARY VARYING. Do not skip this step.
• Inventory stored procedures and identify PL/SQL rewrite scope — this is the primary Oracle project risk, and it needs to be sized accurately before any commitment
• Estimate data volume, query mix, peak concurrency requirements and SLA expectations in Exasol
• Map all SSIS pipeline dependencies (SQL Server) and SSAS cube inventory, including MDX measures that will become ESL models

Phase 2: Schema & Metadata Migration (Weeks 3–4)

• Run the exasol/database-migration script against source — it auto-generates Exasol DDL for all tables with correct type mapping
• Apply pre-screen corrections: exclude TIMESTAMP/ROWVERSION (SQL Server), pre-process NVARCHAR (Netezza), handle ST_GEOMETRY columns
• Configure distribution and partition keys for Exasol’s shared-nothing MPP architecture — this directly impacts query performance
• Validate schema completeness: row counts, primary key definitions, foreign key preservation

Phase 3: Data Load & Validation (Weeks 5–6)

• Parallel IMPORT execution — Exasol’s in-memory engine absorbs data at wire speed, and loading is consistently the fastest phase
• Row count and checksum validation across all migrated tables — do not skip this, even if the migration script ran cleanly
• Post-load column type optimization scripts to minimize storage footprint and accelerate columnar compression
• Delta import scripts configured for ongoing synchronization during the parallel-run window before hard cutover

Phase 4: SQL Compatibility & AI Enablement (Weeks 7–10)

• Oracle PL/SQL → Exasol Lua scripting or Python UDFs for procedural logic; this is the most time-consuming phase for Oracle migrations, size it honestly
• Teradata BTEQ / MultiLoad → standard ANSI SQL (genuinely low effort — best-case migration of all five platforms)
• SSAS MDX measures → Exasol Semantic Layer (ESL) model definitions; business users can be involved in this phase directly since ESL requires no MDX knowledge
• Deploy Python/R UDFs for in-database ML — this is when the AI-to-Data capability comes live and typically produces the first “wow” moment for business stakeholders

Phase 5: Cutover & Legacy Decommission (Weeks 11–12+)

• Parallel-run validation: compare BI output between legacy and Exasol for the same business day — this is the definitive sign-off test
• Hard cutover: redirect all BI tools, ETL pipelines and application connections to Exasol in one coordinated step
• Legacy system decommission — license recovery begins from day one after decommission, this is when the ROI calculation becomes real money
• Measure and report: data load delta, query performance uplift, concurrency capacity, actual cost delta vs. the Calculator projections

9. Ready to Start the Conversation?

The Legacy Exit Is Not a Risk — Staying Is

I want to close with the honest framing. The migration is not risk-free — I have been transparent about that throughout this post. PL/SQL rewrites take time. Pre-screening matters. The gotchas are real. But those risks are bounded, engineered, documented and tooled. You can scope them, plan for them and mitigate them systematically.

The risk of not migrating is completely different in character. It is open-ended, compounding, and — for enterprises that genuinely need AI-native analytical capabilities to compete — it is existential. Every quarter DNI spends renewing its Teradata contract is a quarter the competition gets faster, cheaper and more AI-ready on Exasol. That gap does not close by itself. It only widens.

And you know what? The three companies in Section 6 — bank99, Helsana, OTTO — they all had the same internal conversation DNI is having right now. “Is this the right time?” “Is the risk manageable?” They decided it was. Their data now loads in minutes instead of hours. Their engineers build features instead of tuning cycles. Their AI initiatives have a data foundation that can actually support them. That is what the other side of the migration looks like.

Start Your Legacy Exit Conversation

Bring your platform. We bring the playbook, the calculator, and a migration blueprint on your actual data — not synthetic demos.

Legacy Exit Pilot Programme

• Identify your top 3 most painful legacy processes
• Run the ROI Calculator against your actual license spend
• Exasol Solutions Engineering designs the migration blueprint
• Pilot with quantified performance and cost comparison
• Zero infrastructure investment required to start
• Exasol SaaS, on Azure, or on AWS — three deployment models