Retiring Shared Drives in a GxP Company: Moving Controlled Files Without Losing History

Why Shared Drives Become a Compliance Problem

Network shares were never designed to manage regulated records. They store files and apply folder permissions. That is all. When a company is small, the share feels like enough: the quality lead knows which folder holds the effective SOPs, the validation engineer knows where the test evidence lives, and the CMC lead keeps the stability exports in a folder with a sensible name. The trouble starts when people leave, sites are added, or an inspector asks a simple question that the folder structure cannot answer.

What the Regulations Ask of a Record, Wherever It Lives

The rules do not ban shared drives. They set expectations that a plain share struggles to meet. Under 21 CFR 211.180(c), records required by the US drug GMP regulations, or copies of them, must be readily available for authorized inspection during the retention period. The same paragraph says that “Records that can be immediately retrieved from another location by computer or other electronic means shall be considered as meeting the requirements of this paragraph.”² Retrieval is the easy part for a share. Knowing that what you retrieve is the complete, correct record is the hard part.

EU GMP Chapter 4, in its 2011 text that remains in force while a revision works through the European Commission process, is more direct. Clause 4.10 says: “It should be clearly defined which record is related to each manufacturing activity and where this record is located.” It continues: “Secure controls must be in place to ensure the integrity of the record throughout the retention period and validated where appropriate.”³ A folder tree where the same batch file exists in four places, with three different modified dates, does not define where the record is located. It defines where copies happen to be.

What a Share Cannot Show

A plain network share keeps only the current copy of each file, unless someone has set up backups or snapshots, and those are a recovery tool rather than a version history. It does not record why a file changed. It usually cannot show who changed it unless file system auditing was configured in advance, and even then the log shows that a write happened, not what was written. It cannot tell an approved document from a draft except by file name. Permissions tend to grow over time as people are added for one project and never removed.

FDA has cited this pattern directly. In a January 2017 warning letter to an Italian drug manufacturer, the agency wrote that the firm “stored original data in an ‘unofficial’ and uncontrolled electronic spreadsheet on a shared computer network drive.” Among the corrective actions FDA asked for: “Evaluate the extent of uncontrolled spreadsheets at your facility.”¹ That second sentence is worth reading twice. The request was not to fix one spreadsheet. It was to find out how far the practice had spread. That is the same question a shared drive retirement project has to answer before it moves anything.

These retention periods matter for a simple reason. Many of the files on an old share are still inside their retention period, often by years. They cannot be deleted because the share is being switched off, and they cannot be left where nobody can find them. They have to go somewhere that will keep them intact and retrievable until the clock runs out.

Why Unmanaged SharePoint Counts Too

Many companies moved their shares to SharePoint or another cloud file service and called the problem solved. SharePoint adds version history and a modified-by field, which is an improvement. But a SharePoint site with no document types, no approval workflow, no controlled numbering, and open edit rights is still a shared drive with a better interface. The approved SOP and the draft still look the same. The version history shows who saved a file, not whether it was reviewed and approved. For this article, an unmanaged SharePoint library is in scope in the same way as a mapped drive letter.

Start With an Inventory, Not a Migration Tool

The most common mistake is to start by choosing a migration tool. The tool question comes later. The first question is what is on the share, and you cannot answer it by looking at folder names. An inventory has three parts: a technical scan of the files, a map of who owns each area, and a short list of folders that need special care.

The Technical Scan

Run a scan that lists every file with its full path, name, extension, size, created date, last modified date, and owner as recorded by the file system. Add a content hash for each file, which lets you find exact duplicates no matter what they are named. On Windows file servers, File Server Resource Manager can generate storage reports, including a report to identify duplicate files across a volume and a Files by Owner report that shows how individual users are using shared storage.⁴ Robocopy, the standard Windows copy tool, has a list-only option, /l, that lists files without copying, deleting, or time stamping them, which makes it useful for a dry run against the real share.⁵ Other platforms have their own equivalents. The tool matters less than the output: one spreadsheet or database table with a row per file.

