Skip to content
← Migration paths

REFERENCE · UPDATED October 24, 2026

What carries over in each migration

Before you move anything, you should know what arrives on the other side. This page lists, for each migration path, what MigrationFox copies today: file contents, folders, dates, authors, version history, sharing, metadata, and whether a second run copies only what changed.

It is written from the migration code, not from a wish list. Where something is only partly carried over, the note under the table says exactly what is missing. Where we have checked a cell in a live test, it carries a Live-tested marker; everything else is what the code does, and we haven’t yet run every cell end to end against real tenants.

The matrix

Destination is SharePoint or OneDrive unless the row says otherwise. Rows describe migrations run in the MigrationFox cloud. Scroll sideways on a phone to see every column.

A Yes or Partial without the Live-tested marker is verified from the migration code, not yet from an end-to-end run against real tenants.

What carries over, by migration path. Yes means carried over, Partial means carried over with the limits in the numbered note, No means not carried over.
Migration path File content Folder structure Created and modified dates Authors (Created by, Modified by) Version history Sharing and permissions Metadata and columns Incremental re-runs
SharePoint / OneDrive → SharePoint / OneDrive (standard) Yes Yes 2 Partial 1 No 3 Partial 4
Live-tested		 Partial 5 Partial 6 Yes 7
Live-tested
SharePoint / OneDrive → SharePoint / OneDrive with True History Yes 8 Yes Yes 9 Yes 10 Yes 11 Partial 12 Partial 6 No 13
Google Drive → SharePoint / OneDrive Yes 14 Yes Partial 1 No No Partial 15 No Yes 7
Box → SharePoint / OneDrive Yes 16 Yes Partial 1 No Partial 4 Partial 17 No Yes 7
Dropbox → SharePoint / OneDrive Yes Yes Partial 18 No No No No Yes 7
File share or local folder → SharePoint / OneDrive (Windows app) Yes Partial 19 Partial 20 No No No 21 No No 22
Amazon S3, Azure Blob or SFTP → SharePoint / OneDrive Yes Yes Partial 23 No No No No Yes 7
Slack → Microsoft Teams Partial 24 Partial 25 Yes 26 Partial 27 Not applicable Partial 28 No 29 No 30
Microsoft Teams → Microsoft Teams 31 Partial 32 Partial 33 Yes 26 Yes 34 Not applicable Partial 35 No 29 No 30
Gmail / Microsoft 365 mail (private beta) 36 Partial 37 Partial 38 Partial 39 Partial 40 Not applicable No 41 Partial 42 No 43
InfoPath archive (forms → searchable PDFs) Yes 44 Partial 45 Partial 46 Partial 47 No 48 No 49 Partial 50 No 51

Running from the Windows app

The table describes cloud runs. Most paths behave the same when the Windows app runs them, because the app uses the same migration engine. Two differences today: a plain copy from Google Drive run on the Windows app skips native Google Docs, Sheets and Slides instead of converting them, and a plain copy from Box run on the Windows app doesn’t convert Box Notes. For those two sources, run the migration in the cloud.

