Why this matters

File migrations look like a copy job. They are not. The hard part is not moving the bytes; the hard part is preserving the permission tree (who could see what), the shared-link history (every external link your customers and partners have already bookmarked), the version history (the audit trail that compliance depends on), and the folder semantics (the folder names your team has built workflow around for years). Done badly, you destroy the institutional knowledge encoded in the file system. Done well, the move is invisible.

Common moves

Source → destination patterns we deliver.

ShareFile → SharePoint

The most common Citrix-era cleanup. ShareFile permissions map cleanly into SharePoint site collections + groups. Long external-share links rewritten + tracked.

ShareFile → Box

For customers staying on Box for the storage tier. Permissions map; collaboration metadata preserved.

ShareFile → Google Drive

Sharefile shared folders → shared drives. Permission scope explicitly mapped per folder.

Box → SharePoint

Box collaboration model maps to SharePoint groups + library permissions. External share links rewritten.

Box → Google Drive

Box folders → shared drives. Box notes → Google Docs where conversion is clean.

Dropbox / Dropbox Business → SharePoint / OneDrive / Drive

Personal Dropbox → OneDrive (per user). Dropbox Business shared folders → SharePoint sites or Drive shared drives, depending on collaboration scope.

SharePoint ↔ Google Drive

Bidirectional moves between the two big collaboration suites. Site → shared drive mapping designed in Discovery.

OneDrive consolidation

Multiple personal OneDrives → SharePoint sites. Useful after acquisition or when "everyone has their own" became a problem.

What we preserve

Permissions, links, history, semantics.

  • Permission mapping. Per-folder ACLs preserved. Where source and destination permission models do not align cleanly, we design the mapping rules in Discovery and you sign off before any move.
  • Version history. Retained where the destination supports it. Where it does not (rare), we capture the version chain into an archive copy that lives alongside.
  • External-share links. Every external share link in the source is cataloged. After cutover, the destination links replace them — and we deliver a rewrite list of every link your customers, partners, or website have bookmarked, so you can update outbound communications.
  • Folder semantics. Folder names, structure, and emoji conventions preserved. We do not "clean up your folders" without explicit scope.
  • File metadata. Created-by, modified-by, modified-date preserved where the destination supports the field.
  • Notebook + doc fidelity. Box Notes, OneNote, Google Docs converted to the closest equivalent in the destination. Conversion-loss issues flagged in the verification report.

Education

What to think about before signing.

Why "permission mapping" is the hardest part

Every file-storage product has its own permission model. ShareFile uses folders + access levels. Box uses collaborator types. SharePoint uses groups + scopes. Drive uses sharing + shared drives. The combinations are not symmetric — what one product allows, another does not, and vice versa. The Discovery phase maps every source-permission pattern to its closest destination equivalent, then surfaces the residual gaps so you decide how to handle them BEFORE the cutover, not in the middle of one.

Why version history matters in regulated industries

For financial services, healthcare, legal — version history is part of the audit trail. A document that has 47 revisions over four years tells the regulator a different story than the same document at "version 1." If the destination does not preserve full version history natively, we capture the version chain into an archive bundle that lives alongside the live file and can be served on demand.

Why "shared link rewrite" is non-negotiable

Most file-share systems use opaque tokens in the share URL. After migration, the old URL stops working — and every customer, partner, vendor, contractor, or auditor who has the old link in their email or bookmarks gets a 404. We deliver a rewrite list: every old shared URL, every new equivalent. Your team uses the list to update outbound comms; some customers also publish a redirect list at a stable URL their partners can subscribe to.

When to split into multiple migrations

Multi-TB jobs, multiple regulated-data classifications, or "we have 47 ShareFile sites and they all do something different" usually benefit from splitting into 2–4 phased migrations rather than one big-bang. The Discovery output recommends the sequencing. Phasing also limits blast-radius if anything has to roll back.

Ready for a cloud-migration discovery call?

Tell us source, destination, rough volume, and timeline. We will come back with a written plan and quote within five business days.