Why operators convert
Static addressing is simple until it isn't: enforcement means firewall rules per IP, a plan change means someone edits a router, and you can't see who's actually online. PPPoE gives every subscriber an authenticated session — suspend and restore become RADIUS decisions the billing engine makes itself, speeds are enforced per session, and the live session table becomes your truth.
Phase zero: inventory before anything
Every conversion that goes wrong goes wrong here. Before touching a single ONT, reconcile what's actually deployed: which subscriber is behind which ONU, which ONT models are in the field (their WAN capabilities differ), and which NAS each site homes to. CoreSync's ONU-subscriber binding and import tooling exist for exactly this step.
The per-subscriber conversion recipe
Converting one subscriber is a sequence, and order matters:
- Create the PPPoE credential in billing first, so RADIUS will answer the instant the ONT dials
- Push the new WAN configuration to the ONT — PPPoE with the credential, correct VLAN, NAT on
- Delete the old static/IPoE WAN only after the PPPoE WAN exists — remove it first and you've orphaned the device
- Verify the session came up in the live table, at the right speed, from the right NAS
Credential first, new WAN second, old WAN last. Reverse the order and you're driving to that house.
Batch by site, not by percentage
Convert one PON port or one estate at a time, during the day, while a technician is nearby for the odd ONT that misbehaves. A site batch means any fallout is geographically contained and explainable. Expect a small tail of stubborn devices — ONTs that need an OLT-side deactivate/activate to complete, or models whose credentials must be pushed a different way. Budget the tail; don't let it stall the rollout.
After: what you get to delete
When the last subscriber converts, a whole category of operations disappears: the per-IP firewall rules, the router edits on plan changes, the 'is this customer even connected' guesswork. Enforcement, speed changes and reconnections are now billing-state events — which is the entire reason you did this.