Shared Folders Migration: Transfer Plan and Access Control

Migration goal: move data, keep access intact

Migrating shared folders is almost never just “copy the files.” The goal is simple: move data to a new server or storage so that on Monday people open the same folders and have exactly the same permissions as before. Any deviation ends in either a leak or complaints like “nothing opens.”

Usually it’s not just a single “department folder.” Project directories, shared archives, contractor exchange folders, accounting, and sometimes user profiles or home directories also move. Each type of data has its own sensitivity and exceptions.

Permissions most often break because of small things: copying in the “wrong” way (when ACLs aren’t preserved), broken inheritance, manually applied permissions on individual folders, or mixing two levels of access. Share permissions work at the network publish level (who can access the share). NTFS permissions apply to folders and files (what can be done inside). Users see a single final result, while admins configure access in two places, so confusion easily arises.

Key risks during transfer are usually: extra groups suddenly gain access to confidential folders; necessary groups lose access because inheritance changed or SIDs disappeared; copying takes hours and blocks work; some permissions look fine but individual subfolders “do their own thing.”

A good migration plan answers two questions in advance: which accesses must be preserved exactly, and at what moment users will switch to the new location without losses or surprises.

What to collect before you start: a short audit of the current state

Before moving, collect the minimum facts about what you’re moving and who uses it. This takes a few hours but saves days of handling tickets like “it opened yesterday, but not today.”

Start with an inventory of resources. It’s important not only to know “how many gigabytes,” but also the structure, owners and data types. Note separately folders with many small files (they copy more slowly) and folders with databases, archives or application profiles (they are often sensitive to locks).

For each share record in advance: the resource name and network path (how users see it), total size and approximate file count, the heaviest directories, the business owner, current Share and NTFS permissions (who has Read/Modify/Full), whether inheritance is enabled and whether explicit Deny entries exist.

Next, check which groups and users are actually used. ACLs often contain old groups, terminated employees or nested groups that no one remembers. It’s useful to mark “active” groups that must remain and questionable entries that need confirmation from the data owner.

A separate item is dependencies. Look for places where paths are “hard-coded”: desktop shortcuts, mapped drives via GPO, logon scripts, scheduled tasks, application settings, accounting and archive integrations. A simple example: a department uses \SERVER\Public in document templates, and after the move saving starts failing.

Finally, agree on the switch window: allowed downtime (minutes or hours), periods when data can’t be touched (month-end close, report submission), whether a write freeze is needed during the final copy, who accepts the result and how quickly.

With this audit you’ll understand the scope, risks and the spots where access breaks most often.

Choosing an approach: one-time move or phased migration

The approach depends on two things: how much time you can afford for the switch and how frequently users change files. If data is relatively static and a 1–2 hour downtime window is realistic, a single migration is often enough: short freeze, final run, switch to the new path.

Phased migration is needed when downtime is nearly impossible (accounting on close day, admissions, support), when volumes are large and copying won’t finish overnight, or when folders are constantly changing. In that case you run an initial bulk transfer in advance, then on cutover day transfer only the delta and switch paths quickly.

Where to move: server, VM, NAS, cluster

Choose the platform based on requirements, not habits. Common options are a new Windows file server (most straightforward for NTFS and Share permissions), a virtual machine (easier to scale resources and backups), a NAS (convenient for capacity, but check ACL and protocol support beforehand), or a cluster/HA setup (if downtime is critical and availability is required).

If you’re replacing hardware as part of the migration, estimate lead times, service and support in advance. In Kazakhstan this is often tied to local manufacturing and supply-chain transparency requirements.

Plan for growth over 6–18 months

A frequent mistake is to migrate “just enough.” Allow headroom for capacity and IOPS, and consider upcoming projects: archive scanning, department growth, CRM/ERP rollout, increasing attachments and document flow.

Before finalizing the approach check: allowable downtime for each critical folder, how much data can really be copied overnight given network and antivirus, whether any departments cannot afford even a minute of lost changes, whether domain/group changes are planned or it’s only storage relocation, and whether high availability is needed or fast restore from backup is sufficient.

The clearer the answers, the easier the choice: “copy and switch” or phased with delta and minimal risk.

Access plan: who should have what rights after the move

Fix the access plan before copying. Otherwise migration becomes guesswork: someone loses access while someone else gains extra rights.

First separate roles. There should be a data owner (usually the department head or a designated responsible person) and an approver for permissions (for example, InfoSec or an admin per the policy). The owner is responsible for semantics: which groups should see folders and what they can change. The approver enforces rules: least privilege, prohibiting “everyone,” handling guest and service access.

Then agree on structure and names. If you move “as is,” you’re likely to inherit chaos. A few simple rules (consistent folder names, clear levels like “Shared”, “Projects”, “Archive”) save days of cleanup later.

