You Do Not Have a Data Estate. You Have Copies of One.

Key Takeaways

• The numbers disagree because the data was copied – When three reports from one ERP show three revenue figures, look past the reports to the copies of the data between the source and the screen. That is where the fault usually is.
• Every copy is a tax, levied monthly – Storage and compute paid for again, a second set of permissions nobody reviews, a refresh that fails on month-end, a residency answer that no longer holds, and one more place from which the data can be taken.
• The copies were all reasonable decisions – Reporting could not run on production, the warehouse needed its own shape, the vendor needed a feed. Each was taken locally, by a competent team. Nobody owned the sum.
• A platform makes a copy unnecessary. Only a decision removes it – The estate that stops paying the tax is the one that counted its copies first and switched the losers off.

The board pack says revenue was R412 million. The finance dashboard says R408 million. The sales system’s own report says R415 million. All three began in the same ERP, and by the time anyone has traced why they differ the next pack is due. Trace it anyway: a nightly extract to a reporting server, a warehouse load, a Power BI import, an export to the spreadsheet the CFO actually trusts, and a feed to the CRM vendor, which keeps a copy of its own. Every record exists once in production and six times everywhere else.

We call this the copy tax: the recurring cost – in rands, in permissions, in staleness, in residency and in risk – of every additional copy of the same data made so that someone could report on it. It is levied monthly, it appears on no invoice, and in most estates nobody has ever added it up.

What each copy costs

The first cost is the obvious one. Every copy is stored again and refreshed again, on compute that is paid for again. A reporting server sized in 2019 and a warehouse sized for its peak month both run all year. Nobody has ever added the two together.

The second cost is permissions. The source was locked down by a DBA who knew what was in it; the extract was not. It sits in a database the DBA does not manage, readable by a reporting group that has grown for seven years and been reviewed never. In Sophos’s 2026 South African data, 85 percent of ransomware attacks coincided with the organisation’s most serious identity compromise. Every copy is one more place a credential that already has access can be pointed.

The third is disagreement. Copies drift – a refresh fails on month-end, a transformation is fixed in one pipeline and not the other, a spreadsheet is edited by hand – and the meeting that follows is spent reconciling numbers instead of deciding on them. An organisation cannot govern data it holds in six versions, and it cannot point an AI at it either: whichever copy the model is handed becomes its version of the truth.

The fourth is residency. A copy at a supplier is a copy under someone else’s controls, in whatever jurisdiction their cloud happens to sit. A fortnight ago I argued that data sovereignty is not an address – that September’s breaches reached regulated institutions through a copy of their customers’ identities held by a single South African vendor. Every copy multiplies the who question.

The fifth is the breach surface itself. Each copy is a database or a file that can be taken, and the copies are, by construction, the least watched things in the estate. In the month’s largest incident the policy databases of a life-insurance administrator were never touched. What left, by the provider’s own count, was some 400,000 records in files reached through a support-ticket system it was decommissioning – among them a list of 200,000 cellphone numbers gathered for an SMS campaign. The attackers took the copies and left the source alone.

Why the copies exist

None of this is incompetence. Every copy was a rational decision. Reporting queries were slowing production, so the data was extracted. The warehouse needed a star schema the source did not have, so it was transformed and loaded. The BI tool could only analyse what it imported, so it imported. The vendor’s platform needed the customer file, so the file was sent. Each decision was taken by a competent team solving its own problem. I have yet to see an estate where anyone was asked to own the sum of them.

The copy tax is the price of a generation of tooling that could only analyse data by moving it. That constraint has lifted, and most estates have not noticed.

Analysing data where it sits

Microsoft’s current data platform is built on the opposite assumption: one lake per tenant, and data read where it lives. The specifics matter, because none of these instruments is an add-on: they are the Fabric capacity itself, the same capacity Microsoft has been moving Power BI Premium estates onto as it retires the P SKUs.

OneLake is a single, tenant-wide lake, and in South Africa North every Fabric workload runs against it with storage that stays inside the border. Shortcuts point at data in another store, even in another cloud, and the data stays at its source. Fabric mirroring replicates operational databases continuously into OneLake – SQL Server 2016 to 2022 through change data capture, SQL Server 2025 through its native change feed, Azure SQL and Oracle alongside – and Microsoft charges nothing for the replication compute or for the mirrored storage up to the size of the capacity.

Direct Lake then lets Power BI read those tables directly, with no import and no scheduled refresh to fail on month-end.

The governance instruments are in place too. OneLake security, generally available this year, applies one set of row- and column-level rules whether the data is reached from SQL, Spark or a report. Customer-managed keys for Fabric workspaces are generally available. And Copilot in Fabric ships switched off for South African capacities, so sending prompts abroad is a recorded decision rather than an accident.

The pattern is simple. Production stays where it is, governed by the people who govern it today. One mirrored copy lands in a lake inside the country, secured once, read by everyone. The reporting server, the warehouse loads, the imports and the spreadsheet exports become unnecessary. The objective was never zero copies – an analytical workload will always want one. It is one deliberate, governed copy in place of six accidental ones.

Unnecessary is not the same as gone.

The copy you switch off

A platform makes a copy unnecessary; only a decision removes it. Left alone, a new lake becomes copy number seven and the tax goes up. The work that retires copies begins with a count: the ten datasets that matter most, and for each one every place it exists – who owns it, who can read it, what it costs, what it feeds, where it sits. Then one governed path is chosen for each and the rest are decommissioned in order, with the numbers reconciled before anything is switched off.

The dividend is not only a smaller bill, though it is that. It is one permission model instead of six, one residency answer, one set of numbers in the board pack, and a Fabric capacity sized for what the organisation uses rather than what it duplicates. It is Modernise, Optimise and Protect in a single motion – and the piece of AI readiness most organisations have not yet done.

How Ascent Delivers

Ascent Technology’s Microsoft Fabric Services cover the evaluation, migration planning, implementation, governance and ongoing optimisation of Fabric – but the discipline that shapes the work begins before any of them, with the count. Ascent’s consultants have spent two decades inside the production estates the copies are drawn from, so a Fabric engagement with Ascent starts at the source systems and works outward: which databases mirror, what mirroring asks of the source workload, which stores are reached through shortcuts, and which extracts and loads are retired in which order once the mirrored numbers reconcile.

Governance is built into the same design. OneLake security is set to reflect the access model the source owners already enforce, customer-managed keys are held by the client where policy calls for it, the capacity sits in South Africa North, and the Copilot cross-geo decision is written down for the board before the setting is touched. The sovereignty questions are answered in the platform, not in a policy document.

Ascent works on any Fabric tenant, however it is procured. Where the capacity is bought through Ascent’s Microsoft CSP, the partner sizing the capacity is also the one reading the invoice, and the copy tax comes off the invoice as well as the architecture. That is what Microsoft Fabric Services is for: turning a count of copies into one governed lake, and a much shorter list of places the data lives.

Contact Us

Contact Us to count the copies: one working session on your ten most important datasets – every place each one exists, who owns it, who can read it, what it costs and what it feeds – and which copies a mirrored, governed OneLake in South Africa North would retire first.

Also See

> Microsoft Fabric Services with Ascent Technology
> Data Sovereignty Is Not an Address
> AI Readiness Is Data Readiness

By: Johan Lamberts