Treat some fields with caution. The file system “owner” is often the account that created the file, or an administrator account if files were restored from backup, so it is a clue rather than an answer. Last-accessed dates are unreliable on many servers, because the setting that updates them is often turned off for performance. Created dates may reflect the last time a folder was copied between servers, not when the document was written. Write these limits into the inventory notes now. You will need them later when someone asks why a 2014 SOP shows a 2019 created date.

The Ownership Map

Every top-level folder and most second-level folders need a named business owner: a person in a function who can say what the files are and decide what happens to them. IT can run the scan, but IT cannot decide whether a folder of stability exports is raw data supporting a filing or a scratch area. Build the map by walking the folder tree with function leads in short sessions. Ask four questions for each area: what work produced these files, which of them are approved or final, which are required records, and whether anything here is the only copy of something.

Expect gaps. Some folders will belong to people who have left, to projects that ended, or to a partner company from an acquisition. Mark these as orphaned and assign them to the head of the function that would own the work today. An orphaned folder with no owner is the folder most likely to hold a record that matters and the one most likely to be deleted by mistake.

The Special-Care List

Some folders need extra attention before any bulk activity. Put these on a separate list with a named reviewer:

• Raw data exports from instruments, chromatography systems, or laboratory software, where the share may hold the only copy.
• Signed documents stored as scanned images or PDFs, where the file is the evidence of approval.
• Spreadsheets used for GxP calculations, which were exactly what FDA asked the firm in the 2017 letter to evaluate.¹
• Folders under legal hold or linked to an open investigation, complaint, or inspection commitment.
• Clinical files that belong in a trial master file, which has its own completeness and inspection access rules.
• Folders with personal data, such as patient information or HR records, which add privacy rules on top of GxP rules.

Take a Baseline Before Anything Changes

Once the scan is complete, save it as a dated, read-only baseline with the hash values included. This is the reference point for the whole project. When the project ends, you will compare the baseline against the destinations and the approved deletions, and every file in the baseline should be accounted for. If the share is large, take the baseline in sections, but record when each section was scanned so you can tell whether changes happened between scans.

Classify Every File Into Four Buckets

Classification is where most of the effort goes, and where good judgment matters most. The aim is to put every file, or more practically every folder and file group, into one of four buckets. Each bucket has a different destination and a different level of care during the move.

The Questions That Decide the Bucket

Labels on files cannot be trusted. A file named “SOP-QA-014 FINAL v3 approved.docx” may be a draft that someone renamed. Use a short set of questions, asked in order, and record the answer for each folder or file group:

1. Is a regulation, a filing, or a procedure the reason this file must exist? If yes, it is a controlled document or a record. If no, it is a working file or junk.
2. Does it tell people what to do, or show what was done? Instructions are controlled documents. Evidence is a record.
3. Is this the official copy, or is the official copy somewhere else? If an eQMS or DMS already holds the approved version, the share copy is a duplicate and usually junk. If the share copy is the only copy, it is the record, whatever its file name says.
4. Is it inside its retention period, or under a hold? If yes, it must be kept, even if it is old and nobody uses it.
5. Can the owner confirm it? If the owner cannot say what the file is, it goes to an “unresolved” queue rather than to junk.

The Hard Cases

Four situations come up in nearly every project and deserve a written rule before the classification work starts.

The only copy of an approved document. Older SOPs and specifications are sometimes found only on the share, because they were approved on paper and the scanned copy was never loaded into a system. The scanned file is the best available evidence. Classify it as a record of approval, keep it intact, and if the document is still effective, bring it under document control in the new system as a new controlled version that points back to the original.

Several near-identical copies. Exact duplicates share a hash, so they are easy. Near-duplicates are harder: the same document with a tracked change accepted, or a spreadsheet with one cell different. Do not choose one by guesswork. Ask the owner which one was used, record why, and keep the others until the owner confirms they can go. If nobody can tell, keep all of them in the archive with a note.

Spreadsheets that did GxP work. A spreadsheet that calculated release results or tracked training is part of a record even if nobody thought of it that way. Classify it as a record, and flag it for the system owner, since the bigger question is whether the calculation should keep running in a spreadsheet at all.

Working files that became evidence. An email export or a meeting deck may have been attached to a deviation or cited in a change control. Check the QMS for links back to share paths before you classify any working file as junk. A record that points to a deleted file is a broken record.

