What really survives a migration into Microsoft 365
Most migration questions are really the same question asked in different ways: when this file arrives in SharePoint or OneDrive, will it still be the same file? For the content itself, the answer is yes. For two things people often assume will come along automatically, permissions and version history, the answer is more nuanced. Neither should come as a surprise if you understand where the boundary lies before the migration starts.
What moves with every file
Every file's content is transferred exactly as it exists at the time of migration. The folder structure is preserved, and wherever the source and destination platforms allow it, the original created and modified dates are retained rather than being replaced with the migration date.
Each transferred file is verified using both its size and a cryptographic hash before it is considered complete. Every outcome is then recorded individually. Whether a file was copied, skipped, repaired or failed is captured in the audit trail, giving you a complete record of what happened rather than a simple summary count.
For the vast majority of files, that is the complete story. Two areas deserve a little more explanation.
Permissions do not automatically come across
Access permissions are not recreated automatically in Microsoft 365, and that is a deliberate design decision.
Every source platform represents permissions differently. Some expose detailed permission information through their APIs, others expose only part of the picture, and almost none map cleanly onto Microsoft's security model. Even where the information is available, automatically recreating access would require the migration tool to make assumptions about users, groups and sharing arrangements that it cannot safely make.
Those assumptions are exactly the kind of decisions that belong with the organisation carrying out the migration, not with the software.
Instead of applying permissions automatically, Liscaragh Migrate produces a read-only permissions plan showing how the source permissions relate to the intended Microsoft 365 destination. You review that plan and decide how access should be configured before users begin working with the migrated data.
In practice, this is often an opportunity to improve permissions rather than simply reproduce years of accumulated access that no longer reflects how people work.
Know what you're getting before you commit
The full per-file audit trail and the read-only permissions plan are both built into every migration. Nothing about what does or doesn't survive is a surprise on the day. See what the audit trail actually records.
Version history usually stays behind
Version history also deserves careful explanation.
Some platforms expose historical versions through their APIs, while others do not. Even where they do, every platform represents those versions differently. There is no universal version format that can simply be transferred into SharePoint.
For that reason, migrating from Datto Workplace, a traditional file share, or any other source whose API exposes current content only, transfers the current version of each file rather than attempting to recreate every historical revision.
SharePoint-to-SharePoint migrations are different. Because both systems use the same underlying version model, some migration tools can preserve version history between SharePoint environments. That is a fundamentally different problem to migrating into Microsoft 365 from a platform that was never designed around SharePoint's versioning model.
The file that arrives is the file as it exists today. The edit history that led to that version normally remains on the original platform.
Why this is a boundary, not a limitation
Liscaragh Migrate is designed around a simple principle: it moves data without making business decisions on your behalf.
It never modifies the source platform, and it does not silently change permissions in the destination. Those decisions remain under your control.
The same philosophy applies elsewhere. Provenance columns, such as the original source path, source owner and migration date, can be written directly into SharePoint if you choose to enable them. They are disabled by default because writing those values creates one additional version of every file in a version-enabled library. That is a perfectly acceptable trade-off for many organisations, but it should always be a conscious choice rather than an unexpected side effect.
Planning around the differences
Neither permissions nor version history should become a surprise during cutover. Before the migration begins:
- Review the permissions plan and use it as an opportunity to simplify or modernise access rather than automatically reproducing years of inherited permissions.
- Plan for version history if it matters for a particular set of documents, by keeping the original platform available in read-only mode for an agreed period after migration, so historical revisions remain accessible if required.
- Set expectations with users before migration day. Explaining these boundaries in advance is far easier than answering questions after someone starts looking for an old version or a permission that no longer exists.
Everything else, the content itself, the folder structure, supported timestamps and a fully verified audit trail of every file transferred, arrives exactly as expected.
A good migration is not one that promises everything. It is one that tells you exactly what will arrive, exactly what will not, and gives you the information to plan accordingly before the first file is moved.