CPAR + Steel-Belted RADIUS Combined Migration Playbook for CSPs

• Cisco CPAR handles high-throughput stateless broadband RADIUS authentication; Juniper SBR handles EAP-based Wi-Fi and Voice over Wi-Fi (VoWiFi) sessions. They share integration dependencies – subscriber database, policy server, accounting mediation – that make sequential migration risky and parallel migration complex.
• A single modern AAA platform with native RADIUS, Diameter, and full Extensible Authentication Protocol (EAP) stack support can replace both systems in one program, eliminating the compounding risk of dual simultaneous cutover.
• Any combined migration must begin with a complete interface inventory and VSA audit – before vendor selection, not after.
• Alepo has migrated 50+ operators from legacy AAA to a modern platform, with 100+ operator deployments globally, validated at 36,000+ authentication transactions per second (TPS) at sub-millisecond latency.
• A replacement platform designed for 99.999% uptime delivers fewer than six minutes of unplanned downtime per year – the benchmark figure for internal SLA specifications.

Introduction

A Cisco CPAR migration is hard enough as a standalone program and choosing the wrong replacement platform can cost a Communications Service Provider (CSP) months of rework and a repeated procurement cycle. Cisco CPAR (Carrier-grade Packet AAA Router) carries the broadband authentication workload; when Juniper Steel-Belted RADIUS (SBR) runs on the same network and both systems are heading toward end of life (EOL), the project scope doesn’t double it compounds. Two platforms, each with distinct protocol profiles, session populations, and Vendor-Specific Attribute (VSA) dictionaries, but sharing the same subscriber database, the same policy server, and the same accounting mediation pipeline. A change to any shared component during one migration can break assumptions the second migration is built on.

Most Communications Service Providers (CSPs) arrived at this dual-system architecture through years of layered network decisions rather than deliberate design. CPAR absorbed broadband subscriber authentication workloads when carrier-grade RADIUS throughput was the priority. SBR took on EAP-based Wi-Fi authentication and Wi-Fi calling as offload requirements grew. The protocols overlap both run RADIUS, as defined in RFC 2865 but the operational footprints are different enough that the two systems cannot be treated as one migration project, and treating them as two independent projects carries its own set of cascading risks.

This guide covers what the combined EOL problem looks like at the network level, how a unified replacement strategy reduces risk versus two sequential programs, and what a practical step-by-step playbook looks like for a CSP managing dual-system cutover. It also covers vendor evaluation criteria specific to combined migration including what Alepo delivers in this use case.

The Dual EOL Problem: CPAR and Steel-Belted RADIUS

Most CSPs running both CPAR and SBR didn’t architect that topology from scratch. The combination emerged from network decisions made across different eras: CPAR was deployed when broadband subscriber growth demanded carrier-grade RADIUS throughput for Broadband Remote Access Server (BRAS) and Broadband Network Gateway (BNG) authentication. SBR entered the picture when Wi-Fi offload requirements grew and EAP-based authentication – EAP-SIM, EAP-AKA, EAP-TLS – required an AAA server capable of managing multi-round-trip authentication conversations at carrier scale.

Cisco and Juniper have both reduced active development and support investment in these platforms. For CPAR, Cisco has published end-of-sale and end-of-life milestones for major software versions. SBR has followed a similar trajectory. An operator running either platform past its end-of-support date has a network authentication system that will receive no security patches, no bug fixes, and no vendor escalation when incidents occur.

That is the single-system EOL problem. The dual-system problem is that both platforms share integration dependencies and managing those dependencies across two migration programs, without a coordinated strategy, is where most CSPs underestimate the scope of what they have taken on.

How RADIUS Handles Authentication Requests

RADIUS operates on the client-server model defined in RFC 2865. The Network Access Server (NAS) typically a BRAS, BNG, or in 5G networks a Session Management Function (SMF) sends an Access-Request packet to the RADIUS server carrying subscriber credentials and session context. The server validates the request against the subscriber data source and returns an Access-Accept with session attributes (IP assignment, bandwidth policy, service profile, session timer) or an Access-Reject. At carrier scale, this exchange occurs millions of times daily, with peak authentication rates on large broadband networks reaching tens of thousands of requests per second.

CPAR was purpose-built for this workload: stateless high-throughput RADIUS authentication with deterministic per-request latency. A broadband RADIUS authentication is typically a single exchange – one Access-Request, one Access-Accept or Reject, session opens. The per-request complexity is low; the throughput requirement is not. CPAR’s carrier-grade engineering addressed the throughput side. Understanding the actual transactions-per-second (TPS) and VSA profile of the CPAR deployment is step one of any migration assessment, because the replacement system must be validated against those specific numbers- not against synthetic benchmarks run on different hardware.