Notes

  1. The file’s Modified date is kept, on files and on folders. The Created date shows the time of the migration.
  2. Empty folders are created too.
  3. Created by and Modified by show the account that ran the migration. To keep the original people, use True History.
  4. Optional (“Copy version history”). Earlier versions are uploaded oldest first, one destination version per upload, so the version count matches. Outside True History, each version shows the migration time and account, not the original ones. You can cap how many versions are copied per file. Live-tested (internal test, 2026-10-24) for SharePoint and OneDrive: one destination version per upload.
  5. Optional. Sharing on each file is recreated for the matching people in the destination (using your user mapping across tenants). Access a file inherits from its folder or site becomes sharing on the file itself. Sharing set on folders isn’t copied, and SharePoint groups without an email address are skipped.
  6. When you copy a whole site or library, the destination library is created with its custom columns. The values in those columns on each file aren’t copied yet.
  7. “Only new or changed files” checks each file’s Modified date in SharePoint or OneDrive and skips files that are already up to date. “Sync changes” mode instead copies only files changed at the source since the last completed migration from the same location. Live-tested (internal test, 2026-10-24) in the cloud and on the Windows app: 19 files, 1 edited, the re-run copied 1 and skipped 18.
  8. Files up to 45 GB each. True History needs a destination connected with “Sign in with Microsoft”.
  9. Files and their versions keep their original created and modified dates. Folders keep their original authors; a folder’s Modified date can show the migration time.
  10. Works in one tenant and across tenants. Across tenants, people are matched using your user mapping.
  11. Earlier versions keep their original authors and dates. By default the 50 most recent versions per file are kept; you can set 1 to 500.
  12. Site groups and their members are copied. Unique permissions on individual files and folders aren’t.
  13. True History writes into an empty destination, so it doesn’t do incremental re-runs. Use a standard migration for top-up passes.
  14. Google Docs, Sheets and Slides become Word, Excel and PowerPoint files. Google Drawings become PNG images. Google Forms, Sites, Apps Script, Jamboard and My Maps files can’t be exported; they are listed as skipped.
  15. Optional. User sharing becomes sharing for the matching people, “anyone with the link” becomes an anyone link, and domain sharing becomes an organization link. Applied to files; sharing set on folders isn’t copied.
  16. Box Notes are converted to Word documents (on by default).
  17. Optional. Box folder collaborations are recreated for the matching people. Collaborations on individual files and Box group collaborations aren’t copied.
  18. The Modified date is the one Dropbox records on its servers. The Created date shows the time of the migration. Folders get the migration time.
  19. Folders that contain files are created. Empty folders aren’t.
  20. Files keep their Created and Modified dates from the file share. Folders show the migration time.
  21. NTFS and file share permissions aren’t migrated. Set access in SharePoint after the migration.
  22. A re-run can skip files that already exist by name, and a resumed run skips files it already finished. Checking whether a file changed (“Only new or changed files”) isn’t available for file share sources yet.
  23. The Modified date comes from the source’s last-modified time. For S3 and Azure Blob that is when the object was last written. The Created date shows the time of the migration.
  24. Messages are copied as plain text: Slack formatting, @mentions and emoji codes aren’t converted. Bot and other system messages are skipped. Files shared in Slack aren’t copied.
  25. Public channels become standard channels, private channels become private channels, and threads become replies. Archived channels, direct messages and group DMs aren’t copied.
  26. Messages keep their original timestamps (Microsoft’s Teams import mode). Edits aren’t shown as edited.
  27. Each message shows the Slack author’s name, but it is posted without being linked to that person’s Microsoft 365 account.
  28. Slack workspace members who match an account in the destination (by email or your user mapping) are added to the team, and Slack admins and owners become team owners.
  29. Reactions, pins, bookmarks, tabs and apps aren’t copied.
  30. Each run creates a new team. To redo a migration, run it again into a new team.
  31. Reading messages from a source team with the MigrationFox Teams app needs Microsoft’s approval for its protected Teams APIs, which is pending. Until then, connect the source tenant with your own Azure app. One-to-one and group chats aren’t supported.
  32. Message text and formatting are copied. File and tab cards in messages aren’t, and inline images may not display. Files in the team’s main document library are copied by a companion file migration; private channel files aren’t.
  33. Channels and threads are recreated, reusing General. Shared channels become standard channels. Private channels are created as private, without their membership. Tabs, apps and Planner aren’t copied.
  34. When the author can be matched in the destination (by email or your user mapping), the message is posted as that person. Otherwise it shows their name and email in the message.
  35. Team members and owners are added for the matching people. Private channel membership isn’t copied.
  36. Mail migration is in private beta, between Gmail and Microsoft 365 mailboxes. Exchange (EWS) and IMAP aren’t offered. We are still verifying this path end to end, so check a pilot mailbox before you plan around it.
  37. Messages are copied with their subject, sender and recipients. Message bodies are still being verified end to end in the beta, and attachments are off by default.
  38. Top-level folders and labels are copied. Gmail system labels map to the matching Outlook folders. Nested folders are flattened.
  39. Into Gmail, the original date is kept. Into Microsoft 365, how the received date shows is still being verified in the beta.
  40. Sender and To and Cc recipients are kept. Bcc and Reply-To aren’t.
  41. Mailbox permissions and delegates aren’t copied.
  42. Into Microsoft 365, read state and importance are kept (and stars become flags from Gmail). Into Gmail, read state and stars aren’t.
  43. A re-run copies messages again. Use a date range to copy only a later window.
  44. Each form submission becomes a searchable PDF (real text, not a scan), laid out from the form template. Attachments embedded in the form are restored as the original files, and a CSV index (opens in Excel) lists every form. Sources: a SharePoint Online form library (runs in the cloud) or a folder through the Windows app.
  45. The archive uses its own layout: one folder per form with its PDF and attachments, and the CSV index at the top. The source folder layout isn’t mirrored.
  46. The submission date is written into the PDF and the CSV index. The archive files themselves show the time they were created.
  47. The CSV index has a Submitted by column when the form records who submitted it. The SharePoint Created by and Modified by of the source item aren’t used.
  48. Only the current version of each form is archived.
  49. The archive gets the permissions of the destination library you choose.
  50. SharePoint list columns fill in blank people and lookup fields, and the PDF properties include the title and source location.
  51. A re-run archives every form again.

How we verify a migration

  • Per-file results. Every file and folder in a migration has its own row with its status (completed, skipped or failed), the error message when there is one, the number of attempts and timestamps. You can export the whole list to CSV from the migration’s page.
  • Size check after upload. When the MigrationFox engine uploads to SharePoint or OneDrive, it reads back the size of the uploaded file and marks the file failed if it came up short, so a truncated upload doesn’t pass silently.
  • Source vs destination comparison. For SharePoint site and library migrations, the migration page compares item counts in each library and list on both sides once the migration finishes, and exports the comparison to CSV.
  • Automatic retries. Each file is retried up to five times on temporary errors such as throttling or dropped connections. If a whole migration fails, or a finished migration has files that failed, on errors that look temporary, it is retried automatically later, up to three times. Only the failed files are tried again, and files that already copied are not charged again.

We don’t publish speed or throughput numbers. Your speed depends mostly on the source and destination platforms’ own limits, so run a small pilot to measure it in your tenant.

Related reading

Try it on your own content

2 GB free. No credit card required. Check the per-file results before you plan the full move.

Start free → Download for Windows