The Folder Mistake That Breaks SharePoint — and the Fix That Changes Everything
The tools you're already paying for, finally put to work.
I want to tell you about a client we worked with a few years back.
They were a medical device company — solid business, serious R&D operation, decades of institutional knowledge living on their file server. When they decided to move into Microsoft 365, they did what a lot of companies do: they handed the migration to their server administrator. Competent guy. Knew their infrastructure inside and out. Had managed their file server for years without a single problem.
He did what made complete sense to him. He took the entire server — all four terabytes of it — and copied it into SharePoint.
The uploads completed. No errors. SharePoint accepted every file without complaint. And then almost immediately, the whole thing stopped working.
Nobody could find anything. Files that should have been there weren't showing up. The company thought they had a failed migration. They started preparing to redo the whole thing from scratch.
They didn't have a failed migration. They had a folder problem — two of them, actually. And understanding what went wrong is the single most important thing I can tell you before you put a single file into SharePoint.
The Thing Microsoft Doesn't Warn You About
SharePoint has a 400-character limit on the full URL of any file stored in the system.
Every folder you create adds its name to that URL. A deep folder structure — the kind that grows organically on a file server over fifteen years — can look something like this:
/SiteName/DocumentLibrary/Department/Year/Project/SubProject/Phase/Draft/FileName.docx
Add up those folder names and you can hit 400 characters without even trying. When you do, here's exactly what SharePoint shows you: an empty folder. No warning. No error message. No indication that anything is wrong. Just an empty folder, sitting there as if the files never existed.
That's what happened to this client. The files were there the whole time. SharePoint had simply stopped showing them because the paths were too long. They spent weeks assuming something had broken during the migration. Nothing had broken. The folder structure itself was the problem.
And then there was the storage.
A Microsoft 365 tenant comes with 1 TB of SharePoint storage plus 10 GB for every licensed user. For a company with 50 users, that's 1.5 TB total. Four terabytes of files from a file server will exceed that quickly. SharePoint doesn't shut off when you hit the limit — it just starts asking you to buy more. Additional SharePoint storage runs about $0.20 per gigabyte per month. One extra terabyte: roughly $200 a month, $2,400 a year. In this case, for files nobody could even get to.
The storage cost problem is one reason getting the right Microsoft 365 plan matters before you start building.
I spent six weeks with that client untangling the mess, rearchitecting the whole thing, and rebuilding it the right way. It was completely avoidable.
Why This Keeps Happening
The server administrator in this story wasn't careless. He was experienced and well-intentioned. He looked at SharePoint, saw something that resembled a file system, and did what you'd do with a file system: he copied the files over.
That's the trap. SharePoint looks enough like a file server on the surface — folders, files, drag and drop — that people don't ask questions before they start building. And Microsoft, to its credit, makes everything as easy as possible. The uploads just work. Until they don't.
The file server mental model is the problem. Because SharePoint isn't a file server. It's a document management platform, and the difference matters more than most people realize until something breaks.
It's also one piece of a larger platform — understanding Microsoft 365 as a platform rather than a collection of apps is what makes the SharePoint decision make sense.
You Already Know How This Works — You Just Don't Know It Yet
Look at a typical folder structure on a file server:
Invoices / 2025 / Vendors / Pending
Now look at what you've actually done there. You've described four things about every document in that folder: it's an invoice, it's from 2025, it's vendor-related, and it's pending. That's metadata. You had it all along. You just encoded it vertically — in a structure you have to physically navigate — instead of storing it as searchable, filterable attributes on the document itself.
File servers build a vertical structure. SharePoint is horizontal. All the information you need is inline, visible at a glance, filterable with a click.
And here's something worth thinking about: you already use metadata every single day. You just don't call it that.
Think about the last time you searched for something on Amazon. You type in "men's running shoes" and get thousands of results. Then what happens? A refinement panel appears. Size. Color. Brand. Price range. You start selecting, and the results narrow instantly to exactly what you're looking for.
Every one of those filters is metadata about a shoe. Amazon didn't organize its entire inventory into folders. It tagged every product with attributes and built a system that lets you filter to what you need in seconds. That's exactly what a well-built SharePoint library does with your documents.
The folder version of Amazon would be a nightmare. Nobody would shop there.
Why You Can't Have Both
This is the part that trips people up the most, and it's worth being direct about it.
SharePoint views filter against metadata columns at the library level. Files sitting inside folders don't participate in those filters the way flat files do. When you build a view that shows all Pending invoices filtered by vendor, it's working against the metadata on files stored directly in the library. Files buried inside a folder structure don't surface reliably in those filtered views — they're scoped to the folder, not to the library.
The practical result: if you try to run a hybrid approach — folders for some things, metadata for others — the views don't work as advertised. You end up with a filtered view that looks incomplete because half your documents are inside folders it can't see through.
This is why the architecture decision matters before you put a single file in. Folders and metadata aren't two tools you can mix and match depending on what feels comfortable. They're two fundamentally different organizational models, and SharePoint is built to do one of them well.
How to Build It the Right Way
When we rebuilt the medical device company's SharePoint environment from scratch, we started with three questions that should precede every SharePoint build: what types of documents does this organization actually have, what do people need to find them by, and what does a completed or archived document look like?
The answers shaped everything — starting with how we organized their libraries.
Start with libraries, not folders. A SharePoint document library is a container for like documents that share the same metadata. That last part is the key. Invoices have vendor names, amounts, due dates, and payment status. Project documents have project numbers, phases, owners, and completion status. Purchase orders have supplier names, order dates, and approval status. Those are completely different sets of attributes — and trying to build one library with metadata columns for all three would be an unmanageable mess.
So you don't. You build an Invoice library. A Project Documents library. A Purchase Orders library. Each one is a clean, purpose-built container for a specific type of document, with metadata columns that actually make sense for what lives there. You know what's in a library before you open it, and the columns inside it describe exactly what you need to know about those specific documents — nothing more, nothing less.
That structure is what makes everything else work. Libraries are where the organization happens. Folders just get in the way.
Replace subfolders with metadata columns. Instead of creating a folder called 2025 with a subfolder called Vendors and another called Pending, you add columns to the library — a Year column, a Vendor column, a Status column. Same information your folder structure was encoding, now stored horizontally, filterable instantly, visible without navigation.
Once your library structure is right, the next habit to break is attaching files to emails instead of sharing links.
Use Views to get laser focus. Say your Invoice library has a Status column: Pending, Approved, Rejected. In the folder world, moving an invoice through the approval process means physically moving the file. In SharePoint, you change the tag. The file never moves. Build a View called Pending Invoices that shows only documents where Status equals Pending — one click from the library header, nothing else in frame.
There's also a speed argument most people don't consider until someone points it out. Navigating a folder structure in SharePoint isn't free. Each time you click into a folder, the page reloads. Five folders deep means five page loads every single time. A view is one click and an instant filter. Across a team of ten people over the course of a workday, that time adds up fast.
What to Do With 15 Years of Historical Data
This is where most migrations stall. The architecture question gets answered, the team agrees metadata is the right model — and then someone points at four terabytes of files from fifteen years of closed projects and asks what happens to all of that.
The answer isn't to put it all in SharePoint.
The majority of this client's four terabytes was historical. Closed projects. Documentation from engagements that had wrapped years ago. Occasionally someone needed to reference an old file, or a project that had been on hold for two years was being resumed and its files needed to come back into active use. But most of it sat untouched for months at a time.
SharePoint storage at $0.20 per gigabyte per month is the wrong answer for data that's barely being accessed. We built them an Azure File Share instead.
Azure File Share is Microsoft's cloud-hosted file storage — fully within the Azure ecosystem, accessible from Windows just like a mapped network drive, and priced for archival workloads. Standard HDD storage in a cool access tier runs approximately $0.06 to $0.07 per gigabyte per month. For the same terabyte that costs $200 a month in SharePoint, Azure File Share brings that down to roughly $60 to $70. For two terabytes of historical data, the difference is $2,400 to $3,000 a year in storage costs that simply disappear.
The rule we set up was straightforward: closed projects and historical files live on the Azure File Share. If a project is resumed after being on hold, its files move back into SharePoint where the metadata model and views apply. When the project closes again, it archives back out. Only current working files live in SharePoint, with enough overhead built in for growth without constantly hitting the storage ceiling.
We reduced their effective SharePoint storage footprint from four-plus terabytes down to about two — current working files plus room to grow. The rest landed on Azure File Share at a fraction of the cost.
This is also the answer to the migration path question. You don't have to move everything at once, and you shouldn't. Pick a timeframe — six months of active files, one year, whatever makes sense for how your business works. Get the architecture right in SharePoint and migrate only the current working files. Everything else stays on the file server as an archive, or if you're decommissioning file servers entirely, an Azure File Share is a clean and cost-effective landing spot.
Build the foundation right first. Move the rest when the model is proven.
Frequently Asked Questions
We already have SharePoint set up with a folder structure. Do we have to start over?
Not necessarily — but you do need an honest assessment of what you have before adding more to it. If your folder paths are already deep and you're hitting URL limit issues, a rebuild is usually faster than trying to reorganize in place. If your structure is shallow and your team is small, a migration to metadata columns is achievable without starting from scratch. The answer depends on how entrenched the current structure is and how much pain it's already causing.
Can we use both folders and metadata columns in the same library?
You can create both, but it undermines the whole model. Views filter against library-level metadata — files inside folders don't surface reliably in those filtered results. Once you've built the metadata foundation and the views that filter against it, folders add navigation cost without adding any organizational value, and they break the thing that makes SharePoint actually useful. Commit to one approach. The metadata approach is the one that scales.
What if my team resists moving away from folders because that's what they know?
Show them a filtered view. Take the thing they look for most often — a document type, a status, a vendor — build a view that shows only that in two seconds, and put it next to four folder levels and four page reloads getting to the same result. Most people convert quickly. The resistance is almost always about familiarity, not genuine preference for folders. Once someone finds a document in ten seconds that used to take five minutes, the conversation is over.
If you're planning a move to SharePoint — or if your SharePoint already looks like a file server with folders nested inside folders — the architecture conversation needs to happen before anything gets built or migrated.
The two questions worth asking before you create a single folder:
Would this be better as a separate library?
Would this be better as a metadata column?
Most of the time, the answer to both is yes.
Get those two things right and SharePoint becomes a genuinely powerful tool. Get them wrong and you'll be calling someone like us to spend six weeks fixing it.
Accurate as of March 2026. Microsoft updates its products and pricing regularly.
J. Scott Clark is the President and CEO of The 365 Collective, Inc., a Microsoft 365 consulting and training firm serving small and mid-sized businesses across healthcare, finance, construction, engineering, publishing, and retail.