RADIUS Accounting and Session Tracking

RADIUS Accounting, defined in RFC 2866, produces three message types for every subscriber session: Accounting-Start when the session opens, Accounting-Interim-Update at configurable intervals during the session, and Accounting-Stop when the session terminates. In a network running both CPAR and SBR, both systems generate accounting messages – and they typically feed different downstream targets. CPAR accounting flows to broadband Call Detail Record (CDR) mediation and billing. SBR accounting feeds a separate pipeline for Wi-Fi session records.

The migration risk is accounting gap: any window during cutover when sessions are mid-flight on the legacy system but accounting continuity to the replacement has not been confirmed. Even a short gap creates revenue assurance issues, and in some regulatory environments it constitutes a compliance event. The standard mitigation is a parallel accounting drain: during the migration window, both the legacy and replacement systems send accounting messages for the same sessions to mediation, and a deduplication mechanism at the mediation layer removes the duplicate records. This architecture must be designed and tested before any live traffic migrates – it cannot be a day-of-cutover improvisation.

RADIUS Limitations at Carrier Scale

RFC 2865 was published in 1997 for dial-up authentication. The underlying design – UDP transport, a 32-bit NAS identifier space, an attribute-value pair format requiring extensions for modern subscriber attributes – reflects the network environment it was built for. The extensions exist and work: RFC 6614 adds TLS transport to RADIUS (RadSec), RFC 5176 adds Change-of-Authorization (CoA) for mid-session policy enforcement, and the RADIUS attribute extensions for broadband subscriber management are well-established. But they are all additive layers on an architecture not originally designed for millions of concurrent stateful carrier sessions.

The structural constraint that matters most in a migration context is session state. RADIUS has no native mechanism for distributed session state synchronization. A subscriber’s session state – active attributes, accounting counters, quota tracking – belongs to the AAA server node that authenticated that subscriber. Horizontal scaling requires either session affinity at the load balancer (limiting autoscaling flexibility) or an external session store with replication. Both CPAR and SBR relied on the operator to solve session continuity at the infrastructure level. Modern cloud-native AAA platforms solve it at the architecture layer, using an external distributed session store that decouples session state from the authentication pod that created it. That design is what makes Kubernetes-based horizontal autoscaling viable for stateful AAA workloads at carrier scale. For a detailed treatment of cloud-native AAA architecture, see Alepo’s Cloud-Native AAA Architecture Guide.

Why Dual EOL Multiplies Risk

A single AAA EOL migration is a scoped program: replace vendor A with vendor B, validate protocol compatibility, maintain accounting continuity, confirm policy enforcement parity. The risk is large but bounded. Dual EOL collapses that boundary because CPAR and SBR do not share vendor contracts – but they do share infrastructure: the subscriber management system or HSS/HLR that both systems query for subscriber credentials, the Policy and Charging Rules Function (PCRF) or 5G Policy Control Function (PCF) that sends policy decisions to both via Gx, the billing mediation platform that aggregates accounting records from both, and the IP routing infrastructure that carries RADIUS traffic to both.

A change to any shared component during the CPAR migration workstream – a subscriber database schema update, a CoA routing modification at the PCRF, a CDR format change at mediation – can invalidate assumptions the SBR migration workstream is building on. Running both programs in parallel doubles coordination overhead and introduces the risk of conflicting changes to shared systems. Running them sequentially adds 12–18 months to the overall program timeline and leaves one EOL platform in production while the other is being migrated. Neither option is clean.

Core Concepts and Definitions

Cisco CPAR migration is the process of replacing Cisco’s Carrier-grade Packet AAA Router with a modern AAA platform capable of managing the same subscriber authentication, authorization, and accounting workloads – without service interruption and without loss of accounting records during the transition.

The full lifecycle covers four phases: discovery (mapping all RADIUS clients, VSAs, and session populations); parallel running (both legacy and replacement systems active, with traffic progressively shifted to the new platform under controlled conditions); cutover (final traffic switchover with accounting continuity maintained through a parallel drain architecture); and decommission (legacy platform removal after a defined stability window, with accounting records archived and accessible for the billing team). When SBR is replaced in the same program, the scope expands to include EAP stack migration, VoWiFi authentication parity via the SWm interface, and end-to-end voice session continuity testing before any live Wi-Fi calling traffic moves.

How This Applies to Your Network

