Work our team has delivered · SHIPPING · SOFTWARE PLATFORM
A Fabric migration that turned a shipping platform’s data into a product its customers pay for.
A shipping software platform held a decade of operational data it couldn’t serve the way enterprise customers wanted. In six months, our team moved 2,000+ source tables to Microsoft Fabric and launched data products for each customer. Analytics query throughput rose 10×, and the platform now sells a data tier that didn’t exist before.
↳ Some of this work was delivered by Reenva's founder and team before Reenva was formed. Client name withheld; some commercial figures shown as bands.
/01 · What changed
10× analytics query throughput, and a new revenue line the platform now sells.
A decade of operational records now works as a product. Each of the platform’s customers gets its own data and reports, in a paid tier that did not exist before.
10×
Analytics query throughput, compared with the old data pipeline
2,000+
Source tables moved, with both scheduled and real-time loading
<2s
Analytics response time for 95% of queries on warm data (was 8–22s)
6mo
From kickoff to data products live with the platform’s customers
/02 · The problem the team was asked to fix
The platform held a decade of operational data across more than 2,000 tables. The data existed. It just couldn't be served at the scale, or in the shape, that enterprise customers wanted.
Reports ran against the live application database, so large customers' queries timed out on any real filter. The old pipeline copied data to a reporting store overnight. That was fine for yesterday's view, but useless for today's.
The bigger gap was commercial. Enterprise customers kept asking for two things: their data in their own warehouse, and anonymised benchmarks against other customers. The platform could only say yes by hand, slowly, at a cost that didn't pay for itself.
Why adding a reporting tool wouldn't fix it
A reporting tool on top of the old database would have shipped fast, then hit the same limits. The data had to become a product in its own right. That meant a platform built for the workload, with each customer's data kept separate.
/03 · How the team worked
The team worked inside the platform’s own engineering group and turned a migration into a product launch.
The team’s engineers did not arrive with a fixed design. They worked inside the platform’s engineering and sales teams to find the result worth six months of work.
- 01 · Inside the platform team
The team mapped the data from how the product used it.
Working with the platform’s data and engineering team, the team mapped 2,000+ source tables from real usage, not documents. They also sat in on enterprise sales calls. Customers kept asking for something the platform couldn’t yet give.
- 02 · Show the revenue
Leaders saw the revenue, not just the speed.
The easy brief was “make the reports faster.” The team also sized the enterprise deals stalled on “give us our data in our own warehouse.” That turned a cost-centre migration into a commercial programme the board backed.
- 03 · Re-engineer the model
Customer data was kept apart by design, before a single table moved.
Everything depended on how each customer’s data was kept apart. The team redesigned that model first, then moved the data onto it. That let the platform sell a product, not just show a dashboard.
Six months later, the real result was the data-product tier the platform now sells to its customers.
/04 · The cost, in numbers
The data existed. Customers couldn’t get it fast enough, or in the shape they wanted.
Reports ran against the live application database, so large customers’ queries timed out. The team measured the gap before choosing how to move.
↳ The team measured these figures before and after the move.
Reconstruction · platform telemetry, before and after
- Source tables in scope across the application and nearby systems
- 2,000+
- Loading pattern: scheduled batch vs near-real-time
- ~70% batch · ~30% real-time
- Main business areas covered, including finance, compliance and operations
- 4 areas · 11 sub-areas
- Analytics response time before (95% of queries)
- 8–22s
- Analytics response time after (95% of queries)
- <2s on warm data · <4s cold
Source: anonymised platform telemetry, before and after the move. Figures shown as bands; client details withheld. Response times measured on a representative customer analytics workload.
/05 · What the team did
Measure the cost first, fix the process, then build.
- /01
Diagnose.
Six weeks mapping every source: the application database, nearby finance and compliance stores, and the old data pipeline. The team sorted all 2,000+ tables by business area, by customer and by how each was actually used. The result was the first reliable map of what existed and what customers wanted.
Delivered: a full source inventory and a step-by-step move plan
- /02
Prepare the data.
Everything moved into one store on Microsoft Fabric. Each customer’s data was kept separate, and regulated data was kept apart more strictly. Each metric was defined once, with a clear owner and every change tracked.
Delivered: 2,000+ tables moved, with each customer’s data kept separate
- /03
Build.
Data products went live as data feeds and reports inside the platform. Each customer sees only its own data. The team also added finance and compliance reconciliation agents, and a plain-English chat assistant.
Delivered: customer data feeds, in-product reports, reconciliation agents and a chat assistant
- /04
Run and improve.
The team tuned capacity against the first month of real customer traffic. Heavy workloads were separated, and scheduled loads moved outside peak hours. Automatic checks stop changes in the application from breaking customer reports.
Delivered: capacity tuned to real traffic, automatic data checks and a weekly scorecard per customer
/06 · Technology the team used
Data layer
- Microsoft Fabric, with OneLake as the single store
- Azure Event Hubs and Fabric Eventstream (real-time feeds)
- Azure Data Factory and Fabric notebooks (scheduled loading)
- dbt for shared metric definitions
- Each customer’s data kept separate (row-level security)
What the team built
- Reconciliation agents for finance and compliance (Azure OpenAI)
- Customer-facing chat assistant, answering from the shared data model
- Data-product gateway with sign-in for each customer
Reporting layer
- Power BI Embedded, styled to match the platform
- Data feeds for each customer (API)
- Anonymised benchmark views across customers
- Internal monitoring of workload, cost and service levels per customer
/07 · What changed for each team
Sales floor
The platform’s sales team finally had something concrete to sell to enterprise customers. Embedded reports and data feeds became a tier customers asked for by name.
Operations
The internal data team stopped writing one-off reports for customer questions. The chat assistant answers routine questions from the platform’s customer-facing staff. Reconciliation agents now run finance and compliance checks that used to be manual.
Board
The data-product tier gave the platform a new revenue line. The cost of serving analytics is now tracked for each customer.
“We had the data for years. What we didn't have was a way to put it in front of our customers that wasn't a screenshot or a CSV. Six months later it's an endpoint they pay for.”
/09 · Your next step
Facing the same problem? Find out what fixing it would take.
If there is a fit, a two-week fixed-fee review follows, ending in a clear go or no-go.