chsh-sk-ncs-migrate

First establish a working baseline build and hardware smoke test on the current version, then bump the sdk-nrf revision in west.yml one release at a time. For each hop, apply the official migration guide changes, rebuild with west, flash, and verify against the baseline UART log.

Multi-hop migration through each intermediate release is the recommended default because it isolates debugging to one version's changes at a time. A direct jump is only offered when the user explicitly accepts the higher risk.

New NCS releases rename Kconfig options, move headers, change API signatures, and alter board target syntax such as the HWMv2 board/soc/core format. The per-version migration guide and release notes list each required change to apply.

No, the workflow requires flashing and a functional smoke test on hardware after every hop. A clean build alone is not accepted as proof of migration because behavioral regressions only appear at runtime.

The process stops and asks the user how to proceed rather than guessing at API semantics. This applies to removed functions without replacements, custom patches that no longer apply, and third-party modules pinned to old SHAs.

Sources older than v2.6 involve major build system and Kconfig hierarchy changes, so expect significant work. For pre-v2.5 sources, a rewrite on the target version may be faster, and that trade-off is raised with the user up front.