Egnyte to SharePoint migration requires solving structural mismatches in permissions, metadata, and path limits — not just moving files. Plan your target architecture before writing a single script.
Migrating from Egnyte to SharePoint Online is a structural transformation, not a simple file copy. Egnyte uses a hybrid, folder-centric architecture with explicit per-folder ACLs and custom metadata sections, while SharePoint Online relies on a site-and-library hierarchy governed by Microsoft 365 Groups, inherited permissions, and a 400-character decoded URL path limit. Microsoft's native Migration Manager supports Egnyte as a source but does not migrate version history, custom metadata, or external sharing links. Full-fidelity migrations require either third-party tooling with verified Egnyte connectors or a custom API-based ETL pipeline built against Egnyte's File System/Permissions/Metadata APIs and Microsoft Graph.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Migration Manager does not migrate Egnyte version history
Only the latest version of each file is transferred. It also does not recreate external sharing links, does not automatically share with external collaborators, and does not support Egnyte group mapping. Microsoft's own documentation advises requesting increased API rate limits from Egnyte before starting. (learn.microsoft.com)
Shorten site names and library names before you shorten folders
The 400-character limit counts the decoded site and library path too, not just the visible folder tree. (support.microsoft.com)
Native Graph uploads preserve timestamps but not authorship
fileSystemInfo is writable, but createdBy and lastModifiedBy are read-only on driveItem. If audit trails require original authorship, a Graph-only pipeline won't satisfy that requirement.
Do not ignore the Retry-After header
Microsoft Graph will continue to throttle your application if you retry before the specified delay. Exponential backoff with jitter is the minimum viable retry strategy.
This is a simplified skeleton. Production code must include
exponential backoff with jitter, dead-letter queues for permanently failed files, structured logging, checkpointing to a local database, and eTag-based conflict detection (If-Match headers returning 412 Precondition Failed) to prevent silent overwrites during delta sync windows.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Decide what content deserves to move before you plan how to move it.
Objective A content inventory with a keep/rewrite/retire decision on every article and an agreed URL strategy.
Keep these open
-
Inventory all content in Egnyte
Count articles, categories, attachments, images and embedded media, and pull page views and last-updated dates for each article. Usage data is what makes the next decision defensible rather than political.
Data Profiler Get real record counts instead of estimating from memory -
Make a keep, rewrite or retire call on every article
Most knowledge bases are half stale. Migrating everything imports the staleness and doubles the work; use views and last-updated to triage, and get the owning team to confirm. This usually removes 30-50% of scope.
Migrating stale content is the most common knowledge-base migration mistake — it costs effort and actively degrades the new site.
-
Agree the URL and redirect strategy
Decide the SharePoint URL structure and whether you can serve 301 redirects from the old paths. Public help centres carry real search traffic and inbound links; losing it is a measurable commercial impact.
Without 301 redirects from old article URLs you lose accumulated search ranking and every external link and bookmark breaks.
-
Map the information architecture
Document the current category tree and design the target one, checking whether SharePoint supports your nesting depth. Deeply nested hierarchies frequently have to be flattened, which changes navigation for everyone.
-
Confirm permissions, audiences and localisation scope
Establish which content is public, internal or restricted, and how SharePoint models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.
Don't move on until
- Full content inventory with page views and last-updated dates
- Keep / rewrite / retire decision recorded per article
- URL and redirect strategy agreed with whoever owns SEO
02 Data Audit Audit the markup, the links and the assets — that is where KB migrations break.
Objective A content export with markup, internal links and every embedded asset accounted for.
Keep these open
-
Export content and assess markup fidelity
Export articles in the richest format available and inspect what survived: tables, code blocks, callouts, nested lists, anchors and embedded video. Rich formatting is where fidelity is lost, and it is lost quietly.
HTML-to-Markdown conversion routinely mangles nested lists, tables and code blocks. Inspect the output rather than trusting the converter.
Data Profiler Profile the Egnyte export for nulls, outliers and type drift -
Inventory every internal link and cross-reference
Extract all internal links, anchor links and article cross-references. These break by default: the target URL structure differs, so every internal link needs rewriting as part of the load, not afterwards.
Internal links left pointing at old URLs turn the new knowledge base into a maze of 404s on day one.
-
Inventory images, attachments and embedded media
List every asset with its URL, size and type, and confirm each still resolves. Assets hosted on the old platform's CDN will 404 the moment you decommission it, so they must be rehosted, not referenced.
Images referenced from the source platform's CDN break when the old account closes. Download and rehost every asset.
-
Find and fix broken links and orphans
Crawl for existing broken internal and external links, and find articles no category links to. Fix them before migrating — a migration is a bad time to discover pre-existing rot.
-
Check for PII and internal information in public content
Scan for customer names, internal hostnames, credentials in code samples and screenshots containing real data. Republishing these on a public help centre is a disclosure, and screenshots are the usual culprit.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Normalise metadata
Standardise authors, tags, timestamps to UTC, and locale codes. Author mapping needs a decision for people who have left — attribution to a deleted user usually fails the import.
-
Audit logs
→ Archived export (CSV/JSON). Export from Egnyte's Audit Reporting API and store in Azure Blob or a compliance archive. Historical logs do not transfer into Microsoft 365.
CSV Validator Catch broken headers and ragged rows in the raw export -
Export and archive Egnyte audit logs
Historical logs don't transfer. Export via Egnyte's Audit Reporting API and store in a compliance archive.
Egnyte → SharePoint specifics
- Best for
- Small datasets under 500 GB with flat structure and no complex permissions
Don't move on until
- Content exported with markup fidelity assessed
- Every internal link and asset reference inventoried
- Broken links and missing assets fixed or logged
03 Field Mapping Map structure, metadata, permissions and — above all — URLs.
Objective A mapping covering article fields, taxonomy, permissions and a complete old-to-new URL map.
Keep these open
-
Map the article schema
Map title, body, excerpt, author, dates, status, tags, SEO metadata and any custom properties. Confirm which fields SharePoint lets you set on import versus which it computes — computed dates are a common surprise.
Schema Mapper Opens pre-loaded with the Egnyte → SharePoint field pair -
Map the taxonomy and hierarchy
Map categories, sections and tags to the target structure, resolving any nesting-depth limit explicitly. If you must flatten, decide how the lost level is preserved — usually as a tag or a title prefix.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map permissions and audience segmentation
Map public, logged-in, and role-restricted visibility to SharePoint's model. Verify the mapping deliberately: internal content accidentally published publicly is the highest-severity failure in this whole category.
Permission mapping errors publish internal documentation to the open web. Verify visibility on every restricted article after load.
-
Build the complete old-to-new URL map
Produce a row per article mapping the old URL to the new one, then confirm exactly where the 301s will be served — SharePoint, a CDN, or your own web layer. Without this artifact the redirect step cannot be executed at all.
-
Define the markup conversion and link-rewrite rules
Specify how each markup construct converts and how internal links are rewritten using the URL map. Write it as a repeatable transform, not manual edits — you will run it more than once.
Data Format Converter Reshape the export into the format SharePoint's importer expects -
Plan localisation and freeze the spec
Confirm how translated articles link to their source language in SharePoint, then version and sign off the mapping spec.
Egnyte → SharePoint specifics
- Private folder (user home)
- → OneDrive for Business. Personal files migrate to the user's OneDrive. If files are shared departmentally, route them to a SharePoint document library instead.
- Shared folder (department/team)
- → SharePoint Document Library within a Team Site. One library per department or major logical grouping.
- Folder hierarchy
- → Folder hierarchy within a Document Library. Flatten deep nesting — SharePoint performs poorly beyond 5–6 levels, and the 400-character path limit will bite.
- Folder permissions (user/group ACLs)
- → SharePoint site/library/folder permissions via M365 Groups or Entra ID security groups. Egnyte permission levels (Owner, Full, Editor, Viewer) must map to SharePoint permission levels (Full Control, Edit, Contribute, Read). Avoid item-level permissions wherever possible.
- External sharing links
- → SharePoint sharing links (Anyone / Specific people / Organization). All Egnyte links break on migration. Re-create and notify external recipients.
Don't move on until
- Article schema and taxonomy mapped
- Permission and audience model mapped to target equivalents
- Complete URL map produced and redirect method confirmed
04 Test Migration Pilot the hardest articles, then read them.
Objective A pilot load whose formatting, links, assets and search all hold up under human review.
Keep these open
-
Configure SharePoint with the agreed structure
Create the category tree, permission groups, locales and branding before loading. Articles loaded before their categories exist land uncategorised and have to be moved by hand.
-
Pick the most difficult articles as the pilot
Choose 20-50 articles for difficulty: the longest, the most heavily formatted, ones with tables and code blocks, deep internal linking, many images, embedded video, restricted visibility, and non-Latin scripts. Easy articles prove nothing.
-
Run the conversion and load with link rewriting
Apply the markup conversion, rewrite internal links from the URL map, upload and re-reference assets, then load. Log every conversion warning rather than suppressing it.
-
Read every pilot article side by side
Open source and target together and compare rendering. This step is manual on purpose: no automated check catches a table that collapsed into a paragraph or a code block that lost its indentation.
-
Click every link and load every asset
Verify each internal link resolves, each image loads from the new host, each attachment downloads and each embed plays. Assets still served from the old CDN are the defect that surfaces only after decommissioning.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Test search and permissions
Search for known terms and confirm the right articles rank, then verify every restricted pilot article is invisible to an anonymous browser. Test permissions from a logged-out session, not an admin one.
Don't move on until
- Complex articles render correctly with formatting intact
- Every internal link and asset in the pilot resolves
- Search returns sensible results for the pilot content
05 Cutover Publish, redirect, and keep the search traffic.
Objective All in-scope content live in SharePoint with redirects serving and search engines informed.
Keep these open
-
Load the full content set ahead of the switch
Run the full conversion and load into SharePoint, unpublished or on a staging domain. Content migration differs from data migration here: you can stage the whole thing before anyone sees it.
-
Publish the runbook with the redirect step first-class
Sequence the freeze, final delta, publish, redirect activation, sitemap submission and link updates, with owners for each. Redirect activation is the step with lasting commercial consequences, so it gets explicit ownership.
-
Freeze editing and migrate the delta
Stop editing in Egnyte, then convert and load anything changed since the full load. Announce the freeze to every team that publishes — content teams are used to editing whenever they like.
-
Publish and verify permissions live
Publish the content set, then immediately verify restricted articles are not publicly reachable using an anonymous session. Do this before announcing the new site, not after.
Verify restricted content from a logged-out browser. An admin session will show you everything and tell you nothing.
Migration Validation Tool Confirm the final delta landed before you reopen -
Activate 301 redirects and submit the sitemap
Turn on the redirects from the URL map, then spot-check a sample of high-traffic old URLs and confirm each returns 301 to the right article. Submit the new sitemap and keep the old one reachable until search engines have recrawled.
Redirect chains and redirect loops both leak ranking. Verify each redirect resolves in a single hop.
-
Repoint in-product and support links
Update help links embedded in your product, in support macros, in email templates and in onboarding material. These are the links your existing customers actually use, and they are easy to forget.
Don't move on until
- All content loaded, categorised and correctly permissioned
- 301 redirects live and verified from a sample of old URLs
- Sitemap submitted and support links repointed
06 Validation Watch traffic, links and search rankings for weeks, not hours.
Objective Verified content completeness, healthy redirects, and search traffic recovered to baseline.
Keep these open
-
Reconcile content counts and assets
Compare article counts by category and status, plus asset counts, against source. Confirm every article in the keep list is present and every retired one genuinely is not.
Migration Validation Tool Reconcile Egnyte and SharePoint record-for-record -
Crawl the new site for broken links and assets
Run a full crawl for 404s, broken images and missing attachments, and fix everything it finds. Repeat the crawl after the fixes rather than assuming they worked.
-
Verify the redirects at scale
Test every mapped old URL for a single-hop 301 to the right destination. Chains and loops both leak ranking and are invisible unless you check the whole map, not a sample.
-
Monitor organic traffic and rankings for four to eight weeks
Track organic sessions, impressions and rankings for your top articles against baseline. A dip in the first two weeks is normal; one that has not recovered by week six is a redirect or indexing problem to investigate.
Do not decommission the old platform until search traffic has recovered — you may still need the old URLs to diagnose a ranking loss.
-
Verify search, permissions and feedback loops
Confirm on-site search returns good results for real queries, re-verify restricted content from a logged-out session, and check article feedback and analytics are collecting.
-
Sign off and decommission on a delay
Get acceptance against the Discovery criteria, keep Egnyte available read-only until traffic has recovered, take a final export, and only then close the account.
-
Record count
Total files and folders, source vs. target. Zero tolerance for missing files.
-
Rebuild workflows
Egnyte Workflows must be recreated as Power Automate flows.
-
Configure Microsoft Purview
Apply retention labels, sensitivity labels, and DLP policies to match former Egnyte Governance rules.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for
Egnyte → SharePoint specifics
- File integrity
- SHA-256 checksum comparison on a statistical sample (5–10% random plus targeted sample of largest files, deepest paths, and most-permissioned folders). Full checksums for regulated or critical directories.
- Path validation
- Confirm no files were skipped due to path length, character issues, or blocked file types. Check the dead-letter queue.
- Permission validation
- Spot-check permissions across different hierarchy levels. Verify external shares work.
- Metadata validation
- Confirm values transferred correctly to SharePoint columns on a sample of files.
- Timestamp validation
- Verify created and modified dates are preserved, not overwritten with migration timestamps.
Don't move on until
- Article counts reconciled and no broken links remain
- Redirects returning 301 with no chains or loops
- Organic traffic recovered to within tolerance of baseline
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Files and Folders | medium | Core file content migrates reliably, but deeply nested paths and restricted characters can cause silent failures due to SharePoint's 400-character URL limit. |
| Version History | high | Migration Manager does not migrate any version history, and third-party tools typically cap at 25 versions per file, making full version fidelity extremely difficult to achieve. |
| Custom Metadata | high | Egnyte's metadata sections and typed properties (enum, multi_value_enum, labels) have no native equivalent in SharePoint and require manual mapping to Site Columns or Managed Metadata term sets, with no automated migration path. |
| Folder Permissions (ACLs) | high | Egnyte's explicit per-folder ACLs with granular roles must be translated to SharePoint's inheritance-based model, and excessive permission breaking causes performance degradation beyond 5,000 unique entries per library. |
| User and Group Identity Mapping | medium | Egnyte users and groups must be mapped to Microsoft 365 identities, and Migration Manager does not support Egnyte group mapping, requiring manual or scripted identity reconciliation. |
| External Sharing Links | high | All Egnyte sharing links break completely after migration and must be manually recreated using SharePoint's own sharing link model, with no automated conversion available. |
| File Timestamps | low | Original created and modified timestamps can be preserved via Microsoft Graph's fileSystemInfo resource, but this requires explicit handling during the upload process. |
| Hybrid/On-Premises Storage Node Data | medium | Content on Egnyte on-prem storage nodes must be synced to Egnyte's cloud layer before extraction, adding a prerequisite step that can delay migration timelines. |
| Folder Structure and Hierarchy | medium | Egnyte's flat folder tree must be redesigned into SharePoint's site-and-library hierarchy, and incorrect mapping leads to costly post-migration restructuring. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Hierarchy and Structure Mapping
Egnyte's flat folder tree (Private and Shared folders) must be deliberately restructured into SharePoint's multi-tiered site collection, site, and document library hierarchy before migration begins.
Permission Model Incompatibility
Egnyte's explicit per-folder ACLs with an inheritsPermissions flag must be translated into SharePoint's inheritance-based permission model, where breaking inheritance at scale degrades performance and is limited to 5,000 unique permission entries per library.
Custom Metadata Transformation
Egnyte's metadata sections with typed properties (enum, multi_value_enum, labels, etc.) have no 1:1 equivalent in SharePoint and must be manually mapped to Site Columns, Content Types, or Managed Metadata term sets.
File Path Length Limits
SharePoint enforces a 400-character decoded URL path limit and restricts certain characters, which can silently fail deeply nested or long-named files migrated from Egnyte's more permissive path structure.
Version History Loss
Microsoft's native Migration Manager transfers only the latest file version, and even third-party tools like MigrationWiz cap version migration at 25 versions per file, making full version history preservation a significant engineering challenge.
API Rate Limit Constraints
All migration methods—native, third-party, and custom—are constrained by Egnyte's default API rate limits, requiring advance coordination with Egnyte to request increased thresholds before large-scale extraction.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Does Microsoft Migration Manager migrate Egnyte version history?
No. During an Egnyte migration using Migration Manager, only the most recent version of each file is transferred. If you need version history preserved, you must use a custom API-based migration or a managed migration service that supports sequential version uploads via the Microsoft Graph API.
What is the SharePoint file path character limit for Egnyte migrations?
SharePoint Online enforces a 400-character limit on the decoded file path, which includes the site name, document library name, folders, and file name — but not the tenant domain. Egnyte has no equivalent restriction, so paths must be scanned and shortened before migration.
What are Egnyte's API rate limits for migration?
Egnyte defaults to 1,000 API calls per day and 2 requests per second, enforced per access token. For production migrations, these are too low — you must contact Egnyte to request increased limits before starting. Monitor the X-Accesstoken-Qps-Current and X-Accesstoken-Quota-Current headers proactively.
How do you map Egnyte custom metadata to SharePoint?
Egnyte metadata properties (string, integer, decimal, date, enum, labels, multi_value_enum) must be manually mapped to SharePoint Site Columns, Choice columns, or Managed Metadata term sets. There is no automatic 1:1 mapping. Each property type requires a transformation decision documented before migration.
Can Microsoft Graph preserve createdBy and modifiedBy during an Egnyte migration?
Not with plain Graph uploads alone. The createdBy and lastModifiedBy fields on driveItem are read-only. The fileSystemInfo facet can preserve client-side created and modified dates (timestamps), but original authorship requires additional approaches beyond standard Graph API uploads.