The actual impact of dual EOL depends on how tightly CPAR and SBR are integrated with the rest of the network stack. Consider a Tier-2 broadband operator running CPAR for DSL and Fiber-to-the-Home (FTTH) subscriber authentication and SBR for fixed-wireless access and Wi-Fi calling: the CPAR failure domain covers every broadband subscriber – potentially hundreds of thousands of active sessions. The SBR failure domain covers VoWiFi users and enterprise Wi-Fi offload accounts. Both domains share the HSS (Home Subscriber Server) for credential lookup and the PCRF for policy decisions.

If that operator prioritizes CPAR replacement first, they may defer the SBR integration mapping – only to discover during the SBR migration that a configuration change made during the CPAR program modified a shared dependency. These cascading failures are the most common source of dual-EOL program delays. They surface during integration testing, after significant engineering time has already been invested in the second migration workstream.

The prevention mechanism is an integration dependency map completed before either migration begins. That map must cover every interface: Gx for policy, Gy for online charging, SWm for ePDG (Evolved Packet Data Gateway)/VoWiFi (see Alepo AAA for FTTH Networks for broadband-specific integration context), and every API connecting AAA to subscriber management. A risk register for either migration that does not reference this map is incomplete.

Alepo’s Implementation Approach

Alepo’s approach to dual CPAR/SBR environments begins with a pre-migration discovery phase that produces a verified interface inventory: every RADIUS client and its configuration, every VSA in active use and its policy context, every accounting target and its message format requirement, and every policy integration point including CoA routing paths. This inventory is the migration baseline. If the replacement system cannot reproduce every item in that inventory, the migration cannot begin.

Alepo’s platform natively supports RADIUS (RFC 2865, RFC 2866), Diameter (RFC 6733{rel=”nofollow noopener noreferrer”}), CoA (RFC 5176), RadSec (RFC 6614), and the full EAP family – EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA, and EAP-AKA’. A single Alepo deployment covers both the broadband RADIUS workload CPAR handled and the EAP-based Wi-Fi authentication workload SBR handled, without a protocol translation layer between them. Alepo AAA is deployed in multi-protocol carrier environments that handle both broadband RADIUS and EAP-based session authentication from a unified platform.

Unified Migration Strategy

The case for a unified migration – replacing CPAR and SBR with one platform in one program – rests primarily on risk reduction, not cost. A single integration baseline means one dependency map to maintain, one parallel running architecture to operate, and one vendor accountable for the combined migration outcome. There is no risk of CPAR workstream changes breaking SBR workstream assumptions because there is only one workstream.

The upfront requirement is higher: the replacement platform must be evaluated against both systems’ protocol profiles and session populations at the same time. An RFP that tests the replacement only against CPAR’s RADIUS profile will produce a platform selection that fails when SBR’s EAP requirements are tested. The evaluation process is more demanding – but it eliminates the need for a second, separate migration program two years later.

Pre-Migration Assessment Checklist

Complete these steps before engaging any vendor on a combined CPAR/SBR replacement:

1. Inventory all RADIUS clients. Document every NAS, BRAS, BNG, and Wi-Fi controller sending authentication requests to CPAR or SBR – IP address, shared secret rotation schedule, peak TPS under traffic load, and the RADIUS attribute profile expected in Access-Accept responses from each client.
2. Audit all Vendor-Specific Attributes in active use. Extract the full VSA dictionary from both systems and identify which VSAs appear in live subscriber policies versus those configured but inactive. Any active VSA not reproduced in the replacement system causes silent policy enforcement failure – wrong service profiles applied without authentication errors to flag the problem.
3. Document the EAP stack in full. Identify every EAP method SBR is serving (EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA, EAP-AKA’) and the certificate infrastructure and credential store behind each. For EAP-SIM and EAP-AKA, confirm the interface to the HSS/HLR (typically SWx) and the authentication vector exchange mechanism.
4. Map all accounting targets. Identify every downstream system receiving RADIUS accounting from CPAR and SBR: billing mediation, revenue assurance platforms, regulatory reporting systems, and internal network analytics. Confirm the expected message format at each target and whether any existing deduplication logic exists in the mediation layer.
5. Identify all policy integration points. Map every Gx interface to the PCRF or 5G PCF, every Gy interface for online charging, and every CoA routing path. Confirm which policy decisions trigger CoA messages and from which source those messages will be routed during the migration window – this is a frequently overlooked configuration detail that causes policy enforcement failures post-cutover.
6. Define cutover acceptance criteria before vendor selection. Agree internally on what constitutes a successful migration tranche: authentication success rate thresholds, accounting completeness targets, CoA acknowledgment rates, and a maximum acceptable rollback time. These criteria must be written before the vendor conversation begins so that vendor proposals can be evaluated against defined requirements.

