Open Linux Gateway Migration

The operator ran a fleet on closed, proprietary gateways with locked-down firmware. The vendor controlled the release cadence, the supported integrations, and, because the firmware was a black box, the security posture of every device in the field. Pricing pressure, end-of-life signals from the vendor, and the inability to run a real audit had pushed migration from “nice to have” to “this quarter.”

The migration target was an open Linux gateway with embedded software fully owned by the operator, deployed in a staged rollout with a rollback path, and handed over with documentation that lets the operator extend the stack without us.

Vendor lock-in. The firmware was a single-vendor dependency for updates, support and any new feature. We needed the post-migration stack to be portable across hardware classes and free of single-vendor chokepoints in software.

Security blind spots. The closed firmware could not be audited. The replacement had to be reproducible from source, signed, and verifiable end-to-end so security and compliance had a real artifact to review.

End-of-life risk. Old hardware was on a sunset path with no upgrade story. We built the migration so the operator could continue rolling new units without re-opening our contract.

The new stack uses Owasys open-Linux gateways with a reproducible image built through alloy-it. The image bundles the acquisition layer, a per-asset telemetry schema, and the OTA agent the operator controls. Everything that runs on the device is source-visible inside the operator’s account.

Telemetry flows over MQTT to a broker the operator hosts, then into the operator’s existing analytics and dispatch tooling. The closed-vendor cloud was not in scope post-migration; the operator’s VPC is the operational home for the data.

Crucially, the new image emits records on the same canonical schema as the legacy units once both can be read in parallel, so dashboards do not break during the rollout. Schema reconciliation happens at the edge, not in 12 layers of cloud transforms.

Audit (weeks 1–3): we mapped every capability of the legacy firmware, protocols, integrations, alerts, OTA channels, and produced a feature parity matrix signed off by the operator's engineering lead before any code was written.

Custom firmware (weeks 4–10): alloy-it produced reproducible builds of the new image. We replicated the matrix line by line and added two capabilities the legacy firmware never had: edge buffering across multi-hour outages and OTA rollback by image hash.

Staged rollout (weeks 11–20): migration in waves, with rollback to the legacy firmware available at every step. Each wave ran in dual-emit for 72 hours so dashboards saw both streams and the operator could compare.

IP transfer (week 21): the operator received the gateway image source, the alloy-it build pipeline, the OTA infrastructure as code, and the runbooks. Our contract ended; their stack didn't.

The headline number, fleet on open hardware, no vendor lock, matters, but two operational changes matter more.

• The operator now ships their own gateway updates. OTA windows are scheduled by their team, not their vendor's roadmap. New device features land in days, not quarters.
• Security finally has artifacts. Reproducible builds, signed images, verifiable supply chain. The security team stopped describing the gateway estate as a black box.

This is the standard migration shape for any operator running closed gateway estates that need to become open without disrupting operations: feature-parity audit first, reproducible image build, dual-emit rollout, IP transfer at the end. The hardware vendor changes, the operator stays, with the stack they now own.