NEC and Panasonic PBX Replacement: A Migration Checklist That Avoids Surprises

Legacy PBX estates do not get replaced because they are old. They get replaced because the copper, the trunk and the maintenance contract all reach the end of their useful life at roughly the same time — and then a much bigger surprise turns up: the phones on the desks are not the hard part, the things plugged into the back of them are.

Definition: NEC and Panasonic PBX replacement is the migration of a legacy proprietary exchange estate — NEC PBX, NEC iPBX, Panasonic KX-TDE/TKX and similar systems — onto an IP-PBX platform, with the analogue endpoints, ISDN trunks, calling plans and DIDs preserved.

Legacy PBX estates still running on ISDN

Legacy PBX deployments share a characteristic profile, and it is worth recognising because it explains most of the migration decisions:

• ISDN PRI or ISDN BRI trunks to the carrier. These were delivered as the standard trunking method for proprietary PBXs and remain so on many estates. The trunk count is often high because PRI was the cheapest way to buy channels.
• An analogue peripheral layer. FXS ports carrying desk phones, fax machines, wall phones in corridors, lift intercoms, alarm panels, card readers and PBX-to-PBX tie lines to distant buildings.
• Hybrid key systems still in place. A digital proprietary phone on the desk, a couple of analogue extensions behind it, an FXS trunk to a remote branch. NEC and Panasonic estates are frequently layered rather than clean.
• Existing DIDs and hunting group behaviour that the business has spent years tuning. Often the first and last thing anyone wants to change.
• Alarms, CCTV and access control integrations tied to the telephone system's dial-out or dial-in capability.

The consequence is that the visible work — swapping the phones — is maybe a third of the project. The rest is ports, trunks, translations and the things that were never documented because the original installer left no documentation.

What a NEC or Panasonic replacement actually involves

Four work streams, and they are not equal in difficulty.

1. Trunk migration. Moving ISDN PRI (30B+D) connectivity from the legacy exchange onto a platform that handles it natively. Newrock's OM1000-TE performs IMS/SIP and ISDN PRI (30B+D) protocol conversion, supports up to 120 concurrent calls, up to 40K busy-hour call capacity, carries 500 routing and number transformation rules, registers up to 512 SIP trunk accounts, and provides dual network port and dual power supply redundancy with 6000MIPS DSP processing capacity. The 500 routing and translation rules are the number that makes a messy legacy numbering plan migratable rather than a manual re-entry exercise.
2. Port mapping. Every analogue endpoint gets mapped to an FXS port on the new system, either built into the PBX or on a dedicated gateway.
3. Number and translation plan reconstruction. DIDs, direct-dial entries, hunting groups, overflow and call routing rules get rebuilt from the legacy configuration, not from the legacy configuration file — that file does not exist in most estates.
4. Endpoint and integration verification. Fax, intercom, alarm panel, lift phone, card reader, and anything that used the exchange's dial-out or dial-in for notifications.

Estates that get this right treat the legacy configuration export as a starting hypothesis rather than as source of truth. They walk the building.

Port mapping: keeping analogue devices alive

The following table maps the parts of a legacy exchange to the Newrock component that handles them. Every figure is taken from Newrock's published product pages.

This is where the sizing decision actually lives. Newrock gives you two ways to carry the analogue population.

Built into the PBX. The OM-series models carry built-in FXS/FXO ports directly on the chassis: OM20G up to 4, OM50G up to 12, OM80E up to 48, OM200G up to 96. The OM200G and OM200G-A both provide 96 built-in analogue ports. Where the analogue count fits inside these figures, no separate gateway is needed — which simplifies the estate, removes a box, and removes a thing to monitor.

Dedicated gateway. Where the analogue population is larger or spread across buildings, the MX series is the right structure. The MX8G provides 8 FXS/FXO ports with one WAN and one PC port, both 10/100/1000Mbps. The MX60E-G scales to 48 FXS/FXO ports, with SIP registration failover, load balancing and PSTN failover, plus optional 1+1 redundancy on the network port and power supply. The MX120G reaches up to 96 FXS and FXO ports for multi-tenant and large call centre deployments.

