Built by Monthos · Case Study
Monthos freed an entire legacy billing estate—over a thousand tables and years of documents—and made it queryable on a modern cloud platform, proven field by field.
Who this is for: telecoms, ISPs and any business sitting on a deep legacy database or document store it can no longer easily report on.
The client's billing system had grown over many years into a deep, complex schema. The data needed to run the business was all there—but it was effectively trapped:
The goal was straightforward to state and demanding to deliver: make every required data point reachable and queryable from a modern platform, and prove it field by field.
Monthos approached this as a data-engineering and reachability problem, guided by three principles:
Replicate first, curate later. Rather than attempting a slow, hand-mapped export, we loaded a complete replica of the source database into Supabase. With the full schema present, the vast majority of requirements became immediately reachable—and a curated, simplified layer could be built on top later without re-exporting anything.
Keep bytes and metadata together. Document files were mirrored from S3 into a Supabase Storage bucket, organised by their source-table prefix (emailed documents, customer document attachments, ticket attachments, generated reports). Each file stays addressable by its database id, so metadata in the database always resolves to the right object in storage.
Prove reachability field by field. Every requested reporting field was mapped to its backing table and column, verified against live row counts, and documented—so the client could see exactly where each data point comes from, what's fully resolved, and what needs a business decision.
The entire source billing database—1,161 tables, fully populated—was replicated into Supabase as the single source of truth. This backs almost every reporting requirement directly, with verified live row counts for each domain.
96,588 document objects were copied from S3 into a Supabase Storage bucket, organised by source-table prefix:
Files remain addressable by id within each prefix, so database metadata always resolves to the correct stored file.
A single export table proved a near 1:1 match for the entire revenue requirement: 256,214 rows covering the exact requested window of October 2023 to date. It resolves:
This sits alongside the full invoice ledger: 22,098 invoices and 251,243 invoice lines.
The PDFs actually sent to customers were recovered as their emailed copies: 24,852 invoice/statement emails, each linked through the email log to a stored attachment in the document bucket, dated through May 2026. Years of issued documents became retrievable without re-generating a single file.
A strong match across stock items (2,465), account-allocated stock (3,409), third-party inventory (3,324), warehouses (31), and stock history—covering serial/model numbers, type/condition/status, warehouse, customer allocation, ERP references, quote/order/job numbers, transfer and installation dates, supplier/PO/cost details, and transfer records.
Agent and dealer relationships (135 dealers), each dealer's customers, account types/segments, and legacy ERP billing references—mapped and confirmed with the business.
The complete document classification—document types, subtypes, and the vetting/compliance label set (ID, company registration, tax clearance, VAT, B-BBEE, bank statements, letter of authority, letterhead, and more)—was fully resolved from the platform's generic pick-list system. The same lookup mechanism resolves every other code-to-label field in the dataset (status, type, charge type, account type, and so on).
Replica-first architecture. Loading the complete source schema—rather than a slow, hand-curated subset—made the vast majority of requirements reachable immediately and removed the export workflow as a bottleneck. A curated, simplified layer can be backfilled directly from the replica when needed, with no external dependency.
Metadata-to-object integrity. Because files are stored by source-table prefix and id, every database reference resolves deterministically to its stored object, keeping document metadata and bytes in lockstep.
Generic lookup resolution. Decoding the source system's pick-list tables once unlocked human-readable labels for every coded field across the entire dataset—document types and compliance labels, but also contract status, ticket status, charge type, account type, and more.
Field-by-field reachability assessment. Monthos delivered a verified mapping of every requested reporting field to its backing table and column, with live counts—clearly separating what is fully resolved from the small set of fields that need a business definition before they can be reported.
This is legacy-system modernisation done pragmatically. Instead of a multi-year rebuild or a fragile hand-mapped export, Monthos made an entire legacy billing estate reachable on a modern cloud platform in its entirety, then proved coverage requirement by requirement.
For any organisation sitting on a deep legacy database it can no longer easily report on, this is a proven, fast path to making that data work again.
Sitting on a legacy database or document store you can no longer easily report on? Monthos can make that data reachable, queryable, and useful again—fast.
Talk to Monthos →
Case study prepared for Monthos.com · Project: Telecom Billing Data Platform.
Monthos Group — Cheltondale, Johannesburg, SA. Email info@monthos.com, phone +27 (68) 750 7313.
Case studies · Privacy Policy · Terms of Service