Decide what to do with legacy folders and duplicates. Shares often contain “Final_2”, “Final_3”, folders of ex-employees and temporary dumps. Mark archive candidates and agree retention periods instead of moving everything to the new server.

Prepare a mapping table: old share -> new share. A simple form is enough: old path and share name, new path and share name, data owner (name, department), groups with read/modify/full access, notes (archive, move later, close to all).

Example: accounting has \FS1\BUH with a “Payroll” folder. The plan records that “Payroll” remains accessible only to BUH-Payroll (modify), BUH-Head (full), and closed to others. That clarifies which NTFS and Share permissions should be on the new resource and what to verify after cutover.

Preparing ACLs: tidy up before copying

Clean up permissions before copying. Otherwise you’ll just migrate historical mess to the new server and fixing it there will be harder and riskier. In practice ACL preparation has the biggest impact on how smoothly the migration goes.

First check inheritance. Old shares often contain folders where inheritance was disabled “temporarily” and then forgotten. Find where permissions differ from parents and whether there’s a clear reason. Look specifically for explicit Deny entries: they break access because a single deny on a nested folder can override everything.

Next, standardize owners. If an owner is a random user or a deleted account, it’s a sign permissions were changed manually and unpredictably. Set owners to a standard (for example, an admin group or service account) so no one gets extra ability to change ACLs just because they’re the owner.

Scan for red flags: overly broad groups (Everyone, Domain Users) where department-only access is required; unknown SIDs, disabled accounts, old local groups; mismatches between Share and NTFS settings that grant access to the wrong people; undocumented service accounts and tasks (scanning, backups, 1C exchange) with implicit access; folders with inconsistent rules inside one structure.

Before changes, capture a baseline. Export shared resource settings and take a snapshot of NTFS permissions (including owner and audit if used). If accounting suddenly loses access to “Month Close,” you must be able to compare “before/after” and restore precisely.

Step-by-step transfer without losing ACLs: a working scenario

To avoid surprises, separate data copying from the user switch moment. Most work runs in the background and the downtime window is limited to the final delta and path change.

The scenario below suits Windows file servers where NTFS and Share permissions matter. The logic: prepare destination, test, run multiple synchronizations, then switch users.

1. Prepare target shares. Create folders on the new server, enable inheritance where needed, and set Share permissions narrowly. Frequently Share is limited to entry permissions while detailed access is enforced via NTFS.

2. Make a test copy of a small representative folder. Choose an area with mixed permissions (read, modify, deny) and verify owners, groups and ACLs match. If you find discrepancies here, the main transfer will only replicate the error.

3. Run the main synchronization while users continue working. Typically this takes several passes: the first moves the bulk, subsequent runs catch changes. For Windows many use robocopy with rights and audit copying:

robocopy \"\\\\OLD\\Share\" \"D:\\Shares\\Share\" /MIR /COPY:DATSOU /SEC /SECFIX /R:1 /W:1

4. On the final delta freeze changes. Agree on a short window, restrict writes on the old resource (e.g., temporarily remove modify rights), do the last pass, then switch users to the new path (via GPO, DFS or replacing the share name on the old server).

5. Do quick post-checks and have a rollback plan. Test from accounts representing a typical user and a manager: open and save files, check applications that write to the share. If something breaks critically, rollback should be easy: restore the old path and unfreeze, and investigate later.

Post-migration checks: what to verify besides data volume

Matching total size doesn’t mean everything is OK. Problems often surface in permissions, skipped files and old paths remaining in shortcuts and settings.

Permissions: check the documented state versus real behavior

Start with sample ACL checks on several typical folders: department roots, 2–3 deep subfolders and one sensitive folder (e.g., HR or Finance). Compare both NTFS and Share permissions: sometimes ACLs are preserved but access breaks due to different share-level permissions.

To be sure, test real access from 3–5 representative users and groups: a regular employee, a manager, accounting, an IT admin and a service account. Try opening, creating, modifying and deleting in a test folder. This takes minutes but catches most holes.

Minimum checks: compare ACLs on a sample of folders before and after and ensure inheritance didn’t change; verify effective access for typical users (read, write, delete); ensure no unexpected broad rights appeared (e.g., Full Control for wide groups); check owners on critical folders if required by policy; record results and who confirmed them.

Copy errors and old paths

Next check logs. They often contain “quiet” losses: too-long paths, locked files, name issues, objects skipped due to permissions. Review the copy log for errors and omissions, open files left out (PST/OST, databases), and folders with changed file counts.

Also make sure users actually hit the new location. Commonly the migration is done but shortcuts, mapped drives and app settings still point to the old path.

Practical example: after moving “Accounting,” users could open reports but 1C wouldn’t save exports because the service account lost write permission in the “Exchange” subfolder. You find this only by testing user workflows, not by checking folder size.

