Operators already have large, stable brownfield broadband fleets in customer homes. These devices are installed, provisioned, remotely managed, and part of live networks. Replacing them only to adopt a new platform is costly and operationally risky. A secure field migration path can reduce that barrier by moving deployed OpenWRT gateways toward RDK-B capabilities while preserving the device state needed for service continuity.

The central design point is simple: the router must not lose the information that makes it manageable and usable on Day 0 after migration. Device identity, WAN and LAN configuration, Wi-Fi settings, firewall and NAT rules, DHCP and DNS behavior, ACS ownership, credentials, certificates, application state, and rollback metadata all have to survive the transition.

Migration Goals

• Preserve field identity: retain serial, provisioning data, certificates, keys, and operator ownership.
• Preserve service configuration: carry forward router and application configuration instead of forcing manual re-provisioning.
• Control risk: separate download, verification, boot, health validation, and final commit into distinct stages.
• Keep the operator in control: use ACS and USP/TR-369 telemetry so the fleet manager can observe, approve, stop, or roll back migration.
• Enable RDK-B adoption: make existing hardware useful for RDK-B evaluation and phased deployment when the platform and BSP support it.

What success looks like

A successful migration is not merely an RDK-B image booting once. It is an RDK-B boot that restores WAN, LAN, Wi-Fi, management connectivity, telemetry, required applications, and health reporting. The operator must have enough evidence to decide whether the device should remain on the new bank or automatically return to the previous working image.

Core principle

• Downloaded does not mean verified
• Verified does not mean booted
• Booted does not mean healthy
• Healthy does not mean committed
• Each transition needs explicit evidence

Migration Strategy And Control Plane

The proposed strategy uses a staged flow. The first stage prepares the currently deployed OpenWRT environment with the checks and tooling required for a safe transition. The second stage downloads and verifies the target payload. The third stage persists the required state outside the replaceable root file system. The fourth stage switches boot to RDK-B. The final stages apply configuration, validate runtime health, start application containers, and either commit or roll back.

The diagram shows three control-plane inputs. ACS coordinates migration initialization, authorization, rollout policy, and rollback. The file server provides controlled payload delivery. USP/TR-369 reports event-driven migration state so the operator can see progress and failure reasons without waiting for periodic polling. It also deals with deployment of containerized applications.

Figure 1. End-to-end migration strategy from deployed OpenWRT to RDK-B with ACS, files, checks, applications, telemetry, and rollback

New OpenWRT

Install or verify a migration-capable OpenWRT image with the required tools, board adapters, ACS integration hooks, storage access, and boot-control utilities.

It must contain the necessary scripts that can:

• initiate the migration,
• persist all required settings on a shared partition,
• switch the boot partition to the one containing the RDK-B image.

Pre-Migration Checks

Before accepting a migration, the device performs compatibility and readiness checks.

These checks prevent:

• unauthorized upgrades,
• upgrades to hardware with insufficient capabilities,
• incomplete upgrades.

They also provide the operator with early information about failure reasons before the router even interacts with the boot chain.

• Hardware specifications and board capabilities are compatible.
• The current router software version and migration tool version are supported.
• A/B partitioning, boot control, and rollback metadata are present.
• Sufficient free space is available for payloads, configuration snapshots, and logs.
• Network connectivity to the ACS and file server is stable enough for staged downloads.

Secure download

Download signed image metadata and payload from the approved file server, preferably over authenticated TLS. Verify source authorization, manifest signature, image hash, size, version, and anti-rollback constraints before writing the inactive bank.

Configuration Preservation and TR-181 Mapping

Configuration migration is the highest-risk part of the process. A generic RDK-B image cannot be preconfigured for every deployed router because each live unit has device-specific WAN credentials, VLAN or PPPoE parameters, Wi-Fi SSIDs and keys, LAN addressing, firewall behavior, remote-management identity, ACS credentials, certificates, and application state. Losing any of these can turn a successful image boot into a field outage.

The OpenWRT side must collect state from UCI configuration, files, service databases, certificates, provisioning identifiers, and application-specific storage. That state should be normalized into an explicit migration package with versioning, checksums, source metadata, and target RDK-B mapping rules. The package must live in a partition that is not erased when the root file system changes.

Table 1. Mapping model

Router adapters and ACS templates reduce per-device logic. The adapter knows how to interpret the source platform and hardware variant. The ACS template knows what RDK-B parameters must be applied for that operator profile. This separation lets the same migration framework support multiple board revisions, operators, and RDK-B versions without turning the migration script into a monolithic custom image.

Operational rule: The first RDK-B boot must restore management access quickly. Once ACS and USP/TR-369 are healthy, the operator can reconcile the remaining configuration remotely.

