What "done" actually means for a migration
The progress bar reaches 100%, the window closes, and someone says, "That's that, then." It's a satisfying moment. But a completed copy isn't the same thing as a completed migration, even though the two are often treated as if they are.
What a completed copy actually tells you
A completed transfer tells you that files were sent to the destination. On its own, that's all it confirms.
It doesn't prove every file arrived intact. It doesn't prove nothing changed at the source while the migration was running. It doesn't prove users have the access they expect once they start working in the new location.
"The copy finished without errors" and "the migration is complete" are two very different statements.
Most of the time, everything is fine. The problem is that "most of the time" isn't the same as verified, and the difference usually only becomes visible when someone can't find an important document weeks or months later.
The step that's often skipped
A migration isn't really finished until the destination has been checked against the source.
That means confirming every expected file exists, is current, and is where it should be. It's a different step from copying data, and it's usually slower, which is exactly why it's the part people are tempted to skip once the progress bar reaches the end.
Without that verification, you're relying on the assumption that because the transfer completed successfully, everything must have arrived successfully.
Those aren't the same thing.
The gap between "migrated" and "cut over"
On anything more than a small migration, there's usually a period between the initial copy and the day everyone starts using the new system.
During that time, people keep working.
New files are created. Existing files are edited. Others are deleted.
Unless those changes are identified and synchronised before cutover, the destination is already out of date before anyone starts using it.
A migration that completed last Tuesday isn't necessarily a migration that's current today.
Proof instead of assumption
If someone asks six months later whether a particular document was migrated, "we think so" isn't much of an answer.
A migration that's genuinely complete should be able to answer that question with evidence rather than memory.
That evidence should show what happened to every individual file, not just that a transfer job reported success.
Built around proving a migration, not just running one
Liscaragh Migrate records the outcome of every file as an individual audit entry, showing whether it was copied, skipped, repaired or failed.
Its Verify Files Arrived feature checks the destination directly against the source instead of relying solely on the transfer log.
Its Check for Drift feature compares today's destination with the original migration audit, identifying anything that has been added, changed or deleted since the initial copy, right up to cutover.
Once a migration has been copied, synchronised and verified, a one page completion certificate can be generated as evidence that the migration was completed successfully.
A simple checklist before sign-off
Before declaring a migration complete, it's worth confirming four things.
- Every file has been verified at the destination, not simply copied.
- Nothing changed at the source between the final synchronisation and cutover.
- Users can access the new location with the correct permissions.
- There's an audit trail that proves what happened if anyone asks later.
None of those checks takes very long compared with the migration itself.
Skipping them simply postpones the cost until someone discovers a problem afterwards.
The question worth asking
Before anyone signs off a migration, ask one simple question.
What proves it's finished?
If the answer is simply "the progress bar reached 100%", the migration probably isn't finished yet.