File Server Migration to Cloud: A Practical Playbook

The ₹3.2 Lakh Bill From a Job Nobody Thought Was Risky

In March 2024, a 90-person engineering firm in Peenya ran a Saturday-night file server migration to SharePoint Online. They copied 1.4 TB of drawings, CAD files, and ISO documentation. By Monday morning, 60 of their 90 users could not open a single project folder.

The cause was not the copy. The copy worked. The cause was that their legacy file server had been running NTFS permissions inherited from a Windows Server 2003 era domain, with nested groups four levels deep, local groups that no longer mapped to anything in Active Directory, and no documentation. SharePoint inherited what it could and defaulted the rest to the site owners.

The firm spent three weeks untangling it. Two senior engineers, one external consultant at ₹4,500 an hour for 40 hours, and lost billable time from a project team that could not access drawings. Total damage: roughly ₹3.2 lakh, plus a client escalation. The migration had been budgeted at ₹0 for internal effort.

That story is not unusual. It is, in our experience at SynergyScape, closer to the default outcome when a file server migration to cloud is treated as a storage exercise rather than an identity and access exercise. This article is about doing it properly — SharePoint/OneDrive versus keeping the file server, permission mapping that actually survives, the path-length problem Microsoft has partially but not fully fixed, bandwidth sizing, and a cutover plan that does not require a weekend of prayer.

If you want to skip ahead and just talk to someone who has run these migrations dozens of times, our storage solutions service is where this work lives.

First, Decide Whether You Should Migrate At All

About 30% of the enquiries we get for file server migration to cloud should not migrate. Or not fully. The file server is not obsolete, and the cloud is not automatically cheaper. Anyone who tells you either of those things is selling something.

Here is the honest decision matrix.

The last row matters more than people think. Autodesk Revit central models over SharePoint Online is a known disaster — file locking behaviour breaks, worksharing fails, and users lose work. If your team lives in Revit, do not migrate the central model location. Syncing project deliverables to SharePoint is fine. Moving the working model is not.

What a File Server Actually Costs in 2026

A lot of Indian SMEs have never costed their file server properly because the cost sits in depreciation and a support contract nobody reads. Here is a real comparison for a 60-user deployment, quoted in Bangalore early 2026.

Read that carefully. Year one, the two options are within noise of each other. Year two, the on-premise file server is dramatically cheaper. Anyone claiming SharePoint is always cheaper is wrong, and we will say that plainly even though we sell both.

So why migrate?

• Mobile and remote access without VPN.
• No 5-year hardware refresh cycle.
• Versioning and recycle bin built in.
• Ransomware resilience if done right.
• If you already pay for Microsoft 365 licences with SharePoint included, you may be double-paying for storage.

That last point is where most SMEs actually win. If you are already on Business Standard or Business Premium and not using SharePoint, you are paying for storage you are not consuming while maintaining a file server you do not need.

Permission Mapping Is Where Migrations Die

We said this early and we will say it again: permission mapping is the hard part. The copy is easy. Mapping 12 years of accumulated NTFS permissions to SharePoint groups that reflect how your organisation actually works in 2026 is the work.

Why NTFS Permissions Do Not Translate Cleanly

NTFS permissions and SharePoint permissions are structurally different. Three examples.

Explicit denies. NTFS supports explicit Deny permissions that override allows. SharePoint does not have an equivalent at the library level. If a legacy file server had a Deny that locked an entire finance subfolder away from a group, that structure has no clean SharePoint analogue. It must be redesigned.

Local groups. NTFS permissions frequently reference local server groups like FileServer01\AccountsTeam rather than domain groups. When the server is decommissioned, those group memberships are lost unless someone exports them first. Standard migration tools will report these as unresolved and default them to something. Usually site owners. Usually silently.

Inheritance chains. Deep folder trees with permission inheritance broken at multiple levels are painful. A folder with inheritance broken at level 3 and re-broken at level 6 has no SharePoint equivalent. It flattens, and often what flattens is not what you intended.

The Mapping Exercise That Works

There is no tool that solves this. Microsoft's SharePoint Migration Tool (SPMT) and ShareGate will copy permissions to the extent it can, but they will not redesign them. The mapping exercise is manual, but it can be structured.