Step-by-Step Migration Process

1. Deploy the replacement platform in shadow mode. Install the new system in the production network with no live traffic. Configure RADIUS clients to send authentication requests to both legacy and replacement systems simultaneously; the replacement processes requests and produces responses internally, but does not return responses to the NAS. This enables parity validation without any service impact.
2. Validate protocol parity against live traffic. Run shadow traffic through the replacement for a minimum of 48 hours and compare authentication decisions, accounting messages, and CoA behavior against CPAR and SBR outputs for the same inputs. Resolve every divergence before proceeding. Document the resolution for each divergence – unexplained differences that are not fully understood are migration risks.
3. Migrate non-critical subscriber segments first. Shift authentication for the lowest-risk subscriber group – test accounts, internal users, or a geographically isolated NAS – to the replacement system. Monitor authentication rates, accounting completeness, and CoA delivery for 72 hours before expanding the scope of migration.
4. Progress CPAR workloads by NAS or subscriber group. Shift broadband authentication in defined tranches. Each tranche must complete 72 hours of stable operation before the next tranche is shifted. Maintain a tested rollback procedure for each tranche – a rollback that has not been executed in a staging environment is not a rollback procedure.
5. Migrate SBR workloads after wireline stabilization. EAP-based Wi-Fi authentication should move only after the broadband RADIUS workload is fully stable on the replacement platform. Migrate EAP-TLS and EAP-AKA workloads before VoWiFi via SWm – voice sessions traversing the SWm interface cannot be interrupted mid-call, and migrating them last minimizes blast radius if an issue surfaces.
6. Decommission legacy systems after the stability window. Run the replacement as sole authentication authority for a defined period – minimum 30 days – before taking CPAR and SBR offline. Retain all legacy accounting logs until at least two billing cycles close cleanly on the new platform.

Avoiding Common Migration Pitfalls

• Inactive VSAs in archived subscriber configurations. The VSA audit must cover not just currently active subscriber policies but also recently deactivated profiles that may be reactivated by customer requests or reactivation workflows after migration. Deactivated VSAs missing from the replacement system’s dictionary can surface as errors weeks after migration appears complete.
• Accounting message format mismatches at target systems. Different billing mediation platforms expect RADIUS accounting attributes in specific formats and field orderings. Validate accounting message format compatibility at each downstream target during the parallel drain phase – not during live traffic migration.
• EAP state machine differences between vendors. Two AAA platforms can both support EAP-TLS and still produce different behavior on multi-round-trip EAP conversations depending on implementation details. Test EAP authentication end-to-end against real client devices – not RADIUS simulation tools – before any live Wi-Fi traffic is migrated. This is the most common source of post-migration Wi-Fi authentication failures.
• CoA routing gaps during the transition window. If the PCRF sends a CoA message to the legacy AAA address after a subscriber’s session has moved to the replacement platform, the CoA is silently dropped and policy enforcement fails for that session. CoA routing cutover must be an explicit, documented step in the migration plan – not an assumption.
• Accounting message storms at large tranche cutover. When a large subscriber segment is migrated simultaneously, the replacement system receives a burst of Accounting-Start messages for every active session in the tranche. Validate the replacement system’s peak accounting processing capacity before scheduling large tranches, not after.

Step-by-Step Dual Migration Playbook

The assessment and strategy sections establish the baseline and approach. This playbook translates those into a governance structure for the live migration program. It is a template that each operator must adapt to their specific network topology, but the gate structure applies universally: no phase begins until the prior phase passes its acceptance criteria.

Pre-Migration Gate Checks

Before any live traffic migrates to the replacement platform, these items must be complete and signed off:

• Interface inventory confirmed by network operations. Every RADIUS client, VSA, EAP method, accounting target, and policy integration point documented and independently confirmed as accurate by the operator’s network engineering team – not only by the vendor.
• Protocol parity test signed off. Replacement system has processed a minimum of 48 hours of shadow traffic and produced authentication decisions, accounting messages, and CoA behavior matching the legacy systems for identical inputs. All divergences investigated, resolved, and documented.
• Rollback procedure executed in staging. For the first migration tranche at minimum, the rollback procedure has been executed end-to-end in a staging environment and confirmed to restore the legacy system as the active authentication source within the maximum acceptable rollback time.
• Accounting continuity mechanism active and tested. Parallel accounting drain is live. Billing mediation confirms it is receiving and correctly deduplicating records from both legacy and replacement systems. The billing team has reviewed a sample accounting record set and confirmed format compatibility.
• Dual-workstream change control process in place. Any proposed change to a shared infrastructure component — subscriber database, policy server, HSS/HLR, billing mediation – is reviewed for impact on both CPAR and SBR migration workstreams before change control board approval. This process must be documented and acknowledged by the change control board, not assumed.
• NOC training complete. Network Operations Center (NOC) staff are trained on the replacement platform’s day-to-day procedures: authentication incident handling, accounting alarm response, CoA troubleshooting, and escalation paths. Training completion is a gate, not a parallel track.

