Ask most vendors what a migration costs and you’ll get a license fee. That’s one line out of six.
The Actual Bill
- License fees for the target platform, and often for the migration tooling itself
- Infrastructure for staging, parallel environments, and the compute needed to move large volumes at speed
- Engineering time to build the pipeline: schema translation, type mapping, change capture, retries, validation
- The cost of downtime or a degraded cutover window while the switch happens
- Reconciliation, because nobody signs off a migration on trust alone
- The overlap period where old and new systems both have to be kept running and kept in sync
Most of the conversation happens around the first line. The other five are where the real money and risk sit, and where SMF and SDF actually earn their keep.
Where SMF Already Does This
SMF has been running production Netezza-to-Netezza replication and disaster recovery since 2021. A customer moving from a Hammerhead-generation appliance to a Barracuda-class N4001 doesn’t need a bespoke migration project. The replication and DR functionality is already running, continuously, for reasons that have nothing to do with the hardware refresh. The migration rides on infrastructure that was a sunk cost before anyone decided to swap appliances.
That’s what collapses the bill. Item three on the list above, the bespoke engineering effort, mostly disappears because nobody has to build it for this specific move. Item four, downtime, shrinks because the cutover is a 15-minute replication failover rather than a big-bang cutover with a maintenance window and a prayer. Items one and two don’t go away. You’re still paying for SMF and for the environment it runs in. But if you were already using SMF for database replication or disaster recovery, there’s no additional charge beyond what you were already paying before you decided to migrate anything.
Where SDF Is Starting to Change the Argument
SMF’s story has always been Netezza to Netezza. What’s shifted that argument recently is the cross-platform work we’ve been doing with a long-standing Netezza customer moving analytics workloads to Databricks.
They’d been running an ETL tool to handle this workload at a cost they’d come to see as unacceptable: around $10,000 a month. That bill is what pushed them to try building the bridge themselves, in-house, using AI, rather than keep paying it.
They got far enough to understand exactly why it’s hard, and stopped. Schema drift needs handling on every run, not just the first one. Change data capture on a legacy platform is its own project. Type mapping between an appliance built in the 2000s and a Delta Lake table has enough edge cases to eat a quarter of engineering time. And when they went to move a ten-billion-row table, the unload alone saturated I/O badly enough that it had to be rescheduled to run after hours.
Between the $10,000-a-month tool and the in-house build, neither one held up. That’s when they found SDF, and it’s what they went with: cheaper than what they’d been paying, better value for the money, and it worked better than the mess they’d built internally. None of that is a surprise to us. It’s exactly the class of problem the new SDF, re-engineered from the ground up with a completely new front end and genuine cross-platform capability, was built to solve.
SDF‘s Enterprise tier does the same categories of work SMF has done for years, aimed at any-to-any migration rather than one appliance generation to the next: native bulk-transfer protocols instead of generic row-by-row copying, engine-native change data capture, and cloud-staged transfers built for the throughput a multi-terabyte Netezza table needs. Community edition covers the common open source relational engines and file formats. Pro adds the cloud targets and scheduled incremental sync. Enterprise is where Netezza, Oracle, and the bulk-transfer and CDC machinery live, because that’s where the volumes and the legacy quirks get serious.
Where the Rule-Based Approach Runs Out
Schema translation is easy until it isn’t. Most views translate mechanically: dialect differences map cleanly, and a rule-based converter handles the whole thing without a human touching it. Some views don’t. They lean on functions or syntax with no clean equivalent on the other side, and a rule-based converter either fails outright or produces something that’s wrong in a way nobody notices until it’s in production.
SDF optionally hands those to a BYO AI model instead, one view at a time. It’s not a wholesale AI rewrite of the schema: the rule-based converter still does the bulk of the work, and the model only sees what it can’t handle. SDF checks that the result actually parses under the target dialect before accepting it, and caches successful conversions so the same pattern isn’t solved twice. That’s Pro and Enterprise.
Stored procedures are next: the same approach, extended to procedural code, landing in Enterprise.
A Capability, Not a Project
Migration used to be an event: something you planned for a year, budgeted as a project, and hoped never to repeat. If the tooling that does the hard part is already running continuously, for reasons that have nothing to do with any particular move, migration stops being an event. It becomes a capability sitting on the shelf, ready whenever the business needs it: moving data and workloads between Azure, AWS, and Google to take advantage of price arbitrage, or benchmarking an alternative to your current database platform against realistic production volumes and queries.
Where to Start
SDF Community edition is launching free today: PostgreSQL and MySQL, plus CSV, Parquet, and Avro, up to five jobs, no licence key required. If your migration doesn’t touch Netezza or Oracle and doesn’t need cross-platform change data capture, you can be running real jobs against real data before anyone’s had a sales call.
Pro and Enterprise cover the parts this article has been about: cloud targets, scheduled incremental sync, native CDC, AI-assisted view conversion, and the bulk-transfer protocols that make Netezza and Oracle migrations behave. Stored procedure conversion is landing in Enterprise next. If that’s closer to what you’re planning, get in touch and we’ll work out which tier fits.
