Two Million Files and One Very Stubborn Department: Notes From a Company-Wide Migration
Photo: Donald Trung Quoc Don (chữ Hán: 徵國單) - Wikimedia Commons, CC BY-SA 4.0, via Wikimedia Commons
The email went out on a Tuesday in early March. 'Effective Q3, Meridian Fabrication Solutions will consolidate all document storage onto a single platform.' Two hundred employees, four offices, and — though nobody knew it yet — roughly two million files standing between the executive team and their deadline.
What follows is a composite account drawn from the migration experiences of mid-market companies across the United States. The names are fictional. The problems are not.
Phase One: The Spreadsheet Nobody Finished
The IT director's first task was inventory. The theory was simple: list every file share, map its contents, migrate in order of business priority. The reality was that Meridian's document landscape had grown organically for fourteen years. There was the official server. There was the 'temporary' SharePoint site from 2019 that had become load-bearing. There were at least six personal cloud accounts used for business files, discovered only when employees mentioned them in passing.
The inventory spreadsheet, originally scoped for two weeks, consumed six. This is the first lesson vendors rarely mention: you cannot migrate what you have not found, and discovery always takes longer than estimated. Budget accordingly, and treat undocumented storage as a certainty rather than a risk.
Phase Two: The Permissions That Made No Sense
Migrating files is mechanical. Migrating access rights is archaeology.
Meridian's legacy permission structure included a folder granting edit access to a group called 'Temp Staff 2016' that still contained three active accounts. A finance directory was readable by the entire sales team for reasons no one could reconstruct. One department had solved a permissions dispute years earlier by creating seventeen near-duplicate folders with slightly different access lists.
Migration forces a reckoning with this accumulated debt. The pragmatic approach Meridian eventually adopted: migrate content, but rebuild permissions from role-based templates rather than replicating legacy structures. Accept that some users will complain about lost access. Verify each complaint rather than restoring old permissions reflexively — most 'missing' access was access that never should have existed.
Phase Three: The Department That Refused
Engineering never switched. Officially, they were 'in progress' for four months. In practice, they kept working in their legacy file structure, arguing — not entirely unreasonably — that their CAD files and project archives were too large, too interdependent, and too business-critical to risk.
This is the phase where migrations quietly fail. An department that won't move becomes a shadow system, and shadow systems become the new normal. Meridian's eventual solution was neither mandate nor surrender: they assigned a senior engineer as the department's migration owner, gave the group a dedicated cutover window with IT support on standby, and agreed to a phased move starting with read-only archives. Full adoption took another quarter. It worked because it gave the holdouts control over pace without giving them a veto over the outcome.
Phase Four: The Weeks After Cutover
No migration ends at cutover. For roughly a month, Meridian operated in a state of low-grade confusion: broken spreadsheet links, employees emailing files they previously accessed directly, and a steady stream of 'where did everything go?' questions. The companies that navigate this period well invest in floor-level support — a designated person in each office answering questions in real time — rather than relying on ticket queues.
What Meridian Would Do Differently
In the retrospective, the IT director's list was candid. Start discovery earlier and assume it will double. Rebuild permissions instead of copying them. Identify the holdout departments in week one, not month four. And treat the month after cutover as part of the project, with dedicated budget and staffing.
Migrations are not product installations. They are organizational change projects that happen to involve technology. Companies that plan for the human friction — the stubborn departments, the broken habits, the archaeology of old permissions — finish. Companies that plan only for the technical migration restart their timelines in Q4, again.