Classify Folders First, Files Second

A share with a million files cannot be classified file by file. Work at the folder level wherever a folder holds one kind of content, and go down to file level only where folders are mixed. ICH Q9(R1) states that “The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk.”⁶ Apply that here. A folder of marketing slide decks does not need the same review as a folder of chromatography exports. Record the risk rating for each folder in the inventory, and let it drive how much checking each area gets during the move.

Decide the Destination for Each Bucket

Once the buckets are known, each file group needs a destination. The rule is simple to say and harder to follow: each file goes to the place where the company will look for it, and that place must be able to keep it intact for as long as the retention schedule requires.

The Six Destinations

Two points about this table. First, the archive is a real destination, not a parking lot. If you send a file group to the archive, you are saying it will be kept, protected, and retrievable until a known date, and then reviewed for disposal. Second, deletion is also a real destination. A project that keeps everything because deletion feels risky simply moves the shared drive problem into a new system.

Match Each File Group to a Retention Rule

Every file group headed for the archive or for deletion needs a retention rule from the company’s retention schedule. If you do not have a retention schedule, this project will force you to write one, at least for the record types on the share. The regulations give minimums, and they differ by type of record. For US drug GMP, batch production and control records must be kept at least one year after the batch expiration date.² For US nonclinical laboratory studies under 21 CFR Part 58, the retention period is the shortest of the periods listed, such as at least 2 years after FDA approval of the application the study supported, or at least 5 years after the study results are submitted.⁸ For IND sponsors, 21 CFR 312.57(c) requires retention for 2 years after a marketing application is approved, or, if it is not approved, until 2 years after investigational shipment ends and FDA has been notified.⁷

EU GMP Chapter 4 adds that critical documentation supporting the marketing authorization, including raw data for validation or stability, should be kept for as long as the authorization is in force. It also allows certain documentation, such as raw data behind validation or stability reports, to be retired where a full set of new data has replaced it, as long as the justification is documented and takes batch record retention into account.³ That clause matters for shared drive projects, because old shares are full of superseded validation and stability data. You may be able to dispose of some of it, but only with a written justification that someone in quality has approved.

Do Not Redesign Everything at Once

There is a strong pull to use the move as a chance to redesign the document taxonomy, rename every file, and restructure every folder. Some of that is worth doing, especially for controlled documents going into a DMS. But every rename is a change to the record’s context, and every new folder structure breaks the link between the file and the paths cited in older records. Keep the original path of every file as a metadata field in the destination. That one field lets you answer the question “where was this before?” for the rest of the retention period.

Keep Metadata and History Defensible During the Move

This is the part of the project an inspector or auditor is most likely to probe. The question will not be “did you move the files?” It will be “how do you know the file you are showing me is the same file that was on the share, with the same dates and the same content?” You need an answer that does not depend on anyone’s memory.

What Guidance Expects of a Migration

The GxP guidance with the most detail on moving electronic records comes from the Good Laboratory Practice (GLP) world, but its logic applies to any GxP record. The OECD advisory document on GLP archives defines migration as “The transfer of electronic records from one format, media or computerised system to another.” It says that if migration is necessary, “the process of migration should be fully documented, and validated to ensure complete and accurate migration of the original records before they are lost or destroyed.” It also says that moving records into a dedicated electronic archive includes “raw data, metadata, audit trails, e-signatures” and the hardware and software needed to keep the records available.⁹

The Swiss Working Group on Information Technology in a GLP Environment (AGIT) puts the goal plainly in its guideline on archiving electronic raw data: “Data that have been migrated should be readable, identifiable, retrievable, and interpretable.” For copying between storage locations, such as server to server, the same guideline says that “the replication should not result in any loss of content, structure, or context of the archived data.”¹⁰ Content, structure, and context is a useful checklist for a shared drive move: the bytes, the folder relationships, and the metadata that says what the file is.

The Metadata to Keep for Every File

For each file, capture these values from the source before the move and confirm them at the destination afterward:

