Delay
Every change queued behind a vendor.
New sources, schema updates, and transformations were all gated by external timelines, not business need.
Case Study · Data Engineering & Infrastructure 07 / 07
Eliminating vendor dependency, pipeline control brought back in-house. .
Better Debt Solutions relied on a third-party wrapper that controlled every change to its data pipelines. The Zig migrated each ETL process onto infrastructure BDS owns directly, restoring control at the pipeline level.
Client
Better Debt Solutions
Microsoft FabricETL MigrationData Engineering
01 · The Setup
Better Debt Solutions runs an analytics-driven debt resolution business. Its data measures agent performance, tracks lead conversion, and shapes day-to-day operations. Sitting at the centre of that infrastructure was a third-party wrapper around Microsoft Fabric that managed every ETL process. Any change to a pipeline, any new data source, any transformation update, all of it had to route through the vendor. BDS could not modify its own pipelines.
02 · The Cost
The dependency was not a workflow inconvenience. It was structural.
Cost
Paying for an abstraction layer.
Fabric already supported the required workloads. The wrapper added cost without adding capability.
Risk
Pipeline ownership lived outside the business.
The data pipeline operated on vendor priorities, making external decisions an operational risk. A business decision at the vendor could become a business problem at BDS.
03 · The Migration
Same platform underneath. One layer of control restored.
Before
A vendor wrapper sat between BDS and its own data.
A premium price for an abstraction layer. The work could already run directly on Fabric.
After
BDS connects directly to the platform it owns.
Pipelines live where BDS can reach them. New sources ship the same day they're added.
04 · How We Built It
Audit. Extract. Rebuild. No disruption to live pipelines.
Each pipeline was understood end-to-end before it was rewritten. Cutover ran on a clean sequence, and the vendor contract cancelled within BDS's target window.
STEP 01
Audit
Mapped every pipeline running through the vendor wrapper end to end, including dependencies, data flows, and downstream consumers.
STEP 02
Extract
Extracted the transformation logic embedded inside the vendor layer, recovering how each pipeline actually operated.
STEP 03
Rebuild
Recreated each pipeline inside BDS’s environment using a metadata-driven notebook architecture, replacing rigid flows with reusable, parameterised execution.
STEP 04
Cut Over
Switched traffic to the new pipelines methodically. No live data flow was interrupted.
STEP 05
Decommission
Vendor contract terminated within the target window once all pipelines were operating independently. Migration was completed on time.
05 · The Outcome
BDS owns its data infrastructure outright.
01
Changes happen where the work happens
Pipeline updates are made directly inside BDS’s environment no external coordination required.
02
Data systems evolve continuously
New sources, transformations, and use cases are implemented as part of day-to-day operations — not scheduled vendor work.
03
Engineering effort compounds
Reusable notebook-based pipelines reduce duplication and make each new build faster than the last.
04
The platform is now an internal capability
Data infrastructure is no longer a managed service it’s something the team owns, understands and extends.
If you don’t control your pipelines, you don’t control your speed.
The Zig · Engineering Principle
Got a data problem
you want solved?
No slides, no theatre. An honest conversation about your environment, the problem you're trying to solve, and what it would take to get you there.