Migration Phase Timeline

Phase	Milestone	Minimum Duration
Day 0	Replacement in shadow mode; no live traffic	—
Weeks 1–2	Shadow parity validation complete; all divergences resolved; signed off	2 weeks
Weeks 3–4	Non-critical segment live; accounting continuity confirmed at mediation	72 hrs monitoring per tranche
Month 2	CPAR wireline workload migrated NAS-by-NAS; 72-hr stability per tranche	4–6 weeks
Month 3	SBR EAP/Wi-Fi workloads migrated; VoWiFi via SWm migrated last	3–4 weeks
Month 4	Stability window — full load on replacement; CPAR and SBR in warm standby	4 weeks minimum
Month 5	Legacy decommission after second clean billing cycle	1–2 weeks

Avoiding Common Migration Pitfalls at the Program Level

• Configuration drift between shadow and live phases. The replacement system configuration that passed parity testing must be version-controlled from sign-off forward. Any subsequent configuration change – even a hotfix – must go through a re-validation step before live traffic proceeds. Configuration drift between shadow and live phases is the most common cause of post-cutover authentication failures that cannot be traced during incident response.
• VoWiFi voice session continuity at SWm cutover. Voice sessions traversing the SWm interface (ePDG to AAA) cannot be interrupted mid-call without a call drop event. Schedule VoWiFi authentication cutover during the lowest available call volume window, with a tested fast-rollback mechanism that can restore SBR as the SWm authentication source within minutes – not hours.
• Billing cycle alignment for decommission gate. Time the legacy decommission decision to follow the close of at least two clean billing cycles on the replacement platform. One billing cycle is the minimum; two gives the revenue assurance team confidence across different traffic patterns and subscriber activity peaks. A decommission decision made the week after cutover, before a billing cycle has closed, is premature regardless of how the migration appears to have gone.

Vendor Selection for Combined Migration

The vendor selection question for a combined CPAR/SBR replacement differs from a standard AAA procurement. A standard question is: “Can this platform authenticate our subscribers at carrier scale?” The combined migration question is: “Can this platform replace two distinct AAA systems – different EAP profiles, different VSA dictionaries, different accounting integrations – in a single program, and be accountable for the combined migration outcome?”

Most commercial AAA vendors can answer the first question. Fewer can answer the second with reference deployments to support it.

Vendor Evaluation Criteria for Combined Migration

Evaluate candidates against all of the following before shortlisting:

1. Reference deployments that replaced both wireline RADIUS and EAP-based Wi-Fi authentication on the same platform. Ask for a specific reference where the vendor replaced both workloads in a single program. If no such reference exists, the vendor has not solved the combined migration problem in production – they are proposing to solve it for the first time at your network’s expense.
2. VSA migration tooling and methodology. Ask the vendor to walk through the specific process for migrating a custom VSA dictionary. The answer should name a tool or scripted method, describe the validation methodology, specify the time required for a VSA dictionary of a given size, and describe the escalation procedure when an undocumented VSA is discovered post-cutover.
3. Shadow mode in the production environment. The replacement must support shadow running against live CPAR and SBR traffic without requiring changes to existing RADIUS client configurations. If enabling shadow mode requires reconfiguring live NAS equipment, it is an incomplete parallel running capability – the shadow mode itself introduces migration risk.
4. Tested authentication throughput with documented configuration. Require peak TPS figures with the complete test configuration documented: hardware or container pod count, external session store technology, concurrent session load during the test, and network topology. Alepo’s platform has been validated at 36,000+ authentication transactions per second at sub-millisecond latency under production deployment conditions. Demand equivalent documentation from any vendor under evaluation.
5. Specific accounting continuity mechanism. The vendor’s answer to accounting continuity during cutover should describe a specific architecture – parallel drain, mediation-layer deduplication, session-level handoff – not a general assurance. Ask whether this mechanism has been delivered in a prior migration engagement and whether the reference can be contacted.
6. Migration-specific post-cutover support SLA. Define what engineering support the vendor provides for the first 90 days post-cutover as part of the migration engagement – distinct from ongoing support contract terms. Response time for authentication failure incidents, availability of the migration engineering team for configuration issues, and escalation paths for production problems must be in writing before contract execution.

