Migrating to open source Kafka: cutting TCO without the operational burden

If you are weighing whether to renew a Confluent contract, stay on Amazon MSK, or move to a self-managed or partner-managed open source Kafka setup, the decision usually comes down to three things: technical fit, risk, and cost. In this session, Chad Harris (Factor House) and Justin George (NetApp Instaclustr) walk through what a migration involves in practice, including what moves cleanly and what depends on proprietary features you will need to replace.

Most of the session focuses on total cost of ownership, because that is where migrations most often go wrong. Self-hosting Kafka can end up more expensive than a managed vendor if you over-provision “for safety” instead of tuning, leave default configuration settings unreviewed, or pay for vendor bundle capabilities you never use. Chad and Justin walk through these patterns with real numbers, including a cost comparison across MSK, Confluent, and managed open source Kafka.

The session closes by addressing the question underneath most “open source is too hard to manage” concerns directly: what it takes to build that operational capability in-house, versus what a managed layer and a self-service visibility layer can take off your plate. The goal is not to argue that any one vendor is cheaper. It is to show what it takes to spend less time operating Kafka and more time building on it.