Two sizing rules that hold across most estates. First, count FXS and FXO separately — they are different things and conflating them produces the most common procurement error. Second, size on concurrency rather than on port count when the analogue population includes active devices rather than idle ones. The MX60E-G-SC, for example, supports 48 FXS ports and 48 SIP/IMS registration accounts with 32 concurrent calls on G.711 and 16 on G.729A with G.711 — so if a site has 48 fax machines and card readers, ports are the limit; if it has 48 active handsets, concurrency is.

Central control with local survivability

A legacy multi-site PBX estate usually had local autonomy at each branch — the branch exchange handled its own calls, and the tie line to head office was for inter-site dialling rather than for call routing. Reproducing that behaviour is not optional; it is the baseline expectation of the branch manager who signed off the original system.

Newrock's approach combines central management with local independence:

• The MA50-LS local survivability branch exchange provides 2 to 8 FXO ports, registers 50 to 200 SIP users, keeps calls working locally when the head office or cloud server becomes unreachable, and switches back to the central server once the connection is restored. This is the component that turns "the WAN fell over" from a site outage into a degradation.
• Head-office and branch SIP trunk communication is a native OM-series capability, so inter-site dialling and trunking work the way the legacy tie lines did.
• UMS provides unified management and remote maintenance across OM-series IP-PBX systems and MX-series VoIP gateways, so a distributed estate is still administered from one console.
• The SX100 session border controller supports branch networking and cross-network interconnection, SIP/IMS access, trunk redundancy and load balancing, with 1000 user registrations, 120 concurrent sessions and 70 media transcoding channels, plus customisable signalling header fields, codec and protocol conversion and DTMF mode conversion for the sites that need carrier-grade trunk control.

The design question at each branch is simple to state and easy to get wrong: what still works when the WAN fails? If the answer is "nothing", the branch needs a local survivability component. If the answer is "everything except inter-site calls", it may not.

A migration checklist by phase

Phase 1 — Discovery. Walk every site. Record extensions, trunk types and counts, DIDs, call routing and hunting rules, analogue endpoint inventory by type, integrations with alarm/CCTV/access control, recording and call accounting requirements, and every site whose local autonomy must be preserved. Get the legacy configuration export if it exists, and treat it as a draft.

Phase 2 — Design. Map the analogue population to built-in FXS/FXO ports or MX-series gateways. Decide the trunk strategy — whether PRI is converted via the OM1000-TE, whether SIP trunks replace it, or whether both run in parallel during transition. Design the survivability position for each branch. Size the platform on users, extensions, trunks, analogue ports and concurrent calls.

Phase 3 — Build in parallel. Install the new platform. Connect trunks. Configure the number plan and translation rules. Bring the recording and CDR systems into place.

Phase 4 — Pilot. Move one site, or one floor, with the most representative mix of endpoints. Run it long enough to hit a month-end if you can. Fix the realisations here rather than across the estate.

Phase 5 — Batch migration. Move by area: building, floor, department. Not by person. Batch migration by area produces far less support load and keeps local knowledge intact.

Phase 6 — Decommission. Only after the new system has been stable through a full business cycle. Remove the legacy exchange, keep the copper plant where it still serves an analogue endpoint, and archive the legacy configuration for reference.

Newrock perspective

Newrock's position on legacy PBX replacement is that the migration is an estate mapping exercise, and the two products that make it practical are the ones that handle what the legacy system handled. The OM series' built-in FXS/FXO ports — 4 on the OM20G, 12 on the OM50G, 48 on the OM80E, 96 on the OM200G and OM200G-A — mean that many estates need no gateway at all. The MX series covers the ones that do, with the MX8G at 8 ports, the MX60E-G at up to 48 with failover and load balancing, and the MX120G at up to 96.

For legacy ISDN-heavy estates, the OM1000-TE is the component that carries the transition: IMS/SIP and ISDN PRI (30B+D) protocol conversion, up to 120 concurrent calls, up to 40K busy-hour call capacity, 500 routing and number transformation rules, 512 SIP trunk accounts, dual network port and dual power supply redundancy and 6000MIPS DSP processing capacity. For branch autonomy, the MA50-LS keeps a branch serving calls with 2 to 8 FXO ports and 50 to 200 SIP registrations when the central server is unreachable, with automatic switch-back. For a distributed fleet, UMS gives one management and remote maintenance console across OM and MX platforms.