Common mistakes that create "holes" in access

The most painful problems appear after cutover: suddenly “everyone sees everything” or nobody can work. Causes are usually typical errors.

First — copying only NTFS and forgetting Share permissions. Access is determined by the most restrictive of the two: a permissive share will let extra users in even if NTFS is correct.

Second — inheritance and exceptions. If inheritance was turned off in places and you copy the structure as-is, permissions become a set of special cases. After a few weeks no one remembers why a subfolder had unique rules and any change produces side effects.

Third — copying under an account without required privileges. The run may finish “successfully” but some ACLs aren’t transferred, owners change, and random access failures follow.

Other issues include long paths, locked files and silent copy errors. Data looks present but some objects were skipped or created with different attributes and permissions.

One more trap — switching paths too early. If users write simultaneously to old and new locations you get divergence and confusion during subsequent delta syncs.

Before going live, run control checks: does the Share permissions model match expectations; are there unexpected Everyone/Domain Users broad permissions; did any folder owners change; is there a copy error report and skip list; is the old share write-disabled after switch.

A practical pattern: if accounting must not lose access during month-end, freeze writes on the old resource briefly, run the final delta sync and then change the path. That reduces double-writes and permission holes.

Quick pre-switch checklist

Before switching users, pause for 15 minutes and run a short checklist. It catches small items that later become mass support tickets and emergency rollbacks.

Make sure every share has an owner (a specific person or role, not “IT in general”). The owner confirms structure and permissions and accepts the result.

Record permissions before switch: both Share and NTFS. Note exceptions: explicit Deny, direct user assignments, inheritance, and long-unused groups. If permissions are historically messy, mark contentious spots so they won’t be debated during the critical phase.

At cutover there should be an agreed plan: what changes, when and who’s on call. Communicate the downtime window clearly and warn users about brief errors during that period.

Verify rollback readiness: at minimum, a clear return point (restore users to old shares) and copies of critical data or a quick restore option from backup.

Quick pre-switch items:

• List of all shares and owners with current contacts.
• Logged Share and NTFS permissions, exceptions and Deny entries noted.
• Agreed switch window and a communications owner.
• Rollback plan tested, backups of critical data available.
• Test accounts or department reps ready to validate access.

After switching, don’t stop at volume comparison. Ask owners to run simple tests: open the folder, create a file, edit and delete it, check typical subfolders. Watch new server error logs and handle early reports quickly before people adopt unsafe workarounds (for example granting everyone Full Control).

Practical example: moving a department’s files with no downtime on close day

Three areas shared a folder structure: Projects (active work, many small files), Archive (rare access, integrity important), and Accounting (tight restrictions and sensitivity to failures). The goal: migrate to a new file server without losing ACLs and with zero downtime on month close.

We split the migration over two evenings so workdays were untouched. The first evening we copied the bulk while users still worked: we transferred main data and NTFS rights but left the old share as the primary access point.

robocopy \"\\\\OLD\\SHARE\" \"D:\\Shares\\SHARE\" /MIR /COPYALL /DCOPY:DAT /R:1 /W:1 /NP

On the second evening we ran a short delta sync. 30–60 minutes before the final run we put the old share into read-only: removed write at the Share level and temporarily denied Create/Write on NTFS for main groups. This prevented new writes to the old location during the last pass.

Before switching we asked one representative from each area to perform quick checks on the new server: open and save a file in their folder, create and delete a file, verify access denial to folders they shouldn’t access, find a file by its usual path and open it.

We didn’t delete the old share immediately. We renamed it to *_OLD, left it read-only and placed a text file saying “Folder moved.” After a few days with no new writes we decommissioned it.

Next steps: lock the process and reduce future risks

After the migration, don’t “drop” the topic. Otherwise in a few weeks permissions will spread again, new stray shares will appear, and audits will turn into manual bug hunts.

Document two roles: data owner (responsible for contents) and permission approver (who signs off access). These are different: the owner understands folder contents, the approver enforces who may access. Without both roles changes become ad-hoc chat requests: “please add like before.”

Create a simple policy for access requests after migration. Usually a clear flow is enough: request with reason and duration, owner approval, group-based granting (not direct user assignments), log changes, regular reviews for stale access.

Also reassess the platform for the next 1–3 years. Migration often reveals capacity shortfalls, backup windows that don’t fit, or lack of HA. Check growth, performance needs (especially for accounting and project teams), backups and a clear recovery plan.

If you plan a new server and want to resolve infrastructure and support at the same time, it’s convenient to combine migration with systems integration. For example, GSE.kz as a Kazakhstan producer and integrator supplies servers and helps build infrastructure for organizational needs.

Schedule the first checkpoint in 2–4 weeks and repeat selective access checks. Most risks appear not on migration day but later when new access requests and point changes start.