Moving HR Documents from Shared Drives to a Real System

If your HR documents currently live on Google Drive, OneDrive, SharePoint, or a network file share, you have probably already decided you need something better. The harder question is how to get there without setting fire to the team's calendar or losing track of which version is current. This is the migration playbook for HR teams making the move, including the bits most vendors skip when they pitch the implementation.

Why this migration is harder than it looks

A shared drive migration sounds like "copy files into a new tool, configure access, done." It is rarely that. Three things consistently surprise teams that have not done one before.

First, the documents are inconsistent. A folder called Contracts contains contracts, addenda, NDAs, and three unrelated PDFs. Naming conventions changed in 2021 when the new HR director joined. Half the files have no metadata at all. The migration cannot just copy these; it has to classify them.

Second, the access model on shared drives is almost always wrong. Permissions accumulate over years. People who left the company two years ago still appear in access groups. The migration cannot just preserve current access; it has to design a new one.

Third, the active workflow does not stop while you migrate. New hires keep arriving. Contracts keep needing signatures. The migration has to run alongside business as usual, which means a clear cut-over date and a clean handoff.

The three migration patterns and when to use each

There are three viable patterns for this kind of move.

Pattern A: Cut over, then backfill

Set a date. After that date, all new HR documents go into the new system. Historical documents stay on the shared drive in read-only mode and get backfilled over the following weeks or months. This is the lowest-risk pattern and the most common pick. It works because the team adopts the new tool with new work, while the old tool stays available for lookups.

Pattern B: Big-bang migration

Migrate everything in one weekend, switch off the shared drive Monday. This pattern is faster but riskier. It requires very tight upfront classification work and a clean access matrix. Worth it only for small companies (under 100 employees) or teams that have already done the classification work for another reason.

Pattern C: Phased by employee cohort

Migrate active employees first, then leavers within the retention window, then historical archive. Each cohort cuts over independently. Good for companies with very large historical archives, because it lets you delay the slowest part of the work without delaying the daily-use benefit.

Most mid-sized teams pick Pattern A. The rest of this playbook assumes that pattern.

A 5-step framework for shared-drive migration

1. Inventory what is actually on the shared drive

Run a script or a manual scan to count files by folder, age, and rough size. Most HR teams find their shared drive holds 30 to 60% files that should have been deleted years ago, 20 to 30% duplicates, and only 20 to 40% live current documents. Knowing the ratio shapes everything downstream. You do not have to migrate the dead weight.

2. Design the target taxonomy and access model

Before any file moves, define the categories, retention rules, and access roles in the new system. Treat this as a clean-slate design, not a copy of the shared drive structure. The shared drive structure is the problem you are escaping. Most HR teams end up with 12 to 20 categories, four to six access roles, and three to seven retention rules. Sign this off before migration starts.

3. Classify before you copy

The dirty secret of HR document migrations is that the bottleneck is classification, not copy speed. Each file needs to be assigned to a category, attached to the right employee, given an upload date, and (where applicable) an expiry. Some of this can be inferred from folder structure and filename, but a meaningful percentage needs human review. Budget realistically: 30 to 60 seconds per file for human-reviewed classification, faster if you have automated extraction.

4. Run a parallel period

Set a date when all new HR documents go into the new system, and keep the shared drive read-only for at least 90 days. During the parallel period, anyone who needs a file from the old shared drive can still get it, but no new writes are allowed. This catches the documents you missed without forcing a panicked re-migration. After 90 days of no read requests on a given folder, you can usually archive it without harm.

5. Decommission and document

Once the parallel period ends, formally retire the shared drive. Set it to read-only for one final retention period (often a year), then back it up to cold storage. Document the migration in writing: what was moved, what was archived, what was deleted, what the new system looks like, and what the access model is. This document becomes evidence the next time an auditor asks about the migration.

Mistakes to avoid

1. Copying the shared drive structure into the new system. The structure is the problem you are escaping. Design a new taxonomy.
2. Skipping the classification step. A new system full of uncategorized files is a worse problem than a shared drive of uncategorized files, because it cost money to build.
3. Doing the migration without a cut-over date. Without a date, the old shared drive stays in use forever and the team ends up with two parallel systems.
4. Forgetting about access cleanup. Migrating shared-drive permissions into the new system carries forward two to five years of access drift.
5. Migrating dead files. Documents past their retention period should be deleted before migration, not loaded into the new system where they immediately violate your retention policy.

Migration checklist

• Shared drive inventoried, with counts by folder, age, and rough live-vs-dead ratio
• New taxonomy, retention rules, and access model designed and signed off
• Classification workflow defined, with realistic time budget per file
• Cut-over date communicated, with parallel period planned (90 days minimum)
• Decommission plan covers read-only window, cold archive, and final retention
• Written migration record exists for audit purposes
• Active workflows continue without disruption during the migration

What "good" timing looks like

A realistic timeline for a 500-employee company migrating from a Google Drive setup to a real HR document system:

• Week 1 to 2: inventory and target design
• Week 3 to 4: tool configuration, access roles, retention rules
• Week 5 to 6: parallel period begins, new documents go to the new system
• Week 5 to 12: historical classification and migration in waves
• Week 13: parallel period ends, shared drive goes read-only
• Month 6: shared drive moves to cold archive
• Month 12: full decommission per retention policy

Six months end-to-end, with the team feeling the daily benefit from week 5. Faster is possible for smaller companies; longer is normal for companies with deep historical archives or paper backlogs to scan first.

How Safepiens supports the migration

Safepiens is built so the new system is ready to receive documents in days, not months. Categories and retention rules for standard HR document types ship preconfigured, role-based access maps to standard HR roles, and the upload workflow enforces classification at the moment a file lands. Most customers migrating from shared drives finish the configuration in week 1 and run the parallel period from week 2. The broader picture of what life looks like after the migration is covered in digital document management for HR teams, and the operational habits that make the new system survive long-term are covered in HR document management best practices.