‘We can’t touch the Core’: the sentence that’s slowing telecom down

In telecom legacy systems, treating the core as untouchable shifts innovation to surrounding layers, where incremental integrations, duplicated logic and reactive extensions compound into architectural sprawl. That sprawl increases IT cost, slows product velocity and introduces operational drag not because of inadequate investment, but because change propagates across fragmented system boundaries. The article argues that telecom modernization becomes effective only when leaders deliberately redefine what the core should own, clarify system boundaries and treat integration as a first-class capability. The central decision is whether the current telecom IT architecture makes change progressively safer and more predictable, or progressively heavier and more fragile.

In many telecom organizations, there is one sentence that quietly shapes every architectural decision: “We can’t touch the core.”

It is usually said with good reason. Core billing systems, provisioning engines and legacy OSS/BSS platforms that form the backbone of telecom legacy systems sit at the heart of revenue generation and regulatory compliance. They are stable because they have to be. They are slow because they have grown over decades. Replacing them is risky, expensive and politically complex.

So teams build around them.

Over time, that defensive posture becomes strategy. New customer journeys are layered on top. Manual workarounds are digitized without rethinking the underlying flows. Integration logic grows in middleware. Data is copied instead of unified. Product teams learn to operate within constraints rather than question them.

The result is not stagnation. Telecom companies are investing heavily in transformation. According to GSMA Intelligence, global operator spending on telecom digital transformation initiatives continues to rise as part of broader network and IT modernization efforts. The intent is clear. The execution is where friction accumulates.

This article is not about replacing core systems or debating vendor platforms. It is about understanding how architectural decisions shape the effectiveness of custom telecom solutions and broader telecom modernization efforts.

We will explore how defensive thinking around legacy systems leads to compensating complexity elsewhere, how that complexity slows innovation more than the core ever did and how telecom leaders can reframe modernization without triggering large-scale replacement programs.

Why the core feels untouchable in telecom legacy systems

For most telecom CTOs, the core is not just software. It is accumulated operational history.

Billing engines encode years of pricing logic, exception handling and regulatory adjustments. Provisioning systems reflect network constraints, regional variations and legacy product bundles that still generate revenue. OSS/BSS stacks have survived mergers, vendor swaps and technology cycles. They are fragile in places, rigid in others and deeply interconnected with finance, compliance and operations.

Touching them carries visible risk:

• Revenue disruption
  
• Regulatory exposure
  
• Contractual complications with vendors
  
• Multi-quarter delivery timelines
  
• Organizational resistance across departments
  

In regulated environments, stability is not a preference. It is a mandate. Downtime has financial and reputational consequences. Audit trails must be preserved. Data integrity is non-negotiable.

Given that context, “we can’t touch the core” sounds responsible.

The problem is not the instinct to protect critical systems. The problem is what happens next.

When the core is declared off-limits, innovation shifts to the edges without architectural intent. Product teams are asked to launch new services, improve self-service journeys or automate internal workflows, but only through additional layers. Engineering teams integrate around constraints instead of redesigning flows. Over time, the organization stops asking whether the core is the real bottleneck and starts assuming it is immutable. The untouchable core becomes a boundary condition for every decision. And that boundary shapes complexity everywhere else.

How “protect the core” turns into architectural sprawl

Once the core is declared untouchable, delivery pressure does not disappear. Product roadmaps still move. Enterprise customers still demand new bundles, faster provisioning and better visibility. Regulators introduce new reporting requirements. Commercial teams push for differentiated offers.

The work simply shifts outward.

New requirements are addressed through:

• Additional middleware layers
• Custom scripts reconciling data between systems
• Shadow databases built for reporting or analytics
• Manual operational checkpoints embedded into digital flows
• Standalone portals layered on top of legacy APIs

Individually, each decision is pragmatic. A small integration avoids disturbing a billing engine. A wrapper modernizes an interface without rewriting it. An auxiliary data store accelerates reporting without refactoring core schemas.

Collectively, these decisions compound.

Industry research from McKinsey shows telecom operators often spend 15–20% of revenues on IT, a significant portion of which is driven by maintaining complex, fragmented legacy estates rather than enabling new capabilities.That spend is rarely about innovation alone. It reflects the operational cost of accumulated architecture.

Over time, architecture diagrams reveal multiple orchestration layers between customer interfaces and core systems. Data is replicated because real-time access is unreliable. Business logic exists in more than one place. Exception handling grows reactively, often undocumented.

Release cycles slow not because teams lack skill, but because every change carries ripple effects across interconnected components. Incident resolution becomes cross-functional by necessity, not design.

At that point, the core remains stable. The surrounding digital estate does not. The friction begins to show up most clearly in how quickly product teams can move and how predictably new capabilities can be introduced.

Where the friction becomes visible: product velocity and operational drag

Architectural sprawl rarely surfaces as a visible architectural crisis. It becomes measurable in delivery performance and operational efficiency.

The first signal is product velocity. Seemingly contained roadmap items begin to require cross-stack coordination because business logic is distributed across billing systems, integration layers and custom extensions. A pricing adjustment affects multiple services. A new enterprise feature depends on data that is replicated rather than shared. Scope expands during implementation because dependencies were not fully visible at planning stage.

The result is slower release cycles and reduced predictability. In many telecom modernization programs, this slowdown becomes the hidden cost of architectural layering.

Engineering capacity shifts toward managing complexity rather than building differentiation. A growing share of effort is spent on integration validation, regression testing across interconnected components and troubleshooting data inconsistencies between systems. Additional governance steps are introduced to reduce risk, which further extends timelines.