Boot switch

Set the next boot target to the candidate RDK-B bank, retain the previous working bank, initialize retry counters, and record rollback reason fields for post-mortem analysis.

Secure boot

The partition model should separate immutable boot components, replaceable operating-system banks, and persistent data. A/B banks allow the device to try a new RDK-B image while retaining a known-good OpenWRT or previous image. Rollback can then be based on boot counters, validation results, ACS reachability, and operator policy rather than on a single boot success.

Figure 2. A/B partition model with bootloader, Kernel A/B, Root FS A/B, and persistent data partition

Table 2. Secure boot chain

Apply configurations

Configuration apply starts from the persisted package, not from assumptions baked into the image. The migration adapter reads OpenWRT UCI state, service files, application databases, certificates, and provisioning identifiers, then maps them to target RDK-B parameters and service configuration. The minimum goal is to restore management access quickly; the complete goal is service continuity for WAN, LAN, Wi-Fi, firewall/NAT, DNS/DHCP, ACS ownership, USP identity, and required applications.

Sanity checks

Once RDK-B is running certain health or sanity checks are needed to confirm critical processes are running, no blocking failed units exist, ACS/USP are reachable, and connectivity checks passed.

• OS release and platform profile match the expected migration target
• Critical CCSP processes are running and systemd has no blocking failed units
• WAN interface, default route, DNS, and Internet connectivity are operational
• LAN bridge, DHCP, firewall, and NAT behavior are sane
• TR-069 and TR-369/USP sessions can report state to the operator
• CCSP logs exist and contain enough context for remote troubleshooting
• Wi-Fi backend or OneWifi validation confirms configured radios and SSIDs

Installing containerized applications

Applications should be migrated as managed units rather than copied blindly. The flow is: build an application list, securely download required artifacts, create the container execution unit, mount preserved configuration, run health checks, and report application-specific telemetry.

Dobby provides a container-management layer for RDK environments. In this migration pattern it acts as the boundary between the base RDK-B platform and additional operator or product applications. The base system stays clean; application binaries, writable data, and configuration can be mounted explicitly from controlled locations. Dobby also gives lifecycle control so an application can be started, stopped, restarted, and diagnosed independently from the base boot process.

Table 3. Phases of containerized application migration

This model also supports app-specific validations. A VPN service, smart-home service, or telemetry agent can each expose different success criteria while still fitting into the same migration framework.

Runtime health

Once RDK-B is running certain health or sanity checks are needed to confirm critical processes are running, no blocking failed units exist, ACS/USP are reachable, and connectivity checks passed.

Rollback must remain available until the router proves that it is usable and manageable. For fleets, ACS can also apply rollout policy based on aggregate success rates. For example, if a sample group shows too many failures, the operator can stop the rollout and roll back affected devices before continuing with a larger population.

Proof-of-Concept Environment

The summit work is presented as a proof of concept and migration pattern, not as a claim that every deployed router can be migrated without vendor participation. Production migration depends on BSP availability, signed images, bootloader behavior, board partitioning, Wi-Fi and switch drivers, operator policy, and access to representative hardware.

Figure 3. Environment used for the migration pattern

Lessons Learned

• TR-181 mapping must be is not universal: it depends on RDK-B version, board capabilities and used ACS templates.
• Telemetry must be robust: the operator needs event-driven state, not just periodic polling, especially during failure handling.
• Fleet policy matters: ACS-side rollout thresholds can prevent a local issue from becoming a fleet incident.
• Applications need their own validation: each migrated app requires specific probes and rollback impact assessment.

Value For RDK Community

A reusable migration pattern can shorten RDK-B adoption cycles for brownfield fleets. The immediate value is a repeatable automated strategy, safer rollback, and clearer validation. The longer-term value is shared guidance for operators, OEMs, SoC vendors, and system integrators around secure boot, A/B partitioning, configuration mapping, telemetry, and app migration.

Application specific telemetry and rollback that considers application health checks can be applied outside of migration - in updates between different RDK-B versions or during standard operation.

Figure 4. Value for RDK Community

Proposed next step

Create an RDK community working group focused on OpenWRT-to-RDK-B migration patterns for existing (brownfield) deployments, with particular emphasis on:

• Secure boot
• Persistent device-state preservation
• TR-181 mapping
• Validation
• Telemetry
• Rollback mechanisms

Conclusion

The practical conclusion is that brownfield migration is feasible only when treated as a controlled lifecycle operation. The router must preserve identity, prove health, expose evidence, and keep a safe path back. When those rules are followed, existing devices can become a bridge toward RDK-B adoption instead of a barrier to it.