Many teams only discover how locked in they are to their switching silicon on the day it becomes a problem. This could be a vendor posting an end-of-life notice, a pricing change at renewal, or a roadmap announcement that no longer matches yours. When that happens, the question changes from whether to move to what moving costs, and almost nobody has that number ready.
Part of the reason is that lock-in is widely seen as a single problem. In fact, there are three separate dependencies in play: the SDK your data-path software is written against, the toolchain your engineers have learned, and the roadmap your deployment schedule leans on. Each carries a different cost and a different way out.
In this page, we'll look at each type of lock-in and give you the key questions to ask your potential vendors, including us.
Before we talk about vendor lock-in and how to avoid it, it's important to understand the idea of “merchant silicon.” Most networking companies don't design their own switch chips from scratch. Instead, they buy a chip from a company that specializes in making switch chips and build their own product around it. That purchased chip is called “merchant silicon” because it was bought off-the-shelf from a merchant, not built in-house.
This is often the root of the lock-in problem: the moment you buy someone else's chip, you inherit whatever restrictions come attached to it. The SDK, the toolchain, and the roadmap are all controlled by whoever sold the chip.
When switching, the number that people always focus on is the hardware and associated costs: new silicon, new boards, new bring-up. It's the most visible cost, but often the least significant, because underneath this sit three dependencies, each with its own price tag.
This is the one most teams underestimate, because the code still looks like theirs. The test isn't whether you wrote it, it's whether it means anything anywhere else.
Ask how the data-path programming interface is specified, and whether that specification is public. An open instruction set can be implemented by more than one supplier and read by more than one toolchain. A proprietary SDK is a contract with exactly one company, and its value goes to zero the day you leave.
Most of the sunk engineering investment sits here in data-path code written against a proprietary SDK, and internal tooling built around one vendor's debugger. None of this transfers by itself, and on a mature deployment it routinely exceeds what you paid for the hardware. Unlike the hardware, it appears on no asset register.
The fact is that a proprietary SDK is a proprietary SDK whoever ships it, and every supplier that keeps its interface closed creates the same dependency, including suppliers whose marketing emphasizes openness further up the stack.
Ask your ASIC vendor: is the data-path programming interface publicly specified, and could another vendor implement it without your permission?
The toolchain is where lock-in becomes a people problem. Compilers, debuggers, simulators, CI integration and test rigs all accumulate around whatever the vendor supplies, and so does your team's expertise. Engineers who've spent years becoming fluent in a toolchain that exists in just one place can't apply that fluency elsewhere.
The useful question isn't whether the tools are good. It's whether the skills and the infrastructure can survive a change of supplier. Where a vendor builds on established open components, such as standard compiler infrastructure, common network operating systems and published management interfaces, an engineer moving between platforms takes most of their competence with them. Where the tools are wholly bespoke, that competence is stranded.
This is also where the practical solution usually sits. Portability at the network OS layer means the software above the silicon can often move even when the data-path code below it has to be rewritten. SONiC switches and SAI can enable this portability. These solutions don't eliminate migration entirely, but they can considerably reduce its cost and impact.
Terminology check: what does “SAI” mean? SAI stands for “switch abstraction interface.” It's a standardised, open-source API that allows for the control of a forwarding element, such as a switching ASIC.
Ask your ASIC vendor: which parts of my toolchain are built on open, industry-standard components, and what exactly would my team have to relearn?
The first two dependencies decide what leaving costs. The third decides whether staying is safe.
Every deployment plan includes an inherent assumption that the supplier's roadmap will keep pace with your requirements. When supporting a new protocol or port speed depends on someone else's tape-out schedule, your roadmap is a derivative of theirs. The two diverge eventually, and you absorb the difference. The assumption is invisible until it fails.
Assess it on two axes: first, does the vendor commit publicly to a scaling path, or does each generation arrive as a surprise? Second, does new capability need new silicon? A supplier who can deliver a new protocol as a software update is offering a different risk profile from one who can only deliver it as a new chip, on a schedule you don't control.
Ask your ASIC vendor: what would I need to buy when a new protocol lands, and what is your published end-of-life policy for the part I'm buying today?
A vendor who knows you can't realistically leave has no commercial reason to quote competitively to retain your business. You never see this reduced commercial leverage as a line item, but the opportunity cost of discounts is there year after year, renewal after renewal.
It's also why this exercise is worth doing even if you have no intention of moving. Knowing your exposure tells you what your position is worth.
When Oxide Computer Company's vendor announced the discontinuation of the programmable switch platform they were using, Oxide faced a critical decision. Their existing design relied on that platform for network programmability. The P4-based forwarding code represented significant engineering investment that they needed to preserve.
Oxide successfully migrated their P4-based forwarding code from their previous switch silicon to X2. The migration preserved existing functionality while leveraging X2's parallel execution model, which removes the recirculation penalties common in serial P4 pipelines.
Terminology check: what is a “P4 programmable switch” and a “P4 compiler”? A traditional network switch relies on a fixed-function ASIC with hardwired packet processing logic. A P4 programmable switch, on the other hand, has an ASIC with flexible hardware blocks, allowing for programmable packet-processing pipelines instead of fixed ones. A P4 compiler translates code written in the open-source P4 language into hardware-level instructions, pipeline layouts and table configurations specific to a target ASIC.
Bryan Cantrill, Oxide's CTO, called it switching silicon's x86 moment. The transferable lesson isn't that migration is easy. It's that migration cost is set years earlier, by how much of your investment you let accumulate inside one vendor's proprietary interfaces. Oxide could move because of decisions taken long before they decided to.
Everything above applies whoever you buy from. This last part is our position.
We openly publish the specification for XISA, our instruction set architecture, under the Mozilla Public License version 2. That's a structural choice rather than a feature: the interface your engineers write against is a public specification, not a private contract. Your investment is documented in something you can read and keep, independent of the commercial relationship.
Around it, the X2 runs native Linux, DPDK and SONiC out of the box, so the software layer above the silicon stays portable, and our roadmap is published rather than arriving one generation at a time. The X2 itself delivers 12.8 Tbps at deterministic sub-700ns latency under 200W.
Two things this does not do. Xsight is currently the only company implementing XISA, so an open specification is not by itself a second source. And the pool of engineers already fluent in XISA is small compared with an incumbent's, so staffing is a real consideration.
None of this makes switching free. What it changes is the shape of the dependency. Instead of something opaque, it becomes something you can review, consider, and take into your next negotiation, with us or with any other vendor.
To take this further, the programmability evaluation checklist sets out ten criteria you can put to any vendor, with the questions to ask and how to test the answers.
Our engineers built these solutions to solve real infrastructure challenges. See how they apply to your environment.