• Original full path and file name, stored as a field in the destination.
• Created and last modified dates as recorded on the source, with a note of the time zone.
• Author or owner as recorded by the file system, plus the business owner from the ownership map.
• Version, where the source has one (SharePoint libraries do; plain shares do not).
• Size in bytes and a content hash calculated before the move.
• Bucket, destination, and retention rule from the classification step.
• Permissions on the source, at least at folder level, so you can show who had access while the file lived on the share.

Why Checksums Carry So Much Weight

A content hash is a short value calculated from the file’s bytes. If even one character in the file changes, the hash changes. Microsoft’s documentation for the PowerShell Get-FileHash command explains that the purpose of hash values is to verify that the contents of a file have not been changed, and that if the hash values of two files are identical, the contents are also identical. The same page notes that MD5 and SHA1 are no longer considered secure and should be used only for simple change checks, and that the command uses SHA256 by default.¹¹ SHA-256 is one of the hash algorithms specified in the US federal Secure Hash Standard, FIPS 180-4.¹² Use SHA-256 or stronger for GxP records, and record the algorithm alongside the value.

Hashes prove content. They do not prove dates or authorship, because those live outside the file’s bytes in most file systems. That is why you need both: a hash match shows the content did not change, and a metadata comparison shows the context did not change. A file with a matching hash and a reset created date has kept its content but lost part of its history, and you need to know that before someone else finds it.

Filters Can Leave Records Behind

Migration tools offer filters to reduce volume. The SharePoint Migration Tool, for example, can migrate only files created or modified after a chosen date, and can skip hidden files or files with certain extensions; Microsoft describes the date filters as a way to limit the number of files migrated or to follow company retention policy.¹³ Filters are useful, but in a GxP move they are classification decisions made by a tool. A “modified after 2020” filter will leave behind a 2016 stability export that is still inside its retention period. Use filters only to carry out decisions already made in the classification step, never to make them.

When the Destination Cannot Hold the Original Dates

Some destination systems set their own created date when a file is loaded and do not let you overwrite it. That is not a failure, as long as you plan for it. Store the source dates in dedicated metadata fields, such as “original created date” and “original modified date,” and keep the migration manifest (the per-file list of source values, hashes, and destination identifiers) as a record in its own right. The destination’s system dates then show when the file arrived, and the original fields show its history before that. What you must not do is let the original dates disappear with nothing recorded in their place.

True Copies and Format Changes

US GMP allows records to be kept as original records or as “true copies such as photocopies, microfilm, microfiche, or other accurate reproductions of the original records.”² A byte-for-byte copy with a matching hash is the strongest form of accurate reproduction. A converted copy, such as a spreadsheet saved as PDF or a proprietary instrument file turned into a report, is a different thing. It may lose formulas, metadata, or the ability to reprocess data. AGIT’s guideline addresses this for raw data. It warns that keeping electronic raw data only in human-readable form might not be accepted by all registration authorities, and suggests that it may be appropriate to store both the proprietary and the human-readable form at the time of archiving.¹⁰ If your project converts any formats, treat each conversion as a decision with a documented reason, and keep the original unless a quality-approved assessment says otherwise.

Verify the Move Before Anyone Relies on It

Verification answers one question: does every file in the baseline have a known outcome, and does every moved file match its source? The level of checking should follow the risk rating from the classification step. A folder of raw data gets every check. A folder of working files may get counts and a sample.

Four Levels of Reconciliation

The Exceptions Log

Every project produces exceptions: files with names too long for the destination, files with characters the destination does not accept, locked or corrupt files, files that failed to copy. Copy tools report these. Robocopy, for example, returns an exit code of 8 or higher when at least one failure occurred during the copy.⁵ Capture every exception in one log, with the file, the problem, the fix, and who approved the fix. A renamed file needs its original name recorded. A file that cannot be recovered needs a documented assessment of what was lost. The OECD archives guidance makes the same point for media that can no longer be read: disposal is acceptable provided it “is authorized, documented, and electronic records are migrated and any record losses documented.”⁹

Who Signs Off

Quality should review and approve the reconciliation for any folder that held controlled documents or GxP records. IT can produce the evidence, but the decision that the move is complete and acceptable is a quality decision. For low-risk folders, the business owner’s sign-off may be enough. Write down which is which before the move starts, so nobody is negotiating approval levels with files half migrated.

