Digital transformation programmes don't fail for lack of ambition. They fail because the foundation underneath the ambition isn't production-grade. This is the story of a national telecommunications operator that built the right foundation first and handed it back to their own team, ready to extend.
The question every telco faces
For an incumbent operator running a digital transformation programme, the hardest question is rarely which digital service to launch first. It is this: do we have a real integration foundation we can keep building on, or are we adding new point-to-point links to a fragile estate that will need replacing again in three years?
This national telecommunications operator in an emerging Lusophone market had faced that question. The legacy estate was point-to-point, with microservices scattered across the stack. Adding a new digital channel meant building a new bespoke integration from scratch. Operational visibility into what was happening at the integration layer was limited. The estate wasn't a platform. It was an accumulation.
The operator's digital transformation programme, driven by competitive pressure, needed something different: a production-grade hybrid integration platform, built once and built properly, that the local team could own and extend independently.
Production-grade from day one, not retrofitted
Ampleshift built the foundation before building the integrations. That distinction matters.
The deployment is a hybrid MuleSoft platform: cloud and on-premises, with four Runtime servers across two server groups providing high availability and redundancy from the first day of operation. A dedicated server runs the full Elastic Stack: Filebeat, Logstash, Elasticsearch, Kibana. End-to-end operational logging and traceability the legacy estate had never had.
API-Led Connectivity was applied as the governing architecture from sprint one. System APIs expose the operator's core systems. Process APIs orchestrate the customer-portal flows. Experience APIs serve portal-facing consumers. New digital initiatives extend the same foundation rather than starting again.
Common Assets were applied from sprint one: Template API, Common Flows, Error Handler, Parent POM. These compressed the day-one effort for every API delivered and enforced a consistent operational pattern across the estate.
Five integrations live. A customer portal that works.
The first three integrations were originally scoped as medium-complexity. On discovery, Ampleshift identified that all three were better served as lightweight proxies and adapted scope accordingly, rather than delivering heavyweight integrations the operator didn't need. That is a senior-team instinct that saves time and budget.
Because that effort came in under estimate, scope was extended to two further customer-management integrations: create-client and edit-client, both delivered and live in production. These are now the integrations that power the operator's customer portal for client information management.
Five production APIs, a hybrid platform with HA, and an ELK observability stack, all in a 6-month engagement, handed back to a local team trained to extend it.
“A foundation case study is not the count of integrations delivered; it is whether the foundation that was built can be picked up and extended.”
What made this different
- Hybrid deployment expertise. The 4-server topology (two server groups for non-prod and prod, two MuleSoft Runtime servers each for HA and redundancy, plus a dedicated ELK server) was set up structurally from day one, not retrofitted. The platform was production-grade before the first integration shipped.
- ELK observability built in, not bolted on. Filebeat → Logstash → Elasticsearch → Kibana deployed alongside the integration platform from the start. End-to-end operational logging and traceability the legacy estate had never had, available to the local team from day one.
- Discovery-driven scope adaptation. Three medium-complexity integrations turned out on discovery to be better served as lightweight proxies. Ampleshift adapted scope on that finding rather than blindly delivering heavyweight integrations the operator didn't need, freeing budget to deliver two additional customer-management integrations instead.
- Capability transfer designed in from the start. In a market where senior MuleSoft skills are scarce, the operator needed to own and operate the platform independently. Training was built into the engagement from day one, not added at hand-off. The hybrid topology, the ELK stack and the trained team are all permanent assets.
The platform is the asset
A foundation engagement isn't measured by the count of integrations delivered. It is measured by whether the foundation built can be picked up and extended by anyone, including a small local team in an emerging market where senior MuleSoft skills are scarce.
Capability transfer was designed into the engagement from the start, not bolted on at the end. Training was delivered to the operator's in-house team during the programme. At hand-off, they owned the platform and operated it independently. The hybrid topology, the ELK stack, the API-Led pattern and the trained team are all permanent assets that outlast the engagement.
For incumbent telecommunications operators running digital transformation programmes in similar market footprints, a production-grade hybrid platform can be stood up in months, not years, by a senior boutique team that leaves the capability in your hands.
