Liscaragh Migrate › Help › What happens when files fail, and how to fix it

What happens when files fail, and how to fix it

On a large migration, a small number of files failing is normal, not alarming. What matters is knowing what actually happened, and that fixing it never means rerunning the whole job. This page covers the common causes, how to read the outcome, and the tools built specifically to recover.

How to tell a run had a problem

After a run finishes, a coloured banner summarises the outcome and the Status column updates per project or source, Migrated or Errors, so you know at a glance whether anything needs attention. The report's Run insights section lists every file that hit a retry, and the full per-file listing records the actual outcome, copied, skipped, failed or repaired, for every file in the run. If a report and a quick glance ever disagree, the per-file audit record is the one that is correct; see understanding your audit trail and reports for how that record is structured.

What actually causes a file to fail

In practice, failures trace back to a handful of real causes rather than anything mysterious:

• The file is locked at the source. Someone has it open and is actively editing it. A Datto source review, run before you migrate, flags exactly which files are currently locked and by whom, so you can plan around it rather than discover it mid-run.
• A destination path or name problem. SharePoint rejects certain characters and has a maximum path length. Most of this is handled automatically: name sanitising, on by default, replaces characters SharePoint rejects and trims trailing dots or spaces, logging every rename it makes. What cannot be safely auto-fixed, mainly a path that would be too long, is instead flagged by Check readiness as something that needs a decision from you before the run, rather than silently truncated, because truncating risks two different files colliding under the same shortened name.
• The Microsoft 365 or source API asks the run to slow down. This is not a failure. Microsoft 365 and Datto Workplace will occasionally signal that a service is busy; Liscaragh Migrate detects this automatically, eases off, and gradually speeds back up once the pressure clears. You will see this in the log as rate-limit pauses and retries, not as an error.
• The run was interrupted outright. A reboot, a dropped network connection, or the app simply being closed mid-run.

Fixing a run that reported some failures

After a run that finishes with some files reporting a problem, a Rerun failed files only button becomes available, taken from that run's own record. It re-copies just the files that failed and leaves everything that already succeeded completely untouched: the same file-by-file decisions, verification and retries apply, just to a smaller set. This is not a special kind of run, it is a normal sync narrowed to a specific file list, so it behaves exactly as predictably as any other sync. The button is offered again whenever you reopen a job whose last run left failures, not just in the session where it happened, and if the underlying record cannot be read or names no failed files, it says so plainly rather than quietly falling back to a full sync.

Recovering from an interruption

A deliberate Pause and Resume continues in the same mode it was paused in and does not repeat work already done. Both Pause and Stop always finish by writing a report from the audit record, so an interrupted run still leaves you with a full account of what happened up to that point.

If the interruption was not deliberate, a Windows reboot, a lost connection, or the app closing unexpectedly, there is nothing special to do: reopen the job and run Sync new and changed. Because Sync compares the source against the live destination rather than relying on a stored record of what the previous run thought it had done, it always knows exactly what is still genuinely missing, however the previous run actually ended.

Catching problems before they happen

The tools that reduce failures are the ones you run before Upload, not after:

• Check readiness walks every mapped project or source checking names, path lengths and destination quota, and separates what it can tidy automatically from what genuinely needs a decision from you first.
• Source review (Datto Workplace) flags files shared by a public link, files currently locked by a user, and files not yet fully in the cloud, so none of them arrive as a mid-run surprise.
• Preview is a full dry run: nothing is copied, but you get the same size and blocker picture the real run would hit.

Still not sure what happened

Help > Email support builds a zip of the job's logs and reports, with credentials scrubbed automatically, ready to attach to an email to support@liscaragh.com. A sentence on what you expected and what happened instead is all we need to start looking.