Our Bluetooth product runs on software Nordic no longer develops
Products still on the nRF5 SDK: an honest assessment of what the move to nRF Connect SDK / Zephyr involves, then fixed-price two-week sprints to do it, including the over-the-air update path for units already in the field. Assessment AUD 6,000; sprints AUD 15,000.
Where you are
Your product uses a Nordic nRF52 and was built on the nRF5 SDK. It works. But Nordic put the nRF5 SDK into maintenance mode: it stays alive for nRF51 and nRF52 with maintenance releases only and no new features beyond Bluetooth LE 5. Everything else — the nRF53 and nRF54 parts, new nRF52 features, the current Bluetooth stacks, and Nordic’s active development and long-term support — lives in the nRF Connect SDK (NCS) on Zephyr. If your product has a future, the port is coming; the only questions are when, and how much of your existing code survives.
Nobody can honestly quote that port without reading the code. So it starts with a week inside it.
Step 1 — the assessment (diagnostic week, AUD 6,000)
A written migration plan:
- What you have: modules, drivers, SoftDevice dependencies, custom BLE services, bootloader and DFU scheme, build system, test coverage.
- What maps directly to Zephyr/NCS, what needs rewriting, and what’s dead weight.
- The hard parts named up front — above all whether units already in the field can be updated over the air to the new build, which depends on the bootloader they shipped with. If a fielded version can’t be reached safely, you find that out here, not in sprint 3.
- A sprint-by-sprint plan with acceptance tests per sprint and a fixed price per sprint.
If you stop there, you have a plan any competent Zephyr engineer can execute. If you continue with me and the sprints come to more than AUD 20,000 and start within 90 days, the assessment fee is credited in full — the standard rule on the terms page.
Step 2 — the sprints (AUD 15,000 per two weeks)
Each sprint has a written deliverables list and an acceptance test list agreed before it starts. Typical shape:
| Sprint | Deliverable |
|---|---|
| 1 | NCS project builds in CI for your board; board definition and devicetree; boot, logging, one peripheral end to end |
| 2 | Peripherals and drivers ported; power consumption verified against the old build’s numbers |
| 3 | BLE services and DFU ported; over-the-air update from a fielded nRF5 unit to the NCS build proven on the bench, for each fielded version the assessment found reachable |
| 4 | Hardening, test suite, handover documentation, a recorded walkthrough |
Small products finish in two sprints. Products with custom radio work or a complicated DFU story take four or more; you know from the assessment, not from a surprise.
What you get at the end
A product on Nordic’s supported SDK, building reproducibly in CI, with a test suite, a documented update path from each fielded version the plan found reachable, and a handover your next engineer can pick up.
What’s not included
- New features. The port delivers parity; features are quoted separately once you’re on NCS.
- Hardware changes. If the port reveals a board problem, that’s a diagnostic finding and a separate quote.