Freeze the Old Share, Then Retire It

Once a folder is verified, the old copy should stop changing. If people can keep editing files on the share after the move, you now have two versions of the truth, and the new system is already out of date. Retirement is a sequence, not a single switch.

The Retirement Sequence

Freeze the Context, Not Just the Files

AGIT’s archiving guideline recommends that “all information is frozen at the time of archiving,” and for on-line archives it stresses freezing historical results and report formats, including names such as company, department, and user names.¹⁰ The same idea applies when a share is retired. Folder names, department codes, and user accounts that appear in the old paths may not exist a year from now. Record what they meant in the closure report, so that a reader in ten years can tell that “QC-MICRO-SITE2” was the microbiology lab at a site you later sold.

Stop the Share From Growing Back

The last step is the one most projects skip. If people had a reason to use the share, they will find a new place to do the same thing unless the reason is addressed. Before you close the project, agree on where each kind of working file now goes, write it into the document control or records procedure, and set up a simple check, such as a quarterly review of new team sites and file shares, to catch a new uncontrolled store early. A retired share that is replaced six months later by an unmanaged team site has not been retired. It has been moved.

Owners, Decisions, and the Closure Report

A shared drive retirement touches every function, and it runs over months. The governance does not need to be heavy, but it does need to be written down. The test is whether someone who joins the company in five years could read the project file and understand what was on the share, where it went, and who decided.

Roles That Need Names

Put the Project Under Change Control

Moving GxP records from one storage location to another is a change to how those records are kept. Handle it through change control, with the migration plan as the controlling document. The plan should describe the scope, the classification rules, the destinations, the metadata to keep, the tool and its tested settings, the reconciliation method, the read-only and retirement steps, and the approval levels. It does not need to be long. It needs to be specific enough that a second team could repeat the work and get the same result.

Treat any data migration into a validated system, such as a DMS, eTMF, or eQMS, as part of that system’s validated state. The migration step itself should be tested on a sample before the bulk run, with the test results kept as evidence. Where the destination is a simple read-only archive, the focus shifts to proving that the archive keeps files unchanged, controls access, and lets authorized people find and open files when asked.

The Decision Log

Keep one running log of decisions that affect records: a folder classified as working files after the owner confirmed it, near-duplicates kept because nobody could tell which was used, a format conversion approved with its reason, a superseded stability dataset approved for disposal with its justification. Each entry needs a date, a decision, a reason, and a name. This log is what lets you answer a question about a single file years later without reconstructing the whole project.

The Closure Report

When the share is retired, write a closure report and file it as a record. It should include:

• The share or site name, location, and the dates it was set to read-only, blocked, and deleted.
• The baseline totals, and the final reconciliation showing where every file went: each destination, approved deletions, and exceptions.
• The migration manifests and hash reports, or a reference to where they are kept.
• The decision log and the exceptions log.
• A glossary of old folder names, department codes, and accounts that appear in original paths.
• The final snapshot’s location, owner, and end date.
• Evidence of decommission and storage sanitization.

Measures That Show Progress

Leadership will want to know how the project is going. Useful measures are simple counts from the project’s own records: shares retired against the plan, percentage of baseline files with a confirmed outcome, number of open items in the unresolved queue, number of exceptions awaiting a decision, and recurring access attempts against read-only shares. Avoid measuring progress by terabytes moved. Moving data quickly is easy. Moving it with every outcome accounted for is the work.

Conclusion

Retiring a shared drive in a GxP company is less about the move than about the decisions around it. The files are the easy part. What takes care is knowing what each file is, where it should live, how long it must be kept, and how you will prove later that nothing was lost or changed along the way. A baseline scan with hashes, a four-bucket classification, a destination tied to the retention schedule, a migration that keeps original dates and paths as named fields, a reconciliation that adds up exactly, and a staged freeze before deletion: together these give you a project you can explain to an inspector in a few minutes, using documents rather than recollection.

Sakara Digital works with pharma and biotech organizations on document and records projects like this one, from the first inventory to the closure report. If you are planning to retire a shared drive or bring an unmanaged SharePoint library under control and want an independent view on where to start, we are happy to have that conversation.

For Further Reading