How A File Server to SharePoint Migration for a 120 Employee Fundraising Consultancy Delivers 75% Faster Client Site Setup

A case study on moving 6 TB of active client and department content off an aging file server and into SharePoint Online, while redirecting 2 to 3 TB of archival content to Azure Blob Storage’s lower cost Cool access tier, all without breaking a decade of client-specific permissions along the way. 

Executive Summary

A fundraising and grant consulting firm with approximately 120 employees, serving roughly 240 active nonprofit clients, was running its entire operation off a file server that had grown for years without a consistent structure. Code Creators completed a file server to SharePoint migration covering 6 TB of active department and client content, while redirecting 2 to 3 TB of archival content inside client folders to Azure Blob Storage archival tier, keeping it off premium SharePoint capacity entirely. A structured migration mapping sheet preserved the firm’s one-to-one file server group permissions by translating each group into a corresponding Microsoft Entra ID or Microsoft 365 group, and a trial migration validated the approach before full cutover. New client site provisioning, previously a manual, folder-by-folder process, dropped from about 3 hours to roughly 45 minutes, a 75% reduction. The project ran 14 weeks from discovery through post-migration validation. 

About the Client

The client is a fundraising and grant consulting firm with approximately 120 employees, supporting around 240 active nonprofit clients with fundraising strategy, grant writing, and donor data services. Because the firm provides fundraising services to other nonprofits, its file structure had grown around individual client engagements: a dedicated dedicated SharePoint client portal, for every client, each holding proposals, donor data extracts, grant reports, and correspondence going back years, alongside separate department folders for internal operations. 

That client-by-client structure is exactly what made the file server difficult to govern. Every new client engagement meant manually recreating a folder structure and permission set from scratch, every completed or paused engagement left behind a folder nobody was actively maintaining, and access to sensitive donor and financial data depended entirely on file server security groups that had accumulated inconsistencies over a decade of staff changes. 

The Problem

By the time this project began, the client file server held roughly 12.6 TB across three categories: 819.7 GB of internal department content, 7.4 TB of client-specific content, and a further 4.4 TB that stayed out of scope for this migration entirely. That excluded volume was made up of duplicate copies flagged during the audit, orphaned files with no identifiable owner or intact permission record, and legacy backups the firm already retained through a separate process, none of which needed to move to either SharePoint Online or Azure Blob Storage. Inside many client folders sat a subfolder labeled “Archive,” together holding an estimated 2 to 3 TB of older engagement records the firm needed to retain but rarely opened. 

The core issue was that all of it, active and archival alike, sat on the same expensive primary storage with no tiering strategy. A grant report from a client engagement that ended three years ago costs exactly as much to store as a proposal due tomorrow. On top of the storage cost problem, the file server had accumulated the kind of structural debt that builds up over a decade of manual folder management: long file paths that failed to open or sync correctly, duplicate files left behind by repeated manual copies, inconsistent naming conventions across client folders, and permission inheritance that had broken in enough places that IT could no longer be fully confident about who had access to which client’s sensitive data. 

Provisioning a new client site was a manual, error-prone process. A staff member had to recreate a folder structure from a rough template, then individually configure file server group permissions, a process that took roughly 3 hours per new engagement and left plenty of room for a misconfigured permission to go unnoticed until it caused a problem. 

What We Discovered

Before migrating a single file, Code Creators ran a structured source data audit against the file server to understand exactly what needed to move, what needed to be remediated first, and what could be redirected to lower-cost storage entirely. 

Source Data Audit and Migration Readiness Assessment

We audited the file server to confirm actual data volume, folder depth, file types, naming patterns, and permission structures against what the client believed was there. The audit flagged the specific technical issues that break migrations if left unaddressed: long file paths, unsupported characters, invalid file names, duplicate files, locked files, oversized files, empty folders, broken permission inheritance, and restricted folders that needed special handling. Folders labeled “Archive” inside client folders were identified separately during this pass, since they were the primary candidates for redirection to Azure Blob Storage archival tier. 

Migration Mapping Sheet Preparation

We built a migration mapping sheet as the control document for the entire project, defining three levels of mapping: site level mapping, translating top-level department and client folders into their corresponding SharePoint department sites and client sites; library level mapping, determining whether a given subfolder became its own document library, stayed as a folder inside a library, or merged into a broader library structure; and permission level mapping, defining exactly which source file server group corresponded to which target Microsoft Entra ID or Microsoft 365 group, and at what SharePoint permission level. 

Archive Data Identification

Archive folder paths, estimated volume, folder owners, and permission considerations were documented in the same mapping sheet, giving the firm one place to review and approve both the SharePoint Online migration scope and the Azure Blob Storage archival scope side by side, in a single coordinated view.

The SharePoint Online and Azure File Storage Migration Solution

The objective of this file server to SharePoint migration was to move active content into SharePoint Online where staff could collaborate on it, move archival content to Azure Blob Storage’s Cool access tier where it would cost far less to retain, and do both without breaking the client-specific permissions the firm depended on to keep donor and financial data properly restricted. 