Endpoints are covered by the NRP range — the NRP1312G/P for standard desks, the NRP2020/W where cabling is a constraint, the NRP1600/P for video, the NRP1610G/P for touch and third-party applications. Recording is covered by RMS, which collects, stores, plays back and manages recordings from OM series and MX series platforms, with Recording Agent storing OM recordings as MP3 on Windows and CDR Software collecting call detail records as .txt to an external server.

The OM200G IP-PBX, MX60E-G VoIP gateway and MA50-LS local survivability branch exchange pages cover most of what an NEC or Panasonic replacement needs.

FAQ

How long does a legacy PBX replacement take?

Per site, the physical work is short — often a day or two. The elapsed time is trunk provisioning, number porting, number plan reconstruction, calling plan rebuild and user retraining. For a multi-site estate, plan on a phased rollout measured in weeks, not a big-bang cutover measured in a weekend.

Can we keep our existing NEC or Panasonic phones?

Proprietary digital phones from those platforms generally will not register with an OM-series system, because they rely on proprietary signalling rather than SIP. Analogue phones will work — they are what the built-in FXS/FXO ports and the MX series are for. This is usually the moment an estate realises how much of its desk estate is analogue rather than digital, and it changes the port count significantly.

What happens to the ISDN trunks?

They can be carried over. The OM1000-TE performs IMS/SIP and ISDN PRI (30B+D) protocol conversion with up to 120 concurrent calls, up to 40K busy-hour call capacity and 500 routing and number transformation rules, so a PRI-based estate can migrate without changing its carrier arrangements first. The SX100 also supports ISDN and SIP trunks with trunk redundancy and load balancing.

How do we handle sites that must keep working if the WAN fails?

Give them a local survivability component. The MA50-LS provides 2 to 8 FXO ports, registers 50 to 200 SIP users, keeps calls working when the head office or cloud server is unreachable, and switches back to the central server once the connection returns. Head-office and branch SIP trunk communication on the OM series handles the inter-site side.

Will our fax machines still work?

Analogue fax machines generally work on FXS ports. If a branch is on IMS rather than plain SIP, check for T.38 support — the MX60E-G-SC provides T.38 V3 high-speed fax. Test the specific machine and the specific line before the cutover, because fax behaviour varies more than people expect.

What about the alarm panels and lift intercoms?

These are the items most often missed. They sit on FXS ports and usually keep working, but some panels require a specific line type, polarity or line state, so confirm with the panel manufacturer. Treat this as a required conversation during discovery rather than a detail to resolve on the cutover night.

Do we need a separate box for the analogue ports?

Only if the count exceeds the built-in capacity. The OM20G carries up to 4 built-in FXS/FXO ports, the OM50G up to 12, the OM80E up to 48 and the OM200G up to 96 — so a large mixed estate can often be handled on the PBX chassis itself, and only the largest estates need an MX-series gateway.

Is there a per-user licence?

No — OM-series platforms license by device rather than by person. For an estate with legacy analogue extensions and a low person-to-device ratio, this is often the single biggest cost difference against a per-user model.

What about the number plan?

It gets rebuilt. The 500 routing and number transformation rules in the OM1000-TE exist for exactly this — a legacy estate's DIDs, direct-dial entries and hunting groups rarely translate cleanly without explicit rules. Build them deliberately and test each one, because this is where migration weekends are lost.

Conclusion

An NEC or Panasonic replacement is decided by four things: how many analogue endpoints you actually have, how your trunks are provisioned, which sites must survive a WAN failure, and whether your number plan is documented. Walk every site and count FXS and FXO separately — you will find that the analogue population is larger and more varied than the plan says, and that the fax machine, the lift intercom and the alarm panel are as much of the project as the desk phones. Carry the ISDN PRI through the OM1000-TE's IMS/SIP and PRI conversion with its 500 routing and number transformation rules, keep branch autonomy with the MA50-LS and head-office to branch SIP trunking, administer the whole fleet from UMS, and migrate by area rather than by flag day. Buy the new platform while the old one is still running, keep the old trunks alive through a full business cycle, and only then decommission.