Quick answer. Before you schedule an Egnyte to SharePoint migration, confirm Migration Manager supports your cloud, get Egnyte’s API limit raised, and plan to rebuild group access. Microsoft lists its Egnyte scenario as unsupported in GCC, GCC High and DoD, and its permissions page says Egnyte group permissions are not migrated.
If your organization is consolidating Egnyte into Microsoft 365, the migration date depends on three items that sit outside the copy itself: whether Microsoft’s route runs in your cloud, how fast Egnyte lets the migration app read, and how access will be rebuilt. Microsoft’s Overview: Migrate Egnyte using Migration Manager describes the goal this way: “Collaborate all in one place by migrating your Egnyte documents, data, and users to OneDrive, SharePoint, and Teams in Microsoft 365.” It lays out six steps: connect, scan and assess, copy to the migrations list, review destination paths, map identities, then migrate and monitor. The checklist below follows that order. Microsoft statements are quoted from Microsoft Learn and Egnyte statements from Egnyte’s developer pages, as published on September 26, 2026, with links.
Step 1: Confirm Microsoft’s Route Runs in Your Tenant’s Cloud
If your tenant runs in a US government cloud, check this before anything else. Microsoft’s Specialty Environments support table marks the Egnyte scenario as not supported in GCC, GCC High, DOD or sovereign clouds, while the file share scenario is supported in GCC, GCC High and DOD. Microsoft’s Government cloud settings for Migration Manager page states: “Migration Manager only supports File Share migration for the Government cloud.”
For a government-cloud tenant, then, Migration Manager’s Egnyte scenario is not a route, and the choice of another route is a tool decision, covered in choosing a SharePoint migration tool. What a GCC High destination adds on the SharePoint side is covered in GCC High SharePoint Migration: A Defense Contractor’s Pre-Migration Guide to Customizations, Compliance, and Partner Selection. For a commercial tenant, continue to step 2.
Step 2: Create the Egnyte App and Get Its Rate Limit Raised Before You Set a Date
If the migration date is already on a calendar, check this step first, because Microsoft expects a new Egnyte app to run into Egnyte’s limits. Microsoft’s Step 1: Connect page says you need an Egnyte developers account to create the Egnyte Connect API application that Migration Manager connects through, and suggests “Publicly Available Application” as its type. The same page then warns: “However, it will likely not let you migrate content to Microsoft 365 due to the limits Egnyte imposes on new applications.” Its instruction is: “Contact Egnyte support to request a rate limit increase for your application.” Microsoft’s overview adds that you sign in to your Egnyte developer account to see the rate limit you have now.
Egnyte’s own pages describe the limit. Egnyte’s developer Best Practices page states: “Rate limits are enforced per access token, not per API key.” Its default table lists standard API calls at 2 calls per second per token, and its note says: “If your production application requires higher limits, contact Egnyte to discuss custom arrangements.” Egnyte’s developer FAQ adds: “Customers’ use of the Egnyte Platform is subject to certain usage caps, limitations, and restrictions, which differ from plan to plan.” Because the daily allowance depends on your plan, plan to the figure your developer account shows, not to a published number.
Treat the rate increase as a lead-time item with a named owner and a date. Create the app, read the current limit in the developer account, file the increase request with Egnyte, and set the migration date only after the new limit is confirmed.
Step 3: Give the Migration Account Only the Rights It Needs
If the account running the migration holds more rights than the copy requires, your security review will ask why. On the source side, Microsoft’s overview asks you to “Have Egnyte account credentials that have Read access to any Egnyte user account you plan to migrate.” On the destination side it lists Global admin, OneDrive/SharePoint admin, or a user granted the Microsoft 365 Migration Administrator role, and it adds: “Microsoft recommends that you use roles with the fewest permissions.” Microsoft’s Migration Admin role page explains that role’s purpose: “With this new role, you limit usage to only what is required to migrate your content, reserving SharePoint Admin access to only users who need it.”
Step 4: Settle Folder Structure Before the First Pass
If your teams plan to reorganize folders as part of the move, do it before the first pass or after the last one. Microsoft’s Frequently Asked Questions: Migration Manager Egnyte page states: “Any major changes in directory structure should happen before or after your migration.” It gives an example of what a rename in the middle does: “Changing the path /Sales/Clients to /Global Sales/Clients results in two copies of your Sales folder after the Global Sales folder is also copied during an incremental pass.” Check path length at the same time: Microsoft’s Unsupported files in Migration Manager page lists “Destination path URL that exceeds 400 characters.” What to classify before the move is covered in Data Classification Before SharePoint Migration: The Classify-First Approach.
Step 5: Map Identities, and Plan for Group Access That Will Not Carry
If identity mapping is left to the tool’s defaults, users can arrive at SharePoint without access to their own files. Microsoft’s Step 5: Map identities page states: “If identities aren’t properly set up before migration, it can result in users losing access to content. It can also result in file metadata being incorrect at the destination.” It also says: “In most cases, automapping is unlikely to map all the identities.” And for the mapping file you upload: “Make sure to verify your mappings before uploading the file. The file isn’t validated.”
Microsoft’s pages give two different statements about Egnyte groups, and your plan has to account for both.
- The overview’s step 5 reads: “Map your domains, groups, and users in Egnyte to domains, groups, and users in Microsoft 365 to migrate metadata and permissions correctly.” The FAQ page says that when identities are fully mapped, “content will be automatically reshared after migration, ensuring that each user retains access to their content exactly as before.”
- Microsoft’s Permission settings in Migration Manager page states: “Currently, group mapping of Egnyte is not supported, so group permissions in Egnyte are not migrated.”
Plan as if group permissions do not migrate. List the Egnyte folders where access comes from a group rather than from named users, name the Microsoft 365 group or SharePoint permission that replaces each one, and apply those permissions in SharePoint after the copy. Then prove the result in a pilot: migrate a sample of folders with group-granted access and check, with the users who hold that access, what they can open at the destination.
The same permission settings page sets the defaults for what does carry: “By default, Migration Manager migrates folders permissions. File permissions aren’t migrated, and destination files inherit parent folder permissions.” If you turn on file permissions, it notes: “Migrating file permissions may slow down your migration process.” It also warns about the destination choice: “When migrating to the document library in a SharePoint site, if you choose the library as the destination, the root folder permissions in the source will not be migrated. To avoid this, please create a folder in the library and assign it as the destination.” Its role table maps the Egnyte Owner role to Owner, Full or Editor to Can edit, and Viewer to Can view.
Mapping carries access as it stands, including access that should have been removed. Lift-and-shift migrations typically carry over existing permission inconsistencies, creating immediate audit exposure in Microsoft 365 environments rather than resolving the underlying governance debt. How to inventory and sequence permissions for a SharePoint move is covered in How to Migrate SharePoint to Microsoft 365 Without Breaking Permissions and Governance.
Step 6: List What Will Not Arrive, and Who Rebuilds It
If the business expects SharePoint to look like Egnyte on the first morning, set that expectation with this list before the cutover. Each row is what Microsoft’s pages say about the Egnyte scenario, and the last column is the decision your team makes.
| Item | What Microsoft’s pages say | Decision to make before cutover |
|---|---|---|
| Version history | FAQ page: “During an Egnyte migration, only the most recent version of a file is transferred.” File Versions page: “Currently, file version migration is supported only for a Google scenario.” | Whether older versions are kept in Egnyte, exported, or let go, decided with records management and counsel |
| External sharing links | FAQ page: “We don’t recreate external sharing links. After migration, the links have to be set in the destination manually.” | Which external links are re-created in SharePoint, and by whom |
| External collaborators | FAQ page: “We don’t share content with external collaborators.” | Which external users are invited again, under your guest access settings |
| Group permissions | Permission settings page: group permissions in Egnyte are not migrated (step 5 above) | Which Microsoft 365 group or SharePoint permission replaces each Egnyte group |
| File-level permissions | Permission settings page: by default, files inherit parent folder permissions | Whether to turn on file permissions, and accept the slower run |
| Shortcut files | Unsupported files page: “Shortcut files are skipped in Google, Dropbox, Box, and Egnyte migrations, but migrated as-is in file share migrations.” | Whether shortcuts are replaced with links in SharePoint |
| Very large files | File size limitations page: 250 GB maximum for Egnyte to Microsoft 365 | Where files above that size go |
| Content the migration account cannot read | FAQ page: “Any items the user doesn’t have permission to access are excluded from the migration.” | Whether the source account’s Read access covers the folders in scope |
Retention and sensitivity labels for migrated content are set in SharePoint after the copy, as part of the destination design.
Step 7: Lock Destinations Before Migration Starts
If destinations are still under discussion when the first task runs, the discussion ends there. Microsoft’s Step 4: Review destination paths page states: “Once you start migrating content to a destination, the destination can’t be modified.” For OneDrive destinations it says: “If you choose OneDrive as the destination, pre-provision OneDrive for users in your organization before migration.” Size the task list to Microsoft’s limits: the Step 2: Scan and assess page states “The total number of rows (tasks) in the scan list cannot exceed 50,000.”, and the Step 6: Migrate and monitor page states “At a maximum, only 50 task rows can run simultaneously.” and “Depending on how large your migration, this step can take hours or days.”
Step 8: Run Delta Passes Without Renaming Anything
If users keep working in Egnyte while the copy runs, the later passes pick up their changes. The FAQ page states: “After you complete a migration task for the first time, triggering the Migrate button again will initiate a delta sync (incremental migration run).” Between passes, leave the migrated files alone. The Step 6 page states: “We strongly recommend you don’t rename or move migrated files before the final migration has been completed. Doing so results in files being overwritten.” The Egnyte source stays in place until your organization retires it; the FAQ page states: “We never delete your data from any source.” The cutover itself is covered in SharePoint Migration Cutover Checklist: 4 TB from SharePoint 2016 to SharePoint Online.
How i3solutions Runs the SharePoint Side
When your team brings an Egnyte consolidation to i3solutions, the work starts from the three lead-time items above: the cloud route, the API limit and the group access to rebuild. i3solutions plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based engineers. i3solutions pre-migration SharePoint assessment engagements run four to six weeks.
Key Takeaways
- If your tenant is in GCC, GCC High, DoD or a sovereign cloud, Microsoft lists Migration Manager’s Egnyte scenario as not supported there, and the route becomes a tool decision.
- Microsoft says a new Egnyte app will likely hit Egnyte’s limits; request the rate increase from Egnyte and set the date after it is confirmed.
- Microsoft’s pages differ on Egnyte groups; plan as if group permissions do not migrate, and prove the rebuilt access in a pilot.
- Version history, external sharing links, external collaborators and shortcut files do not arrive; decide who rebuilds each before cutover.
- Lock folder structure and destinations before the first pass, and rename nothing until the final pass is done.
Frequently Asked Questions
Can Migration Manager move Egnyte into GCC High?
If your tenant is in GCC High, no: Microsoft’s Specialty Environments support table marks the Egnyte scenario as not supported in GCC, GCC High, DOD or sovereign clouds, and its government cloud settings page says Migration Manager supports only file share migration for the government cloud. Choosing another route is a tool decision for your team.
Does Egnyte version history move?
If you rely on older versions, plan for them separately. Microsoft’s Egnyte FAQ says only the most recent version of a file is transferred, and its File Versions page says version migration is supported only for a Google scenario. Decide with records management and counsel whether older versions stay in Egnyte, are exported, or are let go.
Do Egnyte shared links still work after the move?
If users share files with people outside your organization, those links have to be set up again. Microsoft’s Egnyte FAQ says Migration Manager does not recreate external sharing links, that the links have to be set in the destination manually, and that it does not share content with external collaborators.
Why does the migration app need a rate increase?
If you connect with a new Egnyte app at its default limits, Microsoft says it will likely not let you migrate content because of the limits Egnyte imposes on new applications. Egnyte’s developer Best Practices page lists a default of 2 calls per second per token for standard API calls and asks you to contact Egnyte for higher limits, so request the increase before you set a migration date.
Do Egnyte group permissions migrate?
If access in Egnyte comes from groups, plan to rebuild it. Microsoft’s Egnyte overview and FAQ describe mapping groups and resharing content, while its permission settings page says group mapping of Egnyte is not supported, so group permissions are not migrated. Plan to that statement, apply group access in SharePoint after the copy, and prove it in a pilot.
Bring Your Egnyte Inventory to the First Conversation
If the Egnyte consolidation is waiting on your approval, bring the cloud your tenant runs in, your current Egnyte API limit, and a list of the folders where access comes from groups. The conversation turns those into a migration plan with the lead-time items named. Talk to a senior architect
Sources
- Microsoft Learn, Overview: Migrate Egnyte using Migration Manager, last updated April 8, 2025; Step 1: Connect, April 8, 2025; Step 2: Scan and assess, April 8, 2025; Step 4: Review destination paths, August 27, 2026; Step 5: Map identities, April 8, 2025; Step 6: Migrate and monitor, April 8, 2025; Frequently Asked Questions: Migration Manager Egnyte, July 16, 2025; all read September 26, 2026.
- Microsoft Learn, Specialty Environments support, April 1, 2025; Government cloud settings for Migration Manager, July 14, 2025; Permission settings in Migration Manager, March 20, 2025; Unsupported files in Migration Manager, June 17, 2026; File size limitations for migration to Microsoft 365, June 29, 2026; File Versions, April 1, 2025; Migration Admin role, January 16, 2025; all read September 26, 2026.
- Egnyte, Best Practices, Egnyte Developer Portal and FAQ, Egnyte for Developers, both read September 26, 2026. Microsoft and Egnyte update these pages from time to time; check the current text before relying on it.