Step 1. Export the full permission structure. Run icacls D:\Shares /save perms.txt /t /c on the file server and get a raw dump of every permission on every folder. This will be ugly. It is also the only complete record you will have.

Step 2. Inventory the actual access patterns. Ask each department head which folders their team needs. Most of them will list 40% of what the permission dump says they have. The other 60% is permission creep — access granted years ago for a project that ended.

Step 3. Map to a SharePoint structure that reflects the business, not the file server. This is the step where the migration becomes an opportunity. The old file server had a Finance folder with 14 subfolders inside, permissions broken at every level. Does the business actually need 14 finance subfolders, or does it need one Finance site with a handful of libraries and modern permissions?

Step 4. Define groups before you migrate anything. Every permission group in the target environment should have a business owner with a name and an escalation contact. If you cannot name who owns a group, that group should not exist.

Step 5. Test with three real users per department. Give them a week. Not a day. A week. Watch what they complain about.

A Worked Example From a Real Migration

One of our Bangalore clients, a 140-user financial services company, had a legacy file server with 6,400 individual permission entries across 2,200 folders. We reduced it to 18 SharePoint groups and 42 libraries. Migration time went from an estimated 9 weeks to 4. Access ticket volume dropped from roughly 30 a month on the file server to 6 a month on SharePoint — because the new structure made access self-evident instead of tribal.

The key insight: nobody needs 6,400 permission entries. They accumulated. Nobody audited them. When you force the business to name who owns each access decision, most of them would rather not.

