Why "just copy the files across" undersells a migration
"Can't we just copy the files across?" It's one of the most common questions asked before a migration starts, and it's an entirely reasonable one. After all, copying files is something everyone has done.
The problem is that a migration isn't simply about moving files. It's about making sure people can carry on working afterwards without discovering that something important was left behind.
Copying files is only part of the job
Moving a file from one location to another preserves its contents. A migration has a much bigger responsibility.
People still need to find the documents they're looking for. Teams still need the right access. Links between documents still need to work. Information that's important for compliance or auditing may need to be retained. Existing ways of working shouldn't quietly fall apart because the storage platform changed.
None of that is covered by "just copy the files across". Yet it's exactly what users expect to still be true on Monday morning.
Permissions are a business decision
Who can access a file is rarely as simple as a list of names.
Most organisations build permissions over many years through security groups, inherited folder permissions, shared folders and one-off exceptions. It usually works because everyone has gradually adapted to it, not because anyone documented it.
Microsoft 365 handles permissions differently from a traditional file share. No migration tool can safely guess how those permissions should be recreated without risking either removing access people need or granting access they shouldn't have.
Treating permissions as a deliberate design decision rather than an automatic copy isn't a limitation. It's an opportunity to simplify years of accumulated complexity instead of faithfully recreating it.
Links often fail long after the migration
Files don't exist in isolation.
Excel workbooks reference other files. Word documents contain hyperlinks. PDFs are shared from network folders. Browser favourites point at shared drives. Internal documentation links to locations that have existed for years.
Every one of those references depends on a specific location.
When files move into Microsoft 365, those locations change. The migration may complete successfully, but the first sign of a problem could be weeks or months later when someone opens a document they haven't touched since before the move.
By then, nobody immediately connects the issue back to the migration.
Folder structures represent years of decisions
Most folder structures aren't random, even if they look untidy.
They reflect departments, projects, customers and the habits of the people who created them. Some parts deserve to stay exactly as they are. Others have become unnecessarily complicated over time.
Simply recreating everything preserves the good and the bad. Starting again from scratch risks losing structures that people genuinely rely on.
Neither approach is automatically right. It's a business decision that deserves to be made deliberately before the migration begins.
Metadata matters more than people realise
Most people rarely think about information such as created dates, modified dates or where a file originally came from.
Until they need it.
An audit, legal discovery exercise, compliance review or customer dispute can suddenly make that information extremely valuable. If it wasn't preserved during the migration, there's usually no way to recreate it afterwards.
Whether metadata survives depends on the migration tool, the source platform and the destination platform, not simply on the fact that the files were moved.
Designed for migrations, not file copying
Liscaragh Migrate is designed around the difference between copying files and completing a migration.
It preserves what can safely be migrated automatically, including file content, supported timestamps and folder structure, while verifying every transferred file individually. It also records a complete audit trail so every migrated file can be accounted for afterwards.
Where business judgement is required, such as permissions or information architecture, the software deliberately leaves those decisions to the people responsible rather than trying to guess.
Set expectations before migration weekend
Many migration problems begin long before any data moves. They begin when everyone assumes the project is simply a weekend copy job.
The valuable conversations happen before the migration starts.
Who should have access afterwards?
Should the existing folder structure be preserved or improved?
Which links, shortcuts and integrations are critical to the business?
Answering those questions early keeps the migration predictable. Discovering them during cutover usually means delays, unexpected work and unhappy users.
The question worth asking
Before agreeing that a migration is "just copying files", ask what happens to permissions, document links, metadata and the structure people rely on every day.
If those questions haven't been answered yet, copying the files is the easiest part of the project.