Inspired by customer requests to extend legacy firmware based on the old nRF5 SDK — or to support new BLE projects on the same stack just to avoid the move to Zephyr — I realized that a clear explanation was badly needed.
Too many teams are still clinging to the familiar, thinking it will save them time or reduce risk. In reality, continuing to invest in the old stack is a decision that brings long-term problems: lack of scalability, missing features, higher technical debt, and future migration pain.
This blog is written to explain what exactly is happening, why Nordic made the transition to the nRF Connect SDK, and why staying behind is ultimately the worse choice for any serious product development.
If you’re planning new BLE products — or upgrading existing ones — you need to understand the new landscape.
nRF5 SDK: Good…
Since 2012, Nordic Semiconductor’s nRF5 SDK has been the foundation for Bluetooth LE product development.
It powered countless products with its rich set of examples, libraries, and drivers.
At its heart was the SoftDevice — a closed, precompiled Bluetooth stack combining Controller and Host — offering developers a stable and battle-tested environment.
The SDK provided native bare-metal development without forcing an RTOS, though examples for FreeRTOS were offered.
It supported nRF51 and nRF52 series SoCs and, over time, expanded with separate SDKs for Thread, Zigbee, Bluetooth Mesh, and even HomeKit.
It was a true success story.
But as product requirements evolved, cracks in the architecture began to show.
…and bad
While the nRF5 SDK enabled thousands of successful products and built Nordic’s strong reputation in Bluetooth LE development, it also presented challenges — especially as product requirements grew more complex.
One key limitation was the SoftDevice model.
Although highly stable, it functioned as a closed black box, controlling the Bluetooth Controller and Host layers internally.
When issues such as timing glitches or subtle memory problems occurred, developers often had no way to diagnose the root cause beyond vague error codes.
Debugging stack internals without Nordic’s assistance was virtually impossible.
Interrupt handling further complicated development.
The SoftDevice enforced strict interrupt priority requirements, and any violation could silently break application behavior.
This led to subtle bugs that were notoriously difficult to isolate, often turning into long and painful debugging sessions.
Memory management was another frequent concern.
Rather than dynamic scaling, developers had to manually allocate memory for GATT tables, radio buffers, and connection resources.
Incorrect sizing could cause unpredictable runtime failures, often without clear warnings.
Perhaps the biggest frustration was (let’s call it) merging multiple examples.
Each feature or protocol came with its own heavily customized sdk_config.h file, creating a web of hidden interdependencies between modules.
When developers tried to combine different features — for example, adding DFU to a BLE peripheral — conflicts, duplicated drivers, and broken configurations were common.
Resolving these issues often required manually digging through hundreds of defines and understanding undocumented dependencies buried deep in the libraries.
Multi-protocol support, while present, was also difficult to scale.
Combining BLE with Thread or Zigbee demanded precise radio scheduling and timeslot management.
Even with official examples, real-world applications often surfaced complex timing issues and resource conflicts that were not easy to solve within the SDK’s architectural model.
If you browse developer discussions on Nordic’s DevZone community forums, these pain points are a recurring theme.
Many teams reported spending considerable time working around these challenges, especially as they attempted to build larger, multi-functional products.
In the end, while the nRF5 SDK was a powerful and advance platform for its time, it was fundamentally designed around simpler BLE devices. As the industry evolved toward multi-protocol, RTOS-driven, secure IoT solutions, it became increasingly clear that a new foundation was necessary.
nRF Connect SDK
Recognizing these challenges, Nordic Semiconductor made a bold move in 2018 – they launched the nRF Connect SDK (NCS) — a new software platform built on the Zephyr RTOS. Keep in mind that Zephyr was publicly announced in the February of 2016. Nordic started seriously investing into Zephyr around 2017-2018, and by 2018, the first public releases of nRF Connect SDK (NCS) based on Zephyr appeared, targeting new hardware like nRF9160 and later nRF5340.
NCS provides a modular, scalable foundation supporting BLE, Bluetooth Mesh, Thread, Zigbee, Matter, Wi-Fi, LTE-M/NB-IoT, GPS, and proprietary 2.4 GHz applications — all from a single unified SDK.
- No more separate SDKs per protocol.
- No more bolted-on multi-protocol hacks.
- One codebase for all devices, all features.
Bluetooth LE architecture in NCS is also completely different. The Host layer is Zephyr’s Bluetooth Host — open, flexible, and community-driven.
Developers can even swap the Host or Controller components as needed for maximum flexibility. Zephyr provides an open-source BLE Controller (Link Layer “LL”) that communicates directly with the radio hardware using the vendor’s HAL.
By avoiding vendor-specific proprietary stacks, this architecture improves portability across different MCUs supported within the Zephyr ecosystem.Instead of battling enormous sdk_config.h files, configuration now uses DeviceTree and Kconfig systems. West and CMake manage projects and dependencies cleanly.
Firmware, stacks, and drivers are all built and versioned together.
It’s a very different world — and a necessary one for today’s complex wireless designs.
Why Nordic Moved to nRF Connect SDK
Several factors drove Nordic’s shift.
First, the new hardware platforms — like the nRF91 cellular series and nRF53 dual-core devices — simply required full RTOS capabilities to operate efficiently.
Bare-metal architectures would have led to unmanageable complexity.
Second, developers demanded faster feature delivery, tighter security, and better multi-protocol coexistence. The old model of isolated SDKs could no longer keep up.
Finally, integrating into the open-source community — especially through Zephyr — meant faster innovation, faster bug fixing, and the ability to collaborate with a much larger development ecosystem.
By moving to nRF Connect SDK, Nordic ensured its customers could build scalable, future-proof, multi-protocol devices without being trapped by legacy constraints.
As of 2025, the picture is clear:
- nRF5 SDK is frozen at version 17.1.0, receiving only critical bug and security patches.
- No new Bluetooth features (Direction Finding, LE Audio) will be added.
- nRF Connect SDK is the only platform actively developed and extended.
New SoC nd nRF54 series are only supported under NCS.
Matter, Wi-Fi 6, Bluetooth LE Audio — all future protocols and standards — are evolving inside NCS.
nRF5 SDK – release notes: https://www.nordicsemi.com/Products/Development-software/nRF5-SDK/Download
Lessons Learned
Our own journey with Zephyr began almost five years ago, when we started working with Nordic’s newly released nRF9160.
At that time, Zephyr was still young, and getting real-world projects off the ground was difficult.
The tooling, the documentation, and the learning curve all presented serious challenges.
But today, after delivering more than twenty Zephyr-based projects across different technologies and industries, we’re glad we entered that arena early.
It allowed us to build deep experience, understand the architecture properly, and help many others — whether through consulting, migrations, or new product designs.
Transitioning from the nRF5 SDK to the nRF Connect SDK is not a small step.
It’s a commitment to building modern, scalable, future-proof wireless products. For teams still relying on legacy software, now is the time to start planning your next move. The earlier you invest in this transition, the faster and stronger your development capabilities will become.
If you’re starting a new product, begin directly with the nRF Connect SDK.
If you’re maintaining an existing nRF5 SDK product, it’s acceptable to stay short-term, especially for stable designs on the nRF52832 or nRF52840. However, it’s important to plan migration early to avoid last-minute crises when new features or certifications become necessary — particularly as Nordic’s newer nRF54 series is already positioned to gradually replace the nRF52 family. Since nRF54 is only supported through the nRF Connect SDK, sticking to legacy tools could limit your ability to adopt new hardware when the market shifts.
If you’re planning a migration, allocate serious engineering resources.
This is a true re-architecture effort — not a simple port.