Protocol and Integration Requirements

Confirm native support – without a third-party integration shim – for each of the following before qualifying any vendor:

• RADIUS authentication and accounting (RFC 2865, RFC 2866)
• RADIUS Change of Authorization (RFC 5176)
• RadSec — RADIUS over TLS (RFC 6614)
• Diameter base protocol (RFC 6733)
• Full EAP family: EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA, EAP-AKA’
• Gx interface (3GPP TS 29.212) for PCRF/PCF policy integration
• SWm interface for VoWiFi/ePDG integration (3GPP TS 29.273)
• Gy/Gz for online and offline charging integration

A platform missing any of these natively requires an integration shim – additional complexity, additional failure surface, and a vendor who cannot own the complete migration outcome when the shim causes an issue.

Red Flags in Vendor Responses

Disqualify vendors who:

• Cannot name a reference deployment where both a wireline RADIUS system and an EAP-based Wi-Fi AAA system were replaced on the same platform in a single program.
• Describe the VSA migration process as “straightforward” without naming a specific tool or method.
• Provide authentication throughput figures without a documented test configuration – hardware, pod count, session store technology, and concurrent session load.
• Require changes to existing RADIUS client configurations to enable shadow running mode.
• Respond to post-cutover support questions with standard support contract language rather than migration-engagement-specific SLA terms.

Alepo as a Single Replacement for Both Systems

Alepo’s carrier-grade AAA platform is deployed across 100+ operator networks globally, spanning North America, Europe, the Middle East, LATAM, and Asia-Pacific. In dual CPAR/SBR environments specifically, Alepo provides a single platform that handles both the broadband RADIUS authentication workload CPAR covered and the EAP-based authentication workload SBR covered – on the same external session store, under the same policy framework, with unified accounting output. For a full overview of the AAA platform capabilities, see Alepo’s AAA Server solution page.

The operational case for consolidation is direct. A single Alepo deployment with a unified subscriber session store means CoA messages from the PCRF reach one system. Accounting records feed one pipeline to mediation. The operations team manages one platform’s configuration, monitoring, and incident workflow. The migration risk profile is one integration baseline and one cutover discipline rather than two.

Alepo has completed migrations from legacy AAA environments – including CPAR-era systems – for 50+ operators, drawing on 20+ years of carrier-grade AAA deployment experience. Authentication throughput is validated at 36,000+ transactions per second at sub-millisecond latency, confirmed by Alepo’s engineering team against production deployment conditions. The platform’s active-active redundancy architecture is designed for 99.999% uptime, which translates to fewer than six minutes of unplanned downtime per year – the figure to specify in the internal SLA for the replacement system.

For cloud-native deployments, Alepo AAA runs in production on Kubernetes using StatefulSets and an external session store that decouples session state from individual authentication pods, enabling horizontal autoscaling without session affinity constraints at carrier scale, across public-cloud, private-cloud, and on-premises environments.

Platform Capabilities Replacing CPAR

• RADIUS authentication (RFC 2865) and accounting (RFC 2866) at carrier scale – validated to 36,000+ TPS in production deployment conditions
• VSA migration tooling with full dictionary import, policy context validation, and post-migration gap verification
• CoA support (RFC 5176) with tested policy enforcement from PCRF/PCF, including CoA routing cutover as an explicit migration step
• Diameter protocol support (RFC 6733) covering S6a, S6b, SWx, SWm, Gx, Gy, and Sh interfaces natively
• Active-active geo-redundant high availability, designed for 99.999% uptime across regions
• External distributed session store – session state decoupled from authentication pods, enabling horizontal autoscaling without session affinity

Platform Capabilities Replacing SBR

• Full EAP stack natively: EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA, EAP-AKA’ – no separate EAP server required
• SWm interface support for VoWiFi and ePDG integration per 3GPP TS 29.273 – same platform authentication path for both wireline and voice sessions
• SWx interface (3GPP TS 29.273) for HSS subscriber data lookup during EAP-SIM/AKA authentication
• Certificate infrastructure integration for EAP-TLS certificate validation against operator Public Key Infrastructure (PKI)
• Wi-Fi offload authentication supporting Hotspot 2.0 and Passpoint for carrier-grade automatic client authentication
• Multi-market VoWiFi authentication over SWm → SWx → S6b at carrier scale

Migration Methodology