We executed the migration in three stages. A trial migration ran first, using one representative client site approved by the firm, validating that the mapping sheet’s site, library, and permission logic actually worked in practice before committing to full-scale migration. Once the trial was validated and the mapping sheet formally approved, full migration executed for all approved active content, moving 6 TB of department and client data into SharePoint Online according to the approved site and library structure. An incremental migration followed cutover, capturing any files that had changed on the source file server during the migration window itself, so nothing edited mid-migration was lost. 

In parallel, the approved archival content, an estimated 2 to 3 TB drawn from the “Archive” subfolders inside client sites, migrated to a purpose-designed Azure Blob Storage container in the Cool access tier, organized by client and archive year, with the original folder paths preserved as blob prefixes so the structure stayed recognizable even after the move. A lightweight SharePoint list logs every archived file’s original path, client, and archive date, so staff can search for whether and where something was archived even though the file itself no longer lives in SharePoint.  

As an additional workstream, we designed a data archival automation flow that flags files unmodified for 12 months based on their SharePoint last-modified date, routes each flagged batch to the folder owner for a quick approval, and only then moves the approved files to Azure Blob Storage automatically, so the storage tiering problem that built up over a decade doesn’t quietly start rebuilding itself six months after go-live. When someone needs an archived file back, a simple retrieval request triggers a flow that copies it from Blob Storage into the relevant SharePoint client site, typically within the same business day, since the Cool tier avoids the multi-hour rehydration delay that colder storage tiers require.

Post-migration validation closed out the project: reviewing migrated content, spot-checking files and folders against the mapping sheet, validating that content landed in the correct site and library, reviewing migration logs for errors, and confirming that restricted permissions carried over correctly for sensitive client folders. 

Challenges Overcome 

Preserving a decade of client-specific permissions without carrying legacy errors forward  

The file server’s one-to-one group structure meant every client site’s access depended on a security group that may or may not have still reflected who actually needed access. Code Creators addressed this by treating permission level mapping as its own formal, documented step in the mapping sheet, defining the intended Microsoft Entra ID or Microsoft 365 group and permission level for every single source group before any content moved, so the client’s IT team approved each mapping deliberately and closed out a decade of drift in the process. 

Separating archival content from active content without slowing down the migration  

Not every “Archive” folder actually belonged in Azure Blob Storage and misjudging that split would have meant either paying premium SharePoint storage rates for content nobody uses or accidentally archiving something a client team still needed. Code Creators addressed this by documenting every archive folder’s estimated volume, owner, and business purpose in the mapping sheet during the audit phase, giving the firm one clear, reviewable list to approve or adjust before a single file moved. 

Keeping the migration current during a multi-week cutover window  

With a migration spanning multiple weeks, files on the source file server didn’t stop changing the moment migration began. Code Creators addressed this with a dedicated incremental migration pass after the full migration completed, specifically designed to catch files created or modified during the cutover window, so staff could keep working normally on the source file server right up until final cutover without losing recent changes. 

Results & Business Impact 

This file server to SharePoint Online migration now leaves the client running its active content, 6 TB across department and client sites, entirely in SharePoint Online, with 2 to 3 TB of archival content sitting in Azure Blob Storage’s Cool access tier, off premium SharePoint capacity entirely. New client site provisioning dropped from roughly 3 hours of manual folder and permission setup to about 45 minutes, a 75% reduction, since the mapping sheet’s site and permission templates turned what used to be a bespoke setup into a repeatable process. 

The day-to-day impact varied by role. Staff working client engagements now find proposals, donor extracts, and grant reports in a consistently structured client site, no longer dependent on whoever happened to set up that folder years earlier. IT administrators manage permissions through Microsoft Entra ID and Microsoft 365 groups with a documented mapping to refer back to, replacing a file server group structure nobody fully trusted. Leadership now works from a defined, approved archival process, replacing what used to be an ever-growing “Archive” folder inside every client site, and the data archival automation flow moves files unmodified for 12 months to lower cost storage automatically, well before they can sit on premium SharePoint capacity indefinitely. 

Lessons Learned 

A few things from this project are worth carrying into any file server to SharePoint Online migration: 

The mapping sheet is the project itself

Site level, library level, and permission level mapping decisions made in the mapping sheet are what the entire migration executes against. Treating it as a formality to get through quickly, when it is actually the design document the whole migration depends on, is how migrations end up with permission errors nobody notices until a client complains about access. 

A trial migration earns its time even on a tight timeline

Validating the mapping sheet against one real client site before committing to 6 TB of full migration caught structural issues while they were still cheap to fix, well before they could compound across 240 client sites. 

Storage tiering only works if it keeps working after go-live 

Manually sorting “Archive” folders once during migration solves the storage cost problem for exactly as long as nobody creates new inactive content, which for a client-engagement business is not very long. Building the 12-month archival automation flow into the original project scope is what keeps the storage tiering benefit from quietly eroding after go-live. 

Client Testimonial

“Our file server had basically become a museum of every client engagement we’d ever had, and nobody wanted to touch it because nobody was fully sure what permissions were attached to what. SPDW didn’t just move the files; they gave us a mapping sheet that finally told us exactly what we had and who could see it. Setting up a new client site now takes our team well under an hour, down from most of an afternoon.” 

Director of Operations