A carrier-grade AAA server deployment timeline runs five phases: planning (2–4 weeks), staging and integration (2–3 weeks), pilot (2–4 weeks), cutover (about a week), and post-go-live stabilization (2–4 weeks), for a typical total of 9–16 weeks. Subscriber scale, protocol scope, integration count, and migration versus greenfield decide where in that range a project lands. Pilot and stabilization are the two phases that should not be compressed to hit a date.
Somebody has asked you for a date. The business case for the new AAA (authentication, authorization, and accounting) platform is approved, and a project sponsor wants to know when subscribers will be authenticating on the new system. The accurate answer is a range, and this article gives you one you can defend. An AAA server deployment is not a same-week install, and it is not a year-long enterprise IT program either. For a carrier-grade platform handling RADIUS, Diameter, or TACACS+ traffic, the work falls into five phases, each with a typical duration that shifts with scale and complexity.
A typical carrier-grade AAA server deployment takes roughly 9–16 weeks end to end: planning (2–4 weeks), staging and integration (2–3 weeks), pilot (2–4 weeks), cutover (about a week), and post-go-live stabilization (2–4 weeks). Large subscriber bases, wide protocol scope, and migration from a legacy system push the total toward the longer end.
| Phase | Typical duration | What stretches or shortens it |
| Planning and scoping | 2–4 weeks | Number of access types in scope; quality of the existing NAS/BNG inventory; how quickly sizing inputs (peak auth rate, accounting frequency) can be collected |
| Staging and integration | 2–3 weeks | Count of adjacent systems (HSS/UDM, PCRF, OCS, BSS, SIEM); availability of test environments for each; certificate and EAP method coverage |
| Pilot | 2–4 weeks | Size and diversity of the pilot segment; number of validation cycles needed before the exit criteria are met |
| Cutover | Usually one scheduled window; up to a few windows for phased waves | Rollout model chosen (big-bang, phased, parallel-run); change-freeze calendar |
| Post-go-live stabilization | 2–4 weeks | Volume of tuning and edge-case fixes; time to complete the first accounting reconciliation against the legacy system |
1. Planning phase: 2–4 weeks of scoping and sizing
A common mistake is treating planning as paperwork before the real work starts. In practice this phase decides how long every later phase takes. A project that enters staging with an accurate inventory of every network access server (NAS), broadband network gateway (BNG), wireless controller, and packet-core element that will talk to the AAA moves quickly. A project that discovers a forgotten realm or an undocumented Diameter peer during pilot loses weeks.
Three deliverables define the phase. Scope: which access types (fixed broadband, Wi-Fi, mobile data, device administration) move to the new platform, and in what order. Sizing: peak authentication rate, interim accounting frequency, session counts, and growth headroom; our AAA server capacity planning guide covers the arithmetic. And the rollout model: choosing between big-bang, phased, and parallel-run sets the shape of cutover later.
Two weeks is realistic for one access type and a clean inventory. Four weeks is realistic for a converged operator collecting sizing data from several network teams and agreeing on a migration order between them.
2. Staging and integration phase: 2–3 weeks
Staging is where the platform is installed in a pre-production environment and wired to everything it will depend on in production. For a RADIUS-only broadband deployment, that means the BRAS/BNG (broadband remote access server) estate, the subscriber store, and the mediation or billing feed for accounting records. For a mobile deployment it also means Diameter interfaces toward the home subscriber server (HSS) over SWx, the packet gateway over S6b, the policy and charging rules function (PCRF) over Gx, and the online charging system (OCS) over Gy, or their 5G-core equivalents. Each needs a test peer and a test plan.
The integration count is the biggest driver of duration here. Each adjacent system adds interface testing and usually has its own owner with its own change calendar. The AAA server installation checklist lists what must be verified before staging is complete: protocol conformance, authentication method coverage (EAP-SIM, EAP-AKA, EAP-TLS, EAP-PEAP, as scope requires, where EAP is the Extensible Authentication Protocol), high-availability behavior, and a first load test against the sizing numbers from planning. Staging cannot be skipped because the vendor has done “the same deployment” elsewhere; the platform may be identical, but the network it connects to never is.
3. Pilot phase: 2–4 weeks on a real subscriber segment
The pilot is the first time production traffic touches the new AAA, and it is the phase most often compressed under schedule pressure. Staging proved the software works. The pilot proves it works against this operator’s live NAS behavior, subscriber profiles, and accounting flows, with a blast radius small enough that a fault is a ticket, not an outage.
A workable pilot segment is representative but contained: a single region, a single realm, or a defined group of NAS devices. Write the exit criteria before the pilot starts; the usual three are authentication success at or above the legacy baseline, accounting records reconciling against the legacy system, and failover behaving as designed. A pilot that meets its criteria in the first validation cycle can close in two weeks. One that surfaces a NAS attribute quirk or an accounting mismatch needs a fix, a retest, and often a second cycle, which is where the fourth week goes.
How fast the team can read a reject code or an EAP failure trace decides whether that second cycle takes days or weeks. Shortening the pilot itself moves the risk into cutover, where it costs far more; how to reduce AAA server deployment risk covers what typically surfaces here.
4. Cutover: usually a single scheduled window
Cutover is the shortest phase on the calendar and the one with the most preparation behind it. For a big-bang rollout it is one overnight maintenance window in which the NAS fleet is repointed to the new AAA, traffic is verified, and the legacy system is left running as a warm fallback. For a phased rollout it is a series of such windows, one per subscriber wave.
The week covers the go/no-go review, the window itself, and the post-window check. Two things keep it to a week: a rehearsed rollback with known trigger conditions, and failover already exercised in pilot, so a node loss during cutover is a known event with a known response.
5. Post-go-live stabilization: 2–4 weeks of close monitoring
Go-live is not the end of the project, and treating it as the end is an expensive planning error. The weeks after cutover are when the platform meets traffic the pilot never generated: month-end accounting peaks, a firmware update on one NAS vendor’s gear, a roaming partner’s Diameter peer behaving differently from its documentation.
The work is mostly tuning and reconciliation. Timeout and retry values are adjusted against observed latency. Accounting output is reconciled against the legacy system for at least one full billing cycle, and operations staff move from vendor-assisted to independent handling of alarms and routine changes. The phase ends when the operator’s own team has run a complete billing cycle without the vendor on the critical path; only then is the legacy AAA switched off. Budget the full four weeks even if you expect to finish in two; finishing late against a two-week plan is a governance problem.
What actually moves the AAA server deployment timeline
Four variables explain most of the difference between a 9-week project and a 16-week one.
- Scale: A larger subscriber base means more NAS devices to inventory and repoint, a larger pilot segment, and more accounting volume to reconcile. Scale does not change the number of phases; it lengthens planning, pilot, and stabilization.
- Protocol scope: A RADIUS-only deployment has one protocol to test. One terminating RADIUS, Diameter, and TACACS+ has three, plus the EAP method matrix for Wi-Fi and Wi-Fi calling. Each adds staging time.
- Integration complexity: Every adjacent system with its own owner and change calendar adds coordination time. Mobile deployments, with HSS or unified data management (UDM), PCRF, and OCS integration, sit at the long end.
- Migration versus greenfield: Replacing a legacy AAA (Cisco Prime Access Registrar, a self-managed FreeRADIUS estate, a vendor-specific platform) adds data migration, parallel-run reconciliation, and legacy decommissioning. Greenfield deployments skip all three. A dedicated article covers how long an AAA migration really takes.
- An illustrative timeline for a mid-size operator: Consider a regional fixed and Wi-Fi operator replacing a legacy RADIUS platform, with two access types in scope and a phased rollout by region. Planning runs three weeks, spent reconciling the BNG inventory across two network teams. Staging takes three weeks because the Wi-Fi controllers need EAP method testing the broadband estate does not. The pilot covers one region and closes in three weeks after one retest of an accounting mismatch. Cutover runs as three regional windows across two weeks, and stabilization takes three weeks, ending when a full billing cycle reconciles cleanly. Total: 14 weeks. A single-access-type operator with a clean inventory and a big-bang cutover could plausibly land at 9.
The platform under the project affects these numbers too. Alepo AAA Server terminates RADIUS, Diameter, and TACACS+ natively on one stack, so a converged operator runs one integration program instead of three. It deploys on Docker and Kubernetes, on virtual machines, on bare metal, in private cloud, or on-premises, so staging fits the environment the operator already has. It is built on real-time database replication with stateless session storage backed by database persistence, and is engineered for 99.999% availability, so the failover tested in pilot is a property of the design. It runs in Tier-1 and Tier-2 carrier networks across the Middle East, Europe, Latin America, Africa, and Asia, in fixed, mobile, and converged deployments.
Want a timeline for your network, not a generic one? Book a demo and bring your access types, integration list, and rollout preference; a scoping conversation is the fastest way to turn this range into a date. Or start with the Alepo AAA Server solution page for your project team.
Frequently asked questions
Q1. How long does AAA server deployment take?
A typical carrier-grade AAA server deployment takes roughly 9–16 weeks end to end: planning (2–4 weeks), staging and integration (2–3 weeks), pilot (2–4 weeks), cutover (about a week), and post-go-live stabilization (2–4 weeks). Scale, protocol scope, integration count, and whether the project is a migration or greenfield decide where in that range a given project lands.
Q2. What is a realistic AAA server implementation timeline?
A realistic timeline is a phase-by-phase range rather than a single number. Use the table above, place your project in each phase’s range based on your scale and integration list, and add the phases together. Most sponsors should plan against the longer end and treat an early finish as upside.
Q3. What factors affect AAA deployment duration?
Four dominate: subscriber and NAS scale, protocol scope (RADIUS only versus RADIUS plus Diameter plus TACACS+), the number of adjacent systems to integrate (HSS/UDM, PCRF, OCS, BSS, SIEM), and whether the project is a migration from a legacy AAA or a greenfield build. Migration and mobile integration are the two that most often push a project past twelve weeks.
Q4. How long does the pilot phase take in an AAA rollout?
Typically two to four weeks. Two weeks is achievable when the pilot segment is small and the exit criteria are met in the first validation cycle; four weeks allows for a fix and retest after the pilot surfaces a NAS attribute or accounting mismatch, which is common on the first live segment.
Q5. How long does AAA migration from a legacy system take?
Longer than a greenfield deployment, because data migration, parallel-run reconciliation against the legacy platform, and legacy decommissioning are added to the plan. Migrations tend to sit at the upper end of the 9–16 week range or beyond it for large converged operators. A dedicated article on AAA migration timelines covers this in detail.
Q6. Does the deployment timeline differ by operator size?
Yes. Larger and more complex operators should plan toward the longer end of every phase range. Scale lengthens planning (more inventory), pilot (a larger representative segment), and stabilization (more accounting volume to reconcile), even though the number of phases stays the same.
Q7. Can AAA server deployment be accelerated?
Some phases compress with dedicated resources: planning moves faster when the NAS inventory and sizing inputs are ready on day one, and staging moves faster when every adjacent system has a test environment available. The pilot and stabilization phases should not be cut, because they are where live-traffic problems surface at low cost. Compressing them moves the same problems into cutover or production, where they are expensive. The rollout strategies article explains how the choice of model affects total duration.