The Path-Length Problem (And Its Stubborn Remnants

Windows had a 260-character path limit for decades. SharePoint and OneDrive Online support paths up to 400 characters, which is generous, but the path limit is not the only trap.

What breaks in practice:

The original file server still has 260 characters. If your server has a folder path of 240 characters and the SharePoint equivalent library URL is 90 characters, the effective combined path during tool-based migration can exceed limits and files will silently fail.

Excel and older Office applications can still truncate at 260. Even in 2026, if a user downloads a file with a 280-character path to a local folder path of 200 characters, the local save may truncate. This is Excel's problem, not SharePoint's, but users will blame the migration.

OneDrive sync client has a local path limit of 260 characters unless you enable Long Paths in Windows via Group Policy. Doing this requires Windows 10 build 1607 or later, which in an Indian SME usually means everything is fine, but check.

The real killer: filenames with characters SharePoint dislikes. #, %, &, {, }, ~, and especially * and ? are legal on NTFS but will fail or break URLs on SharePoint. Files with these characters will fail to migrate. When we audit a legacy file server, we typically find 200-800 files with these characters across a mid-size company. Each one is a support ticket waiting to happen.

How to Handle Path Traps

Run these three tools before you migrate anything.

A typical remediation: rename paths to shorten them, replace illegal characters with underscores, and split deeply-nested folders into separate libraries. This can take 40-80 hours on a 5 TB file server with poor hygiene.

Budget for it. The alternative is a migration that runs "successfully" and then generates 400 user tickets on day one.

Bandwidth and Cutover: The Parts Everyone Underestimates

Two numbers matter most: how fast you can push the initial copy, and how long the final sync window needs to be.

Sizing the Initial Copy

The maths is unforgiving. At 100 Mbps symmetric upload (unusual in India; most connections are asymmetric), you move about 45 GB per hour under ideal conditions. Real world, with SharePoint throttling and many small files, plan for 25-35 GB per hour on a good connection.

A 5 TB file server on a 20 Mbps upstream is no longer a weekend project. It is a 30-day project, and it will saturate the office internet the entire time. This is why we strongly recommend air-gapped seeding via Azure Data Box for anything over 3 TB — Microsoft ships a physical device, you fill it, ship it back, and Azure ingests it. The cost is roughly ₹40,000-₹65,000 round-trip including logistics, but it saves weeks.

The Cutover Weekend Plan

The classic mistake is to schedule the entire migration as a single cutover. The right approach for anything above 500 GB is a two-stage.

Pre-seed (T-21 days to T-3 days). Run a bulk copy of all data using SPMT or ShareGate. This runs during office hours and weekends. Users keep using the file server normally. The copy is not authoritative yet — it is caught in a snapshot.

Delta sync (T-3 days to T-1 day). Re-run the tool in incremental mode. It copies only what changed since the last run. For most SMEs, this is 5-15% of total data, and it takes hours not weeks.

Freeze (T-0, Friday 8 PM). Lock the file server to read-only. Run one final delta (should be small, maybe 1-3 GB). Verify counts match. Change DNS or DFS namespace to point to the new location. Users arrive Monday morning to the new system.

Rollback window (T+14 days). Keep the file server running read-only. If something is broken, you can flip back. After two weeks, decommission.

This structure turns a scary weekend into a controlled one. We run 15-25 of these a year and haven't had a rollback in three years using this pattern.

The One Time It Went Wrong

In August 2023, we migrated a 3.5 TB file server for a design agency in Indiranagar. The cutover was clean. Monday morning was clean. Tuesday at 11 AM, the entire Pantry folder went read-only for 40 users.

Cause: an old Group Policy assignment that nobody had documented was reapplied during the Monday night maintenance cycle, and it reset NTFS permissions on the legacy server to a pre-migration state. The company's backup software then ran a delta sync at 2 AM Tuesday that captured the reset permissions and pushed them to SharePoint via a custom script they had rigged up.

We caught it within four hours because we still had monitoring on the old server and the delta sync script logged loudly. Rollback to the Friday snapshot took 90 minutes. Total cost: about ₹18,000 in our time and half a day of client disruption.

The lesson is not "don't use scripts." The lesson is that turned-on monitoring and a rollback plan are what separate a mild incident from a ₹3 lakh disaster.

SharePoint vs OneDrive: They Are Not the Same Thing

This is genuinely confusing and vendors conflate the two. They are different products with different behaviour.

Where this goes wrong: SMEs migrate all files to OneDrive because "OneDrive is what users know." Then the finance team has separate OneDrive folders and nobody has version control on shared documents. Then the founder's laptop dies and the recovery process is unclear because the file was in one person's OneDrive, not a shared library.

Rule of thumb: if two or more people need to touch the file as part of their regular work, it goes in SharePoint. If it is genuinely a personal working file, OneDrive. Err on the side of SharePoint.

Security and Compliance Considerations for Indian SMEs

A file server migration to cloud is also a compliance event, whether or not you frame it that way.

DPDP Act 2023 Implications

The Digital Personal Data Protection Act, 2023 requires that personal data of Indian residents be handled with defined purpose, consent, and security safeguards. If your file server contains HR files, customer data, KYC documents, or anything with a PAN, Aadhaar, or contact details attached, the migration needs to be documented.

Practically, this means:

• Data mapping before migration. Know what personal data you hold and where it sits.
• Encryption in transit and at rest. Microsoft 365 handles both by default, but verify with your tenant admin.
• Access logging. Know who accessed what.
• Retention rules. Do not migrate 12 years of HR records that should have been purged five years ago.

The migration is a good forcing function for cleaning up. Use it.

CERT-In Guidelines

If your company falls under CERT-In's 2022 directions (broadly, if you are a service provider or intermediary), incident reporting within six hours is mandatory. A migration that loses or misplaces files can count as an incident depending on severity. Document your migration process formally, keep logs, and know your reporting chain.

Microsoft 365 Data Residency

Microsoft's India datacentre regions (Central India and South India) mean your tenant data can stay in India. Default tenant creation usually lands in a region but this should be explicitly confirmed for regulated industries. If your data needs to remain in India for compliance reasons, verify the tenant region before migration, not after.

Cost of Doing It Right: A Real 2026 Budget

Here is a realistic budget for a 100-user company with 2.5 TB of file server data, migrating to SharePoint Online with proper tooling and cleanup.

Standalone, that sounds like a lot. Compared with running an on-premise file server for another 5 years, the total cost of ownership favours migration if — and only if — you already have Microsoft 365 licences for those users.

If you are not already on Microsoft 365, the equation changes. Business Standard at ₹1,050 per user per month for 100 users is ₹12.6 lakh per year, and the file server starts looking like a bargain again unless you need the other Microsoft 365 capabilities.

Where Our Approach Is Not Right For You

We do not do every migration that comes to us. Three types we turn down or refer elsewhere:

Companies migrating for cost reasons only. If the business case is "cloud is cheaper" and your users are all in one office with good on-premise infrastructure, we will usually suggest keeping the file server and investing in better backup. Cloud is cheaper in many scenarios. It is not always cheaper.

Companies with active data residency investigations. If legal counsel has flagged a regulatory question, involve them before us. We cannot advise on your sectoral compliance obligations.

Companies without executive sponsorship. A migration that leadership has delegated entirely to IT will stall. The permission mapping requires department heads to make decisions. If they will not engage, the project will not finish.

For everything else — 60-300 user SMEs, mix of documents and structured files, some remote workers, and Microsoft 365 already in play — we do this frequently and well. Our storage solutions practice runs these as a standard engagement.

A Realistic Timeline

For a 100-user SME with 2.5 TB, expecting no surprises (which never happens):

Realistic total: 6 to 10 weeks. Anything promised in two weeks is being done badly.

Frequently Asked Questions

How long does a file server migration to cloud take for a 100-user Indian SME?

Typically 6 to 10 weeks for 100 users and up to 3 TB of data. The dominant variable is not the copy speed but the permission-mapping and path-remediation work. Companies with clean, well-documented file servers finish in 5 weeks; companies with 15 years of accumulated NTFS permissions take 12 weeks or more.

Is SharePoint cheaper than keeping a file server?

It depends entirely on whether you already pay for Microsoft 365 licences. If you do, SharePoint is often cheaper because you are double-paying for storage. If you do not, the maths usually favours a well-maintained on-premise file server for companies below 100 users. First-year costs are nearly identical for most 60-user deployments; year two onwards, on-premise usually wins on pure storage cost.

What is the path-length problem in SharePoint migration?

Legacy Windows file servers limit paths to 260 characters. SharePoint supports 400, but migration tools, Excel, and the OneDrive sync client still have 260-character limits in places. Additionally, filenames with characters like #, %, &, *, and ? are legal on NTFS but break SharePoint URLs. Every migration needs a path and character audit before the bulk copy starts, or many files will silently fail.

Does moving files to SharePoint comply with DPDP Act 2023?

Not automatically. DPDP compliance requires defined purpose, consent where applicable, security safeguards, and data mapping. Microsoft 365 provides encryption in transit and at rest and access logging by default, but you need to document what personal data you migrated and why, apply retention rules, and avoid migrating data that should already have been purged. If your data must remain in India, verify your Microsoft 365 tenant region is India before you begin.

Can we keep using our P: drive after migrating to SharePoint?

Yes, but there are caveats. P: drive can be mapped to a SharePoint document library via WebDAV, but performance is poor for large files and reliability is inconsistent on weak connections. For teams with heavy AutoCAD or Revit workflows, keeping the working model on a local NAS and syncing deliverables to SharePoint is usually better. For document-centric workflows, switching users to the SharePoint web interface and OneDrive sync is more reliable.

What happens to our file server after migration?

Keep it running read-only for at least 14 days after cutover as a rollback option. After that, take a final backup to a NAS or external drive, retain it for however long your retention policy requires, and then decommission. Do not wipe the drives on decommission; physically destroy them or degauss per your data destruction policy.

What To Do Next

Stop thinking about file server migration to cloud as a copy job. Sit down with whoever owns your Active Directory and your file server, and answer three questions honestly.

One: do we have a documented list of every permission group on the file server and who co-owns it? If the answer is no, your first week of work is creating that list. This is not optional and it cannot be outsourced without your involvement.

Two: do we have any files with paths over 260 characters or filenames containing # % & { } ~ * ?. If yes, get the count. That count is your remediation budget.

Three: is our office internet upload speed genuinely sufficient for the initial copy, or do we need Azure Data Box seeding? Anything above 3 TB on a connection under 100 Mbps upload should be physically seeded.

If you want help answering these, or you have answered them and want a delivery partner for the migration itself, our team runs these engagements regularly for SMEs across Bangalore and South India. The starting point is a discovery call — not a proposal. Reach out at our contact page and bring your file server audit with you. It will halve the discovery time and save you money on the engagement. We have been doing this since 2001 and there are very few surprises left.