SharePoint-to-Egnyte migration breaks on permissions (Egnyte is folder-level only), metadata (no content types or hierarchical terms), and API throttling on both sides. Plan the data model mapping before moving a single file.
There is no seamless native migration path from SharePoint Online to Egnyte. SharePoint's data model—built on Sites, Document Libraries, managed metadata term stores, content types, and inheritance-based permissions—has no direct equivalent in Egnyte's flat, folder-centric architecture with explicit folder-level ACLs. While Egnyte offers a native SPO migration tool for file transfers, it cannot migrate permissions, metadata column values, or version history, meaning significant custom mapping and post-migration configuration work is required. Non-file SharePoint content such as lists, site pages, wiki pages, and OneNote notebooks must be exported or archived separately, as Egnyte has no equivalent constructs.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
SharePoint list view threshold trap
When a document library exceeds the list view threshold, a Graph API query can return a 429 error with an activityLimitReached error code. This is not rate-limit throttling — it is a SharePoint threshold issue disguised as a 429. If you see this on specific libraries, check the item count.
Run at least one pilot on a representative site that includes a deep folder tree, broken
Run at least one pilot on a representative site that includes a deep folder tree, broken inheritance, content types, managed metadata, and Teams-backed files. A pilot on a clean library tells you almost nothing about production risk.
Looking for other destinations? This section focuses on SharePoint
For a full breakdown of alternatives like Confluence, Notion, or direct-to-Egnyte paths, see our Quip Migration Decision Guide.
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 SharePoint
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 Egnyte 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 Egnyte 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 Egnyte models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.
-
Record count comparison
Compare total files and folders between source and target, broken down by site/library vs. Egnyte folder.
Vendor Evaluator Score Egnyte against alternatives on weighted criteria
SharePoint → Egnyte specifics
- Hybrid cloud + on-prem storage
- Egnyte's Storage Nodes and on-prem cache keep active projects at local speed while archiving completed work to the cloud. AEC, engineering, and media teams working with multi-gigabyte CAD or video files need LAN-speed access that SharePoint cannot deliver.
- Simpler file management
- SharePoint's Sites/Libraries/Lists model requires significant IT overhead. Egnyte's folder-centric model maps directly to how most teams think about file storage.
- Large file workflows
- SharePoint supports files up to 250GB, but Egnyte handles large file sync better through its desktop client and storage nodes for many practical workflows.
- Vendor diversification
- Reducing full dependency on the Microsoft 365 ecosystem, especially when SharePoint's collaboration features go underutilized.
- Industry compliance
- Egnyte provides HIPAA-required encryption, access logging, and data loss prevention natively — without requiring Microsoft Purview add-ons.
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 SharePoint 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.
-
Inventory and audit
Full scan of SharePoint: site collections, libraries, file counts, sizes, permissions (including inheritance breaks), metadata schemas, content types, managed metadata term store, checked-out files, Power Automate flows, OneDrive scope, and non-file assets (lists, pages, OneNote).
SharePoint → Egnyte specifics
- Post-migration audits
- Run periodic checks for 30–60 days after migration.
- Assessment & Proof of Concept (2–3 weeks)
- API-driven audit of document counts, Live App usage, and permission structures.
- Full Extraction & Cutover (4–8 weeks)
- Phased extraction, transformation, and loading into SharePoint, followed by a final delta sync over a cutover weekend.
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 Egnyte lets you set on import versus which it computes — computed dates are a common surprise.
Schema Mapper Opens pre-loaded with the SharePoint → Egnyte 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 Egnyte'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 — Egnyte, 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 Egnyte's importer expects -
Plan localisation and freeze the spec
Confirm how translated articles link to their source language in Egnyte, then version and sign off the mapping spec.
SharePoint → Egnyte specifics
- Transform
- Flatten Sites/Libraries hierarchy, convert column values to Egnyte metadata format, map permissions to explicit folder ACLs, restructure item-level unique permissions into dedicated subfolders, and sanitize file/folder names.
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 Egnyte 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.
SharePoint → Egnyte specifics
- File integrity checks
- Run MD5/SHA-256 checksum comparisons on a 5–10% statistical sample and full checksums for critical compliance directories.
- UAT process
- Require department leads to sign off on their specific folder structures and verify access before the final cutover.
- Pilot Migration (1–2 weeks)
- End-to-end migration of a representative department to validate mappings and user acceptance.
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 Egnyte 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 Egnyte, 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 SharePoint, 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.
-
Map users and groups
Match Azure AD / Entra ID users and M365 groups to Egnyte users and groups. Handle mismatches for external/guest users and service accounts.
-
Run the seed migration
Bulk-copy content first via Graph API (streaming for large files). Export permissions, column values, and version history. Do not block the initial seed on deep metadata transforms if they slow down throughput.
-
Load into Egnyte
Upload via File System API (chunked upload for large files), apply metadata via Metadata API, set permissions via Permissions API.
SharePoint → Egnyte specifics
- Design Egnyte target
- Map SharePoint sites to Egnyte top-level folders. Define group/permission model, custom metadata schema, Governance policies, and storage node deployment if hybrid access is needed.
- Provision Egnyte environment
- Create top-level folders, user home folders, groups, custom metadata fields, and Governance rules. Request API rate limit increases from Egnyte support.
- Delta sync passes
- Use Graph API delta queries to capture changes during the migration window. Repeat until daily change volume is small enough for the final cutover.
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 SharePoint and Egnyte 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 SharePoint available read-only until traffic has recovered, take a final export, and only then close the account.
SharePoint → Egnyte specifics
- Permission validation
- Spot-check folders across different hierarchy levels to verify that SharePoint inheritance breaks translated correctly to Egnyte explicit ACLs.
- Metadata verification
- Confirm that SharePoint column values transferred to Egnyte custom metadata fields with correct data types.
- Timestamp validation
- Verify that created/modified dates are preserved.
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 | low | Core file and folder hierarchies transfer reliably via Egnyte's native tool or third-party platforms, though path length limits and filename character restrictions should be validated. |
| Folder-Level Permissions | medium | Egnyte's native migration tool does not transfer permissions at all, so they must be recreated manually or via the Permissions API after file migration is complete. |
| Item-Level Permissions | high | Egnyte does not support file-level permissions, so every SharePoint file with unique permissions requires restructuring into a dedicated subfolder with its own ACLs. |
| Managed Metadata and Term Stores | high | SharePoint's hierarchical term sets and managed metadata columns have no equivalent in Egnyte's flat metadata model, resulting in significant fidelity loss or requiring custom transformation logic. |
| Content Types | high | SharePoint content types that bundle columns, behaviors, and workflows have no Egnyte equivalent and must be decomposed or abandoned during migration. |
| Version History | high | Neither Egnyte's native tool nor most third-party platforms migrate SharePoint version history, so prior versions must be exported separately or accepted as lost. |
| SharePoint Lists | high | SharePoint lists are structured data stores with no Egnyte counterpart; they must be exported to CSV/Excel or migrated to a separate database before decommissioning. |
| Site Pages and Wiki Content | high | SharePoint site pages, wiki pages, and news posts are rendered HTML content with no Egnyte equivalent and must be archived as static exports. |
| OneNote Notebooks | high | OneNote .one files are explicitly unsupported by Egnyte's native migration tool and require separate export to PDF or another format before transfer. |
| File Timestamps | medium | Created and modified timestamps may not be preserved by all migration methods; third-party tools like Movebot claim timestamp preservation, but this should be validated in a pilot migration. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Permission Model Incompatibility
Egnyte only supports folder-level permissions, so any SharePoint file with unique item-level permissions must be restructured into a dedicated subfolder with its own ACLs.
Metadata Fidelity Loss
SharePoint's hierarchical managed metadata term stores, content types, and typed site columns cannot be faithfully represented in Egnyte's flat custom metadata fields, and Egnyte's Metadata API remains in Beta.
API Rate Limit Constraints
Both Microsoft Graph API throttling (especially during peak hours) and Egnyte's strict per-token rate limits (as low as 1,000 calls/day on Business plans) can stall or block large-scale programmatic migrations.
Non-File Content Has No Equivalent
SharePoint lists, site pages, wiki pages, news posts, OneNote notebooks, and Loop components have no Egnyte counterpart and must be exported, converted, or archived outside the migration pipeline.
Site Hierarchy Flattening Is Irreversible
SharePoint's multi-level Site → Document Library → Folder hierarchy must be collapsed into Egnyte's flat shared-folder structure, requiring careful upfront planning since the flattening cannot be undone.
Job Size and Concurrency Limits
Egnyte's native migration tool caps single jobs at 5TB or 5 million objects with a maximum of 50 concurrent jobs, forcing large enterprises to split migrations into multiple coordinated batches.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Item-level permissions
— Files with unique SharePoint permissions require creating a new Egnyte folder just for that file, applying the specific ACL to the folder, and placing the file inside. Pre-process these during the audit phase and map the new folder structures before writing extraction logic.
Large files
— SharePoint supports files up to 250GB. Egnyte's Web UI upload limit is 100GB on Team/Business plans and 150GB on Enterprise Lite/Enterprise plans. Massive files require desktop sync tools or specialized API chunking.
Checked-out files
— Files actively checked out or locked for co-authoring in SharePoint will fail extraction. Force check-in programmatically before the final sync, or flag for manual handling. Libraries with Checkout or Validation columns can sync as read-only, making manual download paths misleading.
OneNote notebooks
— OneNote notebooks stored in SharePoint are not standard files — they are complex directories with their own sync mechanism. They cannot be migrated as-is to Egnyte and must be exported to PDF or .docx.
Teams-connected sites
— SharePoint sites backing Teams channels have specific structures. Files migrate fine, but Teams-specific context (channel conversations, tabs) is lost.
Duplicate and case-sensitive names
— Egnyte is not case-sensitive. Case-only name differences will cause collisions. Your transformation layer must sanitize filenames and handle deduplication.
Large flat folders
— Egnyte enforces a maximum of 50,000 immediate children (files or subfolders) per folder. Plan restructuring if any SharePoint library exceeds this.
Invalid timestamps
— Egnyte rejects files with impossible timestamps. Pre-scan for bad source timestamps so they do not silently become skipped content.
Site pages and wiki pages
— No Egnyte equivalent. Archive as PDFs or accept the loss.
Power Automate, Teams tabs, Outlook links, list-backed apps
— Inventory early. None of these follow a file move automatically.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can Egnyte's native migration tool migrate SharePoint permissions?
No. Egnyte's native SPO migration tool, released in March 2026, migrates files and folder structures but explicitly does not migrate permissions. You must apply Egnyte folder permissions manually or via the Permissions API after the file transfer completes.
How do you handle SharePoint item-level permissions in Egnyte?
Egnyte does not support file-level permissions — only folder-level. Files with unique SharePoint permissions must be moved into dedicated Egnyte subfolders with appropriate ACLs applied at the folder level. This restructuring should be planned during the pre-migration audit.
What are Egnyte's API rate limits for migration?
Egnyte enforces rate limits per access token: Business plans get 1,000 calls/day at 2 QPS, Enterprise Lite/Elite gets 2,000/day, and Enterprise/Ultimate gets 4,000/day. For any meaningful migration, contact api-support@egnyte.com to request a temporary rate limit increase before starting.
Does Egnyte support SharePoint managed metadata and content types?
Not directly. Egnyte's custom metadata model is flat — no hierarchical term stores, no content types. SharePoint managed metadata must be flattened into Egnyte dropdown fields or tags, and content type schemas will need simplification. Egnyte's Metadata API is also still in Beta.
What is the maximum migration job size for Egnyte's native tool?
A single migration job in Egnyte's native SPO migration tool is limited to 5TB of data or 5 million objects. For larger environments, split into multiple migration jobs by site group. Migrating more than 5,000 sites in a single job will also be very slow.