No business sets out to build reporting on top of dozens, or even hundreds, of separate data sources. It happens the way most operational sprawl happens: one reasonable decision at a time, made by different people, at different points, none of them thinking about the total picture that would eventually exist.
A spreadsheet gets built because the "official" system doesn't handle one product line well. A database gets stood up for a specific project and never decommissioned. A file sits on someone's local drive because it was the fastest way to get a one-off analysis done three years ago, and it's still being referenced today. None of these are bad decisions in isolation. Added together, across a business that's grown for years, they become something genuinely risky. Most businesses have no accurate idea how risky, because nobody has ever counted.
Start with the path to the decision
A source inventory is useful only when it follows the information all the way to a decision. Begin with one report the business relies on, then trace each measure backwards: the visual, the dataset, the transformation, the file or application, and the person or account that allows the connection to run. That path often contains more steps than the report owner expects.
Include the manual steps. An emailed extract, a copied tab and a monthly file rename are part of the reporting system even if no architecture diagram shows them. These steps explain why a report can refresh successfully and still contain last month's information.
Why counting the sources matters more than people expect
Every separate data source feeding a report is a separate credential, a separate refresh schedule, and a separate point where something can quietly go stale or break without anyone noticing immediately. A report built on four sources has four places to check when something looks wrong. A report built on dozens has dozens, and in practice, nobody actually checks all of them, so problems sit undetected until they're large enough to be obvious.
Credentials also have owners and lifecycles. People change roles, passwords expire, licences are removed and security settings tighten. When a personal account quietly supports a business report, an ordinary staffing change can become a reporting outage. Recovery then depends on someone knowing which connection used that account and how it was configured.
This isn't a hypothetical concern. It's the pattern behind a genuinely current conversation I'm having with a business assessing this problem: reporting built across a very large number of disconnected sources, each with its own credential, feeding into Power BI without a single governed location behind any of it.
The argument for one governed location
The case for consolidating onto a single, governed data location isn't really a technology argument first. It's a risk-reduction argument: fewer places for a "version of the truth" to exist means fewer credentials to manage, fewer refresh schedules to monitor, and one place to fix when something breaks, instead of a scavenger hunt across dozens of systems.
Microsoft Fabric is one option businesses are increasingly considering for this kind of consolidation, bringing fragmented sources into a single platform that then feeds reporting tools like Power BI from one place, rather than many. I'll be upfront: this is an area of active learning for me rather than delivered experience, and I'd rather say that plainly than imply otherwise. What I can speak to with confidence is the underlying pattern of fewer sources, fewer credentials and one place to trust, because that's a genuine information-architecture problem independent of which specific platform ends up solving it. It sits squarely in our data engineering, Fabric and AI readiness work.
Consolidation does not mean copying everything into one pile
A governed location still needs boundaries. The business must decide which source remains authoritative, how often it is updated, who can change definitions and how errors return to the source system. Copying conflicting data into one platform without those decisions creates a larger place to argue about the same numbers.
Start with the reporting products carrying the most operational or financial consequence. Stabilise their sources, replace personal credentials with managed connections where possible, and record the owner and refresh expectation. Retire duplicate extracts only after users have confirmed what they still need from them.
What to record for each source
For every source, capture its business owner, technical owner, location, access method, refresh frequency, downstream reports and the effect of failure. Note whether the source is authoritative or a copy, and whether the connection depends on an individual account. This produces a practical risk register rather than a list of file names.
The exercise also reveals duplication. Two extracts may carry the same customer or asset data under different names, with different update times and different local corrections. Removing one connection is useful; agreeing which definition survives is the real work.
What consolidation actually changes
The value isn't just tidiness. It's that a governed single location makes data ownership and stewardship possible in a way that dozens of disconnected sources never can, because someone can be accountable for one thing, rather than everyone being informally, partially accountable for their own corner of a much larger, invisible sprawl.
It also removes a specific, quiet risk: the version of the report that's out of sync with everything else, because it's the one source nobody remembered to update. That risk doesn't announce itself. It just sits there until the day it causes a genuinely confusing, hard-to-diagnose problem.
Reduce the highest-risk dependency first
The first move does not have to be a platform programme. Find the report with the greatest business consequence and the weakest source path. Replace the personal credential, document the refresh, add a visible failure alert and confirm who owns the underlying data. That gives the business a safer report while the wider architecture is still being decided.
What to check this week
| Question | If the answer is concerning |
|---|---|
| Do you know, with real confidence, how many separate sources feed your key reporting? | Most businesses don't; that's the first thing to fix |
| How many separate credentials would someone need to fully reproduce your main report from scratch? | A high number is a genuine, quantifiable risk, not just an inconvenience |
| If one source went stale or broke, would anyone notice before it caused a visible problem? | If not, that's an unmonitored point of failure sitting in your reporting today |
Where to go next
The Source Fragmentation Check is still being written. Until it's published, count honestly: list every source feeding your main report and every credential needed to reproduce it. Whatever platform eventually addresses it, counting honestly is the first useful step, and it's one you can do this week regardless of what comes next. If the count worries you, get in touch.