Migrate ShareFile to SharePoint and OneDrive
Move your practice’s ShareFile documents to SharePoint or OneDrive. Map client folders, rebuild permissions, check every transfer and plan cutover.
- Published
- Updated
To migrate ShareFile to SharePoint or OneDrive, export authorised files to protected staging storage, then upload them to the prepared destination. Rebuild access separately. Keep ShareFile available until the copied documents and client upload routes pass your acceptance checks.
What Moves and What Must Be Rebuilt
A ShareFile migration moves file content through a staged download and upload. This route uses separate source and destination steps, with manual access rebuilding. It does not treat ShareFile as a native Microsoft migration connector.
ShareFile’s backup guidance says that files and folders are included, while permissions are not preserved. Use the following matrix to decide what the practice must keep outside the copied folder.
| Item | Transfer route | What the copy retains | Retain or rebuild before acceptance |
|---|---|---|---|
| File content | Download, then upload | The downloaded file’s content | Open each intended destination file and compare it with the preserved source. |
| Folder hierarchy | Extract the download and load mapped folders | Downloaded folder structure, subject to destination restrictions | Record renamed folders and every changed destination path. |
| Versions | Preserve required historical versions separately | The specific files selected for transfer | Retain source version history. Keep required versions as separately labelled archive files if they are outside the download. |
| Metadata and timestamps | Keep source reports beside the mapping | File content can contain its own internal information | Record source creation and modification values. Rebuild required library fields and record destination differences. |
| Permissions | Rebuild in Microsoft 365 | ShareFile backup does not preserve permissions | Translate approved staff and client access into destination groups and item permissions. |
| Share links | Create destination links | Existing source links remain source addresses | Replace links in client messages and workflow templates. Revoke superseded access when authorised. |
| Staff and client accounts | Prepare destination identities | Files do not create Microsoft accounts or guest access | Provision staff accounts and invite approved clients through the selected sharing method. |
| Requests and reminders | Recreate outstanding collection work | A copied file is not a live request | Keep the request register and assign each open request a destination and owner. |
| Audit records | Export available reports and retain source evidence | A file upload does not recreate source event history | Preserve required access and change reports, then start destination logging under the practice’s policy. |
Use OneDrive for work or school for a staff member’s own working files. Put shared practice records in a SharePoint library owned and managed by the practice. Microsoft’s guidance distinguishes individual work from files written and managed by a team.
For a client group’s retained records, a team library avoids making ongoing access depend on one staff member’s OneDrive account. Record who manages that library when staff leave. Keep ShareFile in use if the replacement cannot yet support the practice’s required client access or outstanding requests.
Inventory Folders and Prepare the Destination
Start with a ShareFile Storage Detail Report and a separate folder mapping. ShareFile lists file name, type, size in MB and creation date in that report. Compare the report with the intended files, and note its size units when checking downloads.
An authorised administrator or employee with account-wide reporting permission can run ShareFile reports. Retain available Access, Access Change, Share, Request and Users reports for the relevant period. Report history can require several reporting periods, so save the full set the practice needs.
For every client folder, record the source path, destination site and library, intended staff group and approved client access. If a folder belongs in OneDrive, record its named account owner and the handover arrangement. Also record outstanding requests, retention requirements and links used in staff procedures.
Have the Microsoft 365 administrator prepare the destination before transfer. For OneDrive pre-provisioning, Microsoft requires the user to be allowed to sign in and have a SharePoint licence. A SharePoint administrator with that licence can provision it. Confirm the intended owner’s OneDrive exists before loading files.
For SharePoint, prepare the library and give the transfer operator permission to contribute files. Set staff access by role and client access by the specific client record. Check inherited site and library permissions before adding client folders.
Resolve destination restrictions in the mapping. Microsoft sets a 400-character limit for the decoded full path, including the file name. Shorten long paths and resolve blocked names or file types without changing the preserved source. Record each rename so the original file remains traceable.
Assign a migration lead and a separate acceptance reviewer. Prepare enough protected staging space and a retained backup. Restrict staging access to the transfer team, use encrypted storage and keep it out of personal sync folders.
The Tax Practitioners Board’s confidentiality guidance covers disclosures to cloud and outside providers. Resolve the client permission and disclosure required for the new arrangement before copying confidential records. The OAIC’s TFN guidance requires safeguards and access limited to staff who need that information.
Set a pause on source edits and incoming requests for the bulk transfer. Record who can authorise an exception and how the lead will capture it.
Move Files Into SharePoint or OneDrive
ShareFile documents the application bulk-download route for infrequent backups of 500 GB or less. For a larger or recurring export, have the authorised administrator arrange the documented ShareFile API/SDK backup route and reconcile its output in protected staging before destination import. Pilot one small folder before copying the practice’s full archive. The following example is fictional and uses empty demonstration documents, with no client information or real identification numbers.
The folder contains ID.pdf, Return.pdf and Deed.pdf for one anonymous client group. Map it to a restricted client folder in the prepared SharePoint library. For a separate staff-owned working folder, follow the OneDrive destination steps instead.
- Have the authorised ShareFile employee in the Super User Group open Shared Folders and select the relevant folder’s contents. ShareFile’s web backup steps download a ZIP. Work inside each required top-level folder, because the root Shared Folders view cannot download top-level folders directly.
- Save the ZIP in protected staging storage and preserve it separately. Extract a working copy. Confirm ID.pdf, Return.pdf and Deed.pdf are present and open before uploading anything. Match the intended file count and reported sizes, allowing for report rounding.
- Apply only recorded destination renames to the working copy. Stop if any export is missing, incomplete or unreadable. Re-download the affected items and repeat the staging check.
- For SharePoint, open the mapped site and library, then load the extracted folders through the supported Upload option or drag-and-drop. Confirm the actual destination path before starting.
- For a larger staged file share, use the SharePoint Migration Tool on a supported Windows machine. Sign in to the destination as its site administrator. Select the staged file-share source and mapped SharePoint destination, inspect scan issues and retain the migration report.
- For OneDrive, sign in to the intended work or school account and open its mapped destination folder. Upload the checked files there. Redirect shared practice records to the SharePoint library if one person’s ownership would undermine continuity.
- Review upload or migration errors. Reconcile every failed, renamed or omitted item with the mapping, then retry the affected work. Keep the source and preserved staging copy throughout.
- Rebuild the approved access groups and client permissions. Inspect inherited access again before creating replacement client links.
Microsoft’s upload guidance supports loading local files into OneDrive or a SharePoint library. Its migration tool supports staged file locations and destination scanning. Neither step restores ShareFile permissions from the downloaded files.
Do not upload the ZIP as a substitute for the mapped, extracted documents. A ZIP sitting in a library does not establish that staff can find and open each client record.
Check Client Access and Document Integrity
Accept the pilot only when every intended file opens and matches its preserved source. Counts alone cannot show whether the correct return or deed arrived.
| Fictional file | Content check | Access check | Expected acceptance result |
|---|---|---|---|
| ID.pdf | Compare pages with the demonstration source | Staff authorised for ID records can open it | Every page matches and access is limited to approved staff. |
| Return.pdf | Compare the full demonstration return | Assigned staff and the approved client can open it | The intended copy opens through the replacement link. |
| Deed.pdf | Compare all pages and attachments | Approved staff and the intended client have mapped access | The complete deed is in the recorded destination folder. |
Run access checks in separate signed-in sessions for an assigned staff member, the intended client and an unrelated client. The intended users must see only their mapped records. The unrelated client must fail when opening a copied record link directly.
Revoke a test recipient’s destination access and test again. Remove any alternate group or link that still grants that recipient access. Microsoft’s Specific people links require the named recipient to sign in. Anyone links give access to whoever holds the link, so they cannot prove client identity.
Recreate an outstanding upload request for the fictional client. Submit an empty demonstration file and confirm it reaches the mapped client record. Check staff notification and responsibility for filing that upload. Record any steps the destination needs staff to perform manually.
Microsoft file requests depend on Anyone links being enabled. That upload-only feature lets the sender upload without viewing other files in the folder. Use it only under the practice’s approved collection policy. If the required settings are unsuitable, use a restricted guest upload arrangement or another approved secure collection route.
Compare required versions, recorded timestamps and retained audit evidence with the transfer matrix. Reconcile each changed name and failed item before signing acceptance. A destination upload timestamp must not silently replace the historical record your practice needs.
Cut Over and Recover From Failed Acceptance
Cut over after the final copy passes the same checks as the pilot. Pause ShareFile edits and requests, then compare the source with the pilot inventory. Copy changed and newly received files, and resolve any conflicting destination edits before acceptance.
Have the reviewer sign off the file reconciliation and access results. Replace source links in staff procedures and request messages. Tell staff where to save documents and tell each client where to upload. Explain any new sign-in step before their next request.
Keep ShareFile, the preserved backup and the reports until acceptance and the authorised retention decision. Account cancellation has its own contract and access consequences. Assign it to the owner after the accepted records and required evidence are secure.
If access or reconciliation fails, stop destination edits and record the failure. Reopen the source workflow only with the practice’s authorisation. Account for destination-only uploads and edits before resuming, so the recovery does not lose work created after the copy.
Correct the failed mapping or permission, repeat the affected transfer and rerun its acceptance checks. Retain the error list and the source until the reviewer accepts the repair. Give the responsible administrator the affected path and error message if a supported upload still fails.
For a client who cannot use the destination, approve another secure upload route or an in-person handover. Never ask them to email a TFN or an ID document. Choose the alternative through your secure file sharing procedure and keep its records with the client.
Separate Migration From New-Client Collection
Moving historical folders does not collect missing answers or complete a new-client assessment. Keep document migration separate from the client form and the practice’s professional review.
Tax Genie collects new-client details through a guided form and checks submitted answers with rules and AI. It asks clients to correct fixable issues and chases missing information. The practice receives checked client information for its onboarding work.
The migration lead owns the ShareFile transfer. Your Microsoft 365 administrator owns destination access. Tax Genie’s collection and checking of new-client information is a separate job from those responsibilities.
Keep the folder mapping, unresolved exceptions and access decisions in the handover record. Add the reviewer’s file-check acceptance, the retained evidence location and the ongoing access owner. Use your document management procedure to keep that record with the practice’s filing and retention rules.
Hand the accepted library to its ongoing owner only when every intended document and replacement client route is accounted for.
See it with your own clients in mind
Tell us a little about your practice and we’ll walk you through Tax Genie.