Alepo’s migration engagement follows the parallel running model detailed in the Step-by-Step Dual Migration Playbook section above. Deliverables from an Alepo engagement include: a complete interface inventory and VSA migration report produced during discovery; a protocol parity test report with documented resolution of all divergences; a tranche-by-tranche cutover plan with a tested rollback procedure for each tranche; accounting continuity validation reports for each billing cycle during migration; and post-cutover monitoring through the decommission gate. The Alepo AI Agent for AAA – a real-time security and operations control plane built into the AAA stack – also provides RADIUS and Diameter log analysis, authentication anomaly detection, and operational diagnostics that reduce mean-time-to-diagnose for NOC teams during and after migration.

Migration Timeline and Resources

Dual CPAR/SBR migration timelines depend on subscriber population size, RADIUS client count, EAP deployment complexity, and the operator’s change control process. The estimates below reflect Alepo’s migration program experience with Tier-2 and Tier-3 operators. Tier-1 operators with more complex integration topologies should add 30–60 days to the discovery and CPAR workload migration phases.

Representative Migration Timeline

Phase	Key Activities	Duration
Discovery	RADIUS client inventory, VSA audit, EAP stack documentation, accounting target mapping, policy integration map	3–4 weeks
Parallel Deployment	Replacement system installed in production, shadow mode enabled, internal baseline testing	2–3 weeks
Parity Validation	Shadow running against live traffic, divergence resolution and sign-off	1–2 weeks
Non-Critical Segment Migration	First tranche live, 72-hour monitoring, accounting continuity confirmed at mediation	2 weeks
CPAR Workload Migration	NAS-by-NAS tranche migration, 72-hour stability per tranche, rollback available throughout	4–6 weeks
SBR Workload Migration	EAP-TLS/AKA migration, Wi-Fi offload, VoWiFi via SWm migrated last	3–4 weeks
Stability Window	Full load on replacement; CPAR and SBR in warm standby	4 weeks minimum
Legacy Decommission	After second clean billing cycle; legacy platforms taken offline; logs archived	1–2 weeks
Total		~5–6 months

Internal Resources Required

Operators consistently underestimate the internal resource commitment required for AAA migration. The vendor provides the platform and methodology; the operator provides the operational context that no vendor has access to.

• Network engineering time in discovery. VSA extraction, RADIUS client documentation, and integration dependency mapping require sustained network engineering involvement for 2–4 weeks. This cannot be outsourced to the vendor – only the operator’s engineering team has visibility into undocumented or environment-specific configurations.
• Billing and mediation team ownership of accounting continuity. Accounting continuity validation is not a technical checkbox – it requires the billing team to confirm CDR format compatibility, actively reconcile duplicate accounting during parallel drain, and sign off on each billing cycle during migration. Budget this as a recurring responsibility throughout the program, not a one-time review.
• NOC training before live traffic moves. Operations staff must be trained and demonstrably competent on the replacement platform before live traffic is on it. Training during active migration amplifies incident risk – an operator who has never seen the platform’s alerting interface is not equipped to respond when an authentication alarm fires at 02:00.
• Change control board capacity for each tranche. Every migration tranche is a formal change control event. Budget for the review, approval, and post-change monitoring process in the migration timeline. Treating change control as administrative overhead that runs in parallel with migration work is a program governance risk.
• Dedicated resource for VoWiFi testing. Wi-Fi calling migration requires end-to-end call testing with live handsets, confirming voice session continuity and SWm interface behavior under realistic load. This requires coordination with the Wi-Fi, IMS (IP Multimedia Subsystem), and ePDG teams. Confirm testing resource availability and schedule it before the SBR workload migration phase begins – not during it.

Reducing Migration Timeline Risk

• Start discovery before vendor selection. The interface inventory and VSA audit are network documentation tasks that do not require a vendor to be chosen. Beginning discovery 4–6 weeks ahead of the vendor decision compresses the overall program timeline and gives vendor candidates accurate scope information for their migration proposals – which produces better-quality proposals.
• Run parity validation against live production traffic, not staging. Shadow running in a staging environment misses edge cases that only appear in production: unusual VSA combinations, infrequent EAP method requests, off-hours accounting burst patterns. A vendor who cannot support shadow mode in the production environment is offering a parity validation methodology that will miss exactly the cases that cause post-cutover failures.
• Sequence CPAR workloads before SBR workloads. Wireline broadband RADIUS authentication has fewer EAP complexity dependencies and is typically the larger session population. Stabilizing it on the replacement first reduces the risk surface for the EAP migration phase and gives the replacement platform’s session store time to reach operational steady state before EAP sessions are added.
• Time major tranches to avoid billing cycle close dates. Major cutover events should complete at least two weeks before a billing cycle closes, giving the billing team enough time to identify accounting anomalies before invoices are generated. A tranche that completes three days before month-end leaves insufficient time for accounting validation and no time for remediation.

