The cost of doing nothing: legacy on-prem keeps getting riskier
Deferring a platform migration feels like the cautious choice. In practice, the risks compound quietly: servers that cannot be patched, firewalls that become a permanent job, knowledge that leaves with the people who hold it, and data that drifts further from any clean state every year.
Calling cards and prepaid voice are not a dying business. Specific corridors — diaspora communities calling South Asia, Latin America, West Africa — still carry substantial traffic. Many operators serving those corridors are generating consistent revenue on platforms that have been running for a decade or more. That is part of the problem: the revenue makes it easy to treat the platform as a solved question.
The argument for staying put is usually framed as risk management. The platform works. A migration carries risk. The disruption might outweigh the benefit. Better to wait until the timing is right.
The timing argument treats the current state as static. It is not. Every month a legacy on-prem prepaid platform stays in production, the attack surface grows, the operational knowledge base shrinks, the data becomes harder to clean, and the eventual migration becomes a larger project. Doing nothing is not a neutral position. It is a choice with a cost that accumulates whether or not it is being measured.
Six ways the risk grows while you wait
None of these is a one-off event. Each is a direction of travel — and without intervention, each gets worse over time.
Servers that cannot be patched
An on-prem prepaid platform typically runs on infrastructure that is tightly coupled to specific OS versions, database releases, and runtime dependencies. When those components reach end-of-life, security patches stop arriving. CVEs accumulate against software the vendor stopped supporting years ago, and the platform cannot be updated without risking the service. The exposure is not theoretical — it grows with every new vulnerability disclosure.
Firewalls as a permanent strategy
The standard response to an unpatched platform is a perimeter: firewalls, IP allowlisting, VPN tunnels, access controls. Each new threat requires a new rule. Rules accumulate, overlap, and become difficult to audit. This is not a security posture — it is a permanent reaction to a root cause that is never addressed. The firewall becomes a full-time maintenance job that still leaves the underlying system unpatched.
Knowledge walking out the door
The business logic that keeps the platform running correctly — the rate tables that have been adjusted over years, the IVR behaviour that was modified for a specific carrier, the support procedures that depend on knowing how the system was originally configured — often exists in people's heads. As team members move on, that knowledge is not replaced. Each departure makes the system harder to reason about, harder to change safely, and harder to hand over.
Data quality continuing to degrade
Without a normalisation event, format drift, rate-table inconsistencies, stale account states, and accumulated exceptions keep compounding. Support workarounds create new formats. Manual adjustments create undocumented exceptions. Operational patches create configuration that was never part of the product model. Every year of additional runtime makes the eventual migration harder and riskier.
Fraud patterns the platform cannot respond to
PIN fraud and calling fraud evolve. Attack patterns adapt to whatever defences are in place. A platform that cannot be updated — because any change risks breaking something — cannot respond to new threat patterns. Caps, velocity limits, and concurrency controls that were adequate when the platform launched may be bypassed by techniques that emerged since. The defence is frozen; the threat is not.
Hidden complexity that only grows
Every support workaround, every exception created under pressure, every manual fix applied to keep the service running adds to the system's undocumented complexity. Over time, the actual behaviour of the platform diverges further from anything written down. The longer it runs, the higher the risk of any change and the harder the audit trail — regardless of whether the people who made those changes are still there. The accumulated mess is the liability, not just the knowledge gap. A misconfiguration nobody noticed, a stale rate entry, a dormant fraud vector that was never closed — these sit quietly until something causes them to surface. The longer they sit, the greater the chance that one of them becomes an incident.
The longer it runs, the harder it gets
Each of these risks compounds the others. A platform that cannot be patched is also harder to audit, because any intrusion attempt lands on infrastructure that cannot be updated to log it properly. Data that keeps drifting makes the security picture harder to interpret, because anomalies blend into the background noise of inconsistent records. Knowledge that walks out the door makes all of these harder to address, because fewer people understand the system well enough to change it safely.
A migration that was moderately complex two years ago is more complex now, because there is more drift, fewer people who remember the original design, and more operational workarounds layered on top. If that trajectory continues, the window for a controlled migration closes — and the operator is left with an unplanned one.
An unplanned migration — forced by a hardware failure, a security incident, or a vendor decision — is the most expensive kind. The option to migrate on your own terms exists now. It may not exist indefinitely.
A controlled migration is still possible
The goal of a migration is not to reproduce the old platform on new infrastructure. It is to replace it with something safer to support, easier to audit, and no longer dependent on specific people or undocumented workarounds. The data gets cleaned on the way in. The hidden business logic gets surfaced and rebuilt explicitly. The rate tables are normalised. The PIN and account data is validated.
That kind of migration is possible as a controlled event: discovery, dry runs, reconciliation, a tested cutover procedure, rollback criteria. It is a different outcome from copying the existing mess onto a new server — and it closes the risks that accumulate as long as the legacy platform stays live.
Seshnova approaches migration as an operational control process. The platform it moves operators onto is built around real-time prepaid enforcement: per-second rating, A to Z rate decks, hard cut-off, balance and PIN control, CDR audit, fraud caps, and API and softswitch integration. The migration tooling normalises the data on the way in, so the new platform starts from a cleaner position than the one it replaced.