NGBLU is a Dutch telecommunications operator, part of Delta Internet, one of the largest telcos in the Netherlands. Years of growth had outrun the systems underneath the business: a fragmented ecosystem, a core that could not carry what was being asked of it, and no single place to run the operation from. We built the ERP that now runs it.
Rebuilding the platform was the visible half of that work. The hard half was the data underneath it.
A decade of live operational data does not sit still while you migrate it. Customers were being provisioned, invoices were being raised, and orders were moving through the old system every day of the project. The data also carried a decade of accumulated inconsistency: records entered before anyone wrote the rules down, fields that had quietly changed meaning, and exceptions that existed only in people's heads.
The tempting answer is to freeze the business, clean everything, and switch over. Nobody who runs a telco can afford that. So the migration had to happen while the operation kept running, and the data had to arrive correct rather than arrive fast.
We used the Strangler Fig pattern. Instead of a full rewrite with a big-bang cutover, the new system grew around the legacy core until the legacy core had nothing left to do.
New modules were built around the existing core, so value shipped before the migration finished. Data was cleaned, transformed, and kept in sync through shadow deployments, which let us prove correctness against live traffic before anything depended on it. Only then was the legacy system switched off.
One decision mattered more than the rest. Rather than cleaning data downstream forever, we built validation into the entry points, so bad records stop where they are created. For the legacy records that automation could not reach, we built front-end tools so the team could correct them by hand, with the domain knowledge only they had.
That is the difference between a migration and a data transformation. A migration moves what you have. A transformation changes what your systems will accept from tomorrow onward.
The platform runs against the systems the business already depended on: PortaOne for telecoms provisioning, AFAS for finance, and Microsoft SSO and IAM for identity and access. Nothing was replaced for the sake of tidiness.
The outcome: minimal downtime, data integrity through the cutover, and consistent business logic in one place instead of scattered across the estate.
This work predates our platform. There were no agents in it. We are publishing it because it is where the data transformation part of our groundwork came from, and because it settles a question every prospect is right to ask: has this team actually done the hard version of this before.
It also explains a position we hold that sounds unhelpful at first. We do not sell you a warehouse to migrate into, and we do not scope two-year data programmes. We fix the paths the work actually runs on, in delivery order, while the business keeps operating. Agents raise the stakes on all of it: a person compensates for a messy estate without noticing, and an agent cannot. Which is why the estate comes first, and the order matters.