Download the Alepo AAA Data Sheet →

Frequently Asked Questions

What is a Cisco CPAR migration and why does it matter for telecom operators?

Cisco CPAR migration is the process of replacing Cisco’s Carrier-grade Packet AAA Router with a modern platform capable of handling RADIUS subscriber authentication, authorization, and accounting at carrier scale without service interruption. It matters because CPAR has reached end of support, meaning Cisco no longer publishes security patches, bug fixes, or technical assistance for the platform under any support agreement. Operators running CPAR without a migration plan carry unpatched security exposure and have no vendor escalation path when authentication platform incidents occur.

When does Cisco CPAR reach end of life and what does that mean?

Cisco has published end-of-sale and end-of-life milestones for major CPAR software versions. Operators should verify the exact EOL date for their deployed version directly with Cisco, as milestones vary by release. End of life means no further software updates, security remediation, or technical support will be provided by Cisco, regardless of active support contract status. Operating on an EOL platform means authentication platform failures have no vendor engineering escalation path and accumulate unaddressed security vulnerabilities over time.

What is the fastest way to migrate off Cisco CPAR?

The fastest migration path is parallel running deployment: install the replacement in production, run it in shadow mode against live CPAR traffic, validate protocol parity, then shift subscriber segments progressively with rollback available at each step. Vendors with pre-built VSA migration tooling and documented shadow mode capability compress the discovery and validation phases. Hard-cutover migrations – taking CPAR offline and bringing the replacement up in its place – are faster in calendar terms but carry the highest risk of authentication failure and accounting gaps in production, particularly in environments with complex VSA configurations.

Which AAA servers are direct CPAR replacements for carrier operators?

Both commercial and open-source AAA platforms operate in carrier environments handling CPAR-class RADIUS authentication workloads. Commercial carrier-grade platforms typically offer certified 3GPP integration, support SLAs, and migration tooling out of the box; open-source options can run at scale but generally require additional engineering investment and commercial extensions to reach carrier-grade support and certified integration. For a combined CPAR/SBR replacement, the decisive evaluation criterion is whether a single platform can address both the wireline RADIUS workload and the EAP-based Wi-Fi authentication workload in one program – a vendor who can only address the CPAR workload requires a second migration program for SBR.

How long does a Cisco CPAR migration take?

A dual CPAR/SBR migration for a Tier-2 operator runs approximately five to six months from discovery through legacy decommission. The discovery and VSA audit phase takes three to four weeks. Protocol parity validation takes one to two weeks. CPAR workload migration takes four to six weeks using progressive NAS-by-NAS tranche migration. SBR workload migration adds three to four weeks after wireline stabilization. A minimum four-week stability window follows before legacy decommission. Tier-1 operators with more complex integration dependencies should plan 30–60 additional days across the discovery and CPAR migration phases.

What integrations does a Cisco CPAR migration require with existing telecom systems?

A CPAR migration touches the subscriber management system or HSS/HLR (credential and subscriber attribute source), the PCRF or 5G PCF via the Gx interface (policy enforcement and CoA routing), billing mediation (RADIUS accounting target), and the NAS/BRAS/BNG infrastructure (RADIUS clients). For combined CPAR and SBR replacement, add the ePDG via the SWm interface for VoWiFi authentication, the HSS via SWx for EAP-SIM/AKA credential lookup, and any Wi-Fi controller infrastructure receiving EAP-based authentication from SBR. Each integration point must be documented in the pre-migration assessment and validated during parallel running before any live traffic moves.

Conclusion

Running Cisco CPAR and Juniper Steel-Belted RADIUS past their end-of-life dates is not a risk that resolves itself. Each platform continues operating until it fails, and when it fails under end-of-life conditions, there is no vendor standing behind it. The case for a unified migration – replacing both with a single carrier-grade AAA platform in one program – comes down to risk arithmetic: one integration dependency map to maintain, one parallel running architecture to operate, one vendor accountable for the combined outcome. Two sequential programs sharing infrastructure dependencies that neither workstream fully owns is the alternative.

Alepo has completed migrations from CPAR-era legacy AAA environments for 50+ operators globally, on a platform validated at 36,000+ authentication transactions per second and designed for 99.999% uptime. For CSPs evaluating a combined exit from CPAR and SBR, the starting point is the interface inventory and VSA audit – before vendor selection, not after. Get the network documentation right first, and the vendor evaluation becomes a tractable engineering decision rather than a comparison of feature lists.

Book a demo and talk about your combined CPAR and SBR migration requirements.