Operational performance reflects the same structural issue. Exception handling increases where workflows were layered rather than redesigned. Monitoring provides visibility into components but limited insight into end-to-end customer journeys. Incident resolution requires coordination across multiple ownership domains, lengthening recovery times and diffusing accountability.

None of this is caused by incompetence or lack of investment. It is a structural outcome of protecting the core while continuously extending around it.

At this stage, stability is preserved, but adaptability declines. The question shifts from whether the core can be modified to how the surrounding architecture can be intentionally restructured so that innovation does not depend on navigating accumulated complexity.

Rethinking telecom modernization without triggering a core replacement program

When delivery slows and operational drag increases, the instinctive reaction is often framed as a binary choice: either continue working around the core or initiate a large-scale replacement program. In practice, neither extreme is attractive. Full core replacement carries financial, regulatory and organizational risk. Continuing to layer around existing constraints compounds complexity.

A more pragmatic approach starts by reframing the objective. For telecom leaders investing in custom telecom solutions, this reframing is critical to avoid repeating the same structural constraints in new systems. The goal is not to “modernize the core” as a monolithic initiative. It is to regain architectural control over where differentiation lives and how change propagates across the system. This mirrors the structured simplification approach discussed in our analysis of how mature telcos streamline without losing stability.

1. Clarify and enforce system boundaries

Core systems should remain responsible for what they are structurally designed to handle: stable transaction processing, compliance-critical logic and revenue integrity. Problems arise when differentiation logic, customer-specific workflows or temporary business rules become embedded inside them or loosely replicated across surrounding systems.

Defining explicit domain boundaries reduces ambiguity. When ownership is clear and responsibilities are intentionally separated, teams can evolve customer-facing capabilities without repeatedly navigating hidden dependencies inside legacy platforms.

2. Consolidate business logic that has drifted outward

Over time, business rules tend to spread. Pricing logic appears in middleware. Eligibility rules are duplicated in portals. Exception handling lives in scripts maintained by operations teams. Each duplication may have been justified at the time, but collectively they create inconsistency and risk.

Identifying where decision logic resides and consolidating it into clearly owned services restores coherence. It also reduces the ripple effect of change, because modifications are made once rather than reconciled across multiple layers.

3. Treat integration as a product capability

In many telecom environments, integration evolves reactively. APIs are added to satisfy immediate needs. Event flows are introduced without consistent versioning or observability. Workflow orchestration is implemented in whichever layer is easiest to modify.

Designing integration deliberately changes that dynamic. API layers, event streams and orchestration services should be versioned, observable and owned. When integration is treated as a first-class capability rather than glue code, new functionality can be introduced without amplifying fragility.

These shifts do not require rewriting the entire core. Instead, they require disciplined engineering decisions about ownership, boundaries and long-term maintainability. The organizations that regain velocity are not necessarily the ones that replaced their legacy systems. They are the ones that stopped allowing the legacy core to dictate every architectural compromise around it.

How to assess whether you are scaling stability or scaling fragility

For most CTOs, the difficulty is not acknowledging complexity. Telecom stacks are complex by nature. The harder question is whether that complexity is intentional and bounded, or whether it is expanding in ways that quietly reduce optionality.

A useful starting point is to examine how change behaves inside your system.

Consider change amplification. When a contained commercial adjustment, such as introducing a new pricing model or modifying eligibility criteria, consistently requires coordinated updates across multiple services and integration layers, the architecture is likely carrying hidden coupling. In a well-bounded system, changes should be localized more often than they are systemic.

Look at where business logic lives. If pricing rules, provisioning conditions or validation steps are duplicated across portals, middleware and reporting tools, alignment depends on communication rather than structure. Over time, that dependency on coordination becomes a risk surface.

Dependency visibility is another indicator. If planning cycles routinely uncover unknown integration constraints late in delivery, the issue is rarely individual oversight. It reflects insufficient transparency in how systems interact and where responsibilities are defined.

Finally, assess coordination overhead. When roadmap delivery is gated more by cross-team synchronization than by engineering capacity, structural coupling is likely constraining flow.

These are not signals of failure. They are signals of accumulated design decisions interacting at scale. The relevant shift is not immediately about replacing platforms. It is about determining whether the current architecture makes change progressively safer and more predictable, or progressively heavier and more fragile. That distinction shapes what modernization should target next.

Reframing the sentence: defining what the core should and should not own

“We can’t touch the core” often persists because the core has never been clearly redefined. Responsibility expands gradually. Systems that began as transaction engines gradually absorb workflow logic, product configuration rules and integration shortcuts. The boundary blurs.

A more productive question is not whether the core can be modified, but what it should be responsible for.

In most telecom environments, the core’s role is straightforward: ensure revenue integrity, enforce compliance-critical processes and execute high-volume transactions reliably. Those responsibilities justify caution and stability. They do not justify allowing every new capability to be shaped by historical constraints.

Differentiation, on the other hand, rarely belongs inside the core. Customer experience, orchestration logic, experimentation with new bundles and automation of internal workflows are areas where flexibility and iteration matter more than transactional durability. When these capabilities are tightly coupled to legacy systems, innovation inherits the core’s release cadence and risk profile.

Redefining ownership clarifies trade-offs. If a capability drives competitive advantage or operational agility, it should sit in a domain designed for change. If it safeguards revenue and compliance, it belongs in a domain optimized for stability.

This reframing shifts the conversation from avoidance to intent. The core is no longer untouchable by default. It becomes deliberately scoped. And once that scope is explicit, architectural decisions around it become less reactive and more strategic.