A SharePoint analysis tool can look great in a small test tenant and behave very differently once it meets years of real organizational data.
That is why scale has been part of CBITS Lens development from the beginning.
We have used Lens against environments spanning hundreds of SharePoint sites and more than a million current files. At that size, the job is no longer simply to retrieve metadata. The product has to organize a large amount of information into something useful while keeping repeated analysis practical.
Inventory the environment, not just a sample site
Storage decisions are difficult to make from a handful of libraries. A tenant can have one site dominated by active project files, another filled with long-inactive content, and another where version history is the bigger story.
Lens inventories across SharePoint sites and document libraries so the report can describe the environment as a whole. Current files are then grouped into age bands that make inactivity visible without requiring someone to manually inspect hundreds of locations.
That turns a sprawling tenant into a set of questions an administrator can actually act on.
Make repeated scans smarter
Lens maintains a local analysis database and uses an upsert-based workflow when a scan is run again. The scanner still verifies the SharePoint environment, but it does not have to treat every run as though the application has never seen the tenant before.
That architecture gives us a foundation for faster repeat analysis and for comparing an environment as it continues to grow.
For a product intended to provide ongoing visibility, repeatability matters just as much as the first scan.
Keep the output executive-friendly
A million-file inventory is impressive technically, but nobody wants a million-row report.
Lens condenses the scan into the measures that are useful for planning: sites, libraries, files, current storage, inactivity by age, measured version-history data, estimated archive opportunity, and potential cost impact.
The report also separates current-file measurements from version-history estimates so a reader can understand where the numbers came from rather than receiving a single unexplained savings figure.
Optimize the expensive parts
Large tenants also made it obvious where optimization mattered most. Enumerating current content and measuring historical versions have very different costs, so Lens does not force them into the same scanning strategy.
Current files are inventoried broadly. Historical versions are sampled and measured strategically. That lets the scanner spend more effort on the information that changes the quality of the answer.
We have continued to refine that balance as we validate Lens against larger environments.
Build for the environment customers actually have
The most valuable development work on Lens has come from testing against real Microsoft 365 complexity: many sites, many libraries, large files, deep version histories, and years of accumulated content.
Those environments are exactly where storage visibility is hardest to get manually — and where a purpose-built analysis tool is most useful.
For us, supporting scale is not about putting a large number on a feature list. It is about making sure Lens remains useful when the SharePoint environment is too large to understand by inspection.