The ACS URL is one parameter on the CPE. Changing it is trivial. Everything that depends on it is not: the presets that set WAN, Wi-Fi and VoIP, the firmware campaigns, the diagnostics your support desk runs, and the habit your first-line team has of trusting whatever the ACS shows them. A migration turns into a support storm when devices arrive at the new ACS before the new ACS knows what to do with them.
The rule I work from is simple: never point a device at an ACS that has not already proved it can handle that device's model, firmware and plan. Everything below is that rule turned into a sequence.
Before you touch a single device
Most of the pain in ACS migrations is discovered on day one of the rollout and could have been found a month earlier in a spreadsheet. Build the inventory first.
- Fleet by model and firmware. Pull the full list from the vendor ACS: manufacturer, model, hardware version, software version, and how many devices of each. The long tail matters: the odd model with a few hundred units is the one that will surprise you.
- Data model per model. Note which devices speak TR-098 (
InternetGatewayDevice.) and which speak TR-181 (Device.). Your presets will branch on this, so decide the mapping now, not during the batch. - How the ACS URL is set today. It may come from the vendor ACS itself, from DHCP, from a factory default baked into the firmware, or from a mix of these. If the firmware resets the URL on factory reset, a support agent can undo your migration one device at a time without knowing it.
- Export the existing presets. Whatever the vendor ACS applies on first contact, on plan change and on reboot, write it down as plain parameter lists. These become your GenieACS provisions.
- Inform interval and reachability. Devices only move when they next inform. Know the interval, and know which devices sit behind NAT without a working connection request. Those are the stragglers you will be chasing at the end.
- Who else talks to the ACS. Billing, OSS/BSS, the support portal, the field app. List every integration that calls the ACS API, because each one needs a GenieACS equivalent before the device it refers to moves.
Build GenieACS to receive, not to act
Stand up GenieACS, size it for the full fleet rather than the first batch, and put it behind the same kind of front-end you would use for any other production service. Then do something that feels counter-intuitive: for the first phase, give it presets that only observe.
In this read-only phase the ACS accepts informs, refreshes the parameters you care about, and tags the device with its model and firmware. It changes nothing. This lets you point a handful of lab units at it and confirm three things:
- the device completes the inform and
GetParameterValuescycle cleanly; - the parameter paths you mapped actually exist on this firmware;
- connection requests work through your network, so remote actions will later work too.
Only when a model and firmware pair passes this phase does it earn a preset that changes something.
Presets per model, logic shared
Multi-vendor fleets are normal, not a problem. The pattern that keeps them manageable is one preset per model (and sometimes per firmware) for the parameter mapping, with shared provisioning logic for the business rules. The decision "this subscriber is on this plan, so WAN is PPPoE with these credentials and Wi-Fi is this SSID" lives in one place; the question "what is the exact path for the PPPoE username on this box" lives in the model preset.
Test each preset against a lab unit for every model and firmware pair you intend to move. Check the obvious (WAN comes up, Wi-Fi name is right, VoIP registers if it applies) and the less obvious:
- the device does not reboot more than once after provisioning;
- a second inform does not re-apply the same values and trigger another reboot;
- a factory reset followed by first contact lands on the correct preset without manual help.
The batch plan
Now, and only now, start moving real devices. The mechanics are usually a staged ACS URL change per batch, with a verification step before the next batch.
- Start with 1–2% of the fleet. Pick a batch that is homogeneous (one model, one firmware) and sits in a region where your support team has capacity to notice problems.
- Change the URL through the mechanism you identified. If the vendor ACS can set
ManagementServer.URL, use it. If DHCP or firmware defaults are involved, align them in the same change window, or the device will drift back. - Watch the arrival. Every device in the batch should inform to GenieACS within roughly two inform intervals. Anything that does not is either unreachable or still pointed at the old ACS. Resolve the list before moving on.
- Confirm the preset ran. The device should carry your tags, the parameters you expect should be present, and nothing subscriber-facing should have changed.
- Verification gate. Before batch two: zero reboot loops, no rise in tickets for the batch's region, remote actions (reboot, Wi-Fi change, diagnostics) working on at least a few devices from the batch.
Grow the batches as the gate keeps passing. If the gate fails, stop. Fix the preset, not the batch.
Keep the vendor ACS alive
Do not decommission the old ACS until the last straggler has moved and stayed moved. While it is alive, rollback is a single parameter change back to the old URL. The moment it is gone, rollback becomes a project.
Keep its credentials, its exports and its access logs. The access log is how you find devices that are still informing to the old system weeks later.
Support desk readiness
A support storm is rarely about devices. It is about agents who cannot see what happened. Before the first batch:
- the actions they use daily (reboot, factory reset, Wi-Fi change, diagnostics) work on GenieACS and are reachable from the tool they already use;
- a lookup by serial number or subscriber ID shows which ACS the device is on right now;
- a one-page "what changed and what to do if" sits next to every agent;
- there is one channel where the migration team watches for patterns in real time during each batch.
Firmware comes after, not during
It is tempting to combine the migration with a firmware update, because you are touching every device anyway. Resist it. A firmware campaign changes the data model, the default values and sometimes the ACS URL itself. Run it as a separate staged rollout with its own rollback once the fleet is stable on GenieACS. One variable at a time is slower on the calendar and much faster in practice.
Rollback, written down before you need it
- The exact parameter and value to restore per model.
- Who is allowed to trigger it and from where.
- The condition that triggers it: a measurable one, such as a ticket spike for the batch region or any device in a reboot loop.
- Confirmation that the old ACS still accepts the device and applies its old preset.
What done looks like
You know the migration has worked when the inform pattern on GenieACS is steady and predictable, the old ACS access log is quiet, ticket volume did not move during the batches, and your support team has stopped logging into routers. That last one is the point of the whole exercise.
If you are planning a move like this and want a second pair of eyes on the inventory, the presets or the batch plan, that is exactly the kind of review I do.