Rescue · Missing files
Files that did not arrive in SharePoint were usually skipped, not lost.
SharePoint rejects paths, characters and sizes that Windows, Dropbox and Google Drive accept. Every rejection is silent unless someone counts.
We count the source against the destination, identify every skipped item and the reason it was skipped, remediate the cause and complete the transfer.
- Source preserved
- Retrievability confirmed first
- Written findings
- Nothing re-run blind
Price cue, ex GST
Assessment from $750
Find out what is retrievable Or call 1300 652 280If a licence or subscription is about to lapse, the recovery window is closing. Call 1300 652 280 and say so — we will triage it ahead of the queue.
- Australian managed
- Delivered remotely
- Source data never deleted
- Verification report at sign-off
Why files do not arrive
Total path length exceeded the SharePoint limit and the item was skipped
Illegal characters in a file or folder name caused a silent rejection
The file exceeded the destination size limit
The file was open and locked when the transfer ran
The file type is blocked by tenant policy
The file was owned by a deleted account and had no valid destination owner
How the gap gets closed
Every step produces a number. That is the point — the reason this problem persists is that nobody has counted.
The full 17-gate method- 01Count the source: files and folders, by share and by library
- 02Count the destination the same way, so the two numbers are comparable
- 03Extract the skip and failure list from the migration tool logs
- 04Classify every missing item by cause: path, characters, size, lock, policy, ownership
- 05Remediate the cause at the source rather than working around it at the destination
- 06Transfer the remaining items and re-count
- 07Reconcile version history and permissions, which are commonly lost alongside the files
The proof you keep
Every missing file is accounted for by cause.
A list of missing files is not a finding. A list of missing files with the reason each one was skipped is a work plan. Example format below.
File Reconciliation Report
SharePoint gap closure · Example format
| Cause | Skipped | Recovered | Status |
|---|---|---|---|
| Files in source | 1,884,220 | 1,884,220 | Verified |
| Path too long | 4,882 | 4,882 | Remediated |
| Illegal characters in name | 1,206 | 1,206 | Remediated |
| Exceeded size limit | 148 | 148 | Transferred separately |
| Locked at transfer time | 2,204 | 2,204 | Remediated |
| Blocked file type | 316 | 0 | 316 Accepted Exception |
Blocked file types remain blocked by your own tenant policy. They are listed individually so you can decide whether to change the policy or store them elsewhere.
Free · About three minutes · No sales call required
Four steps. An engineer reads every one.
A broken migration never receives an automated price. The Fit Check captures the environment and the symptoms so the engineer who calls you back already understands the situation.
Questions about missing files
Why does SharePoint reject files that worked fine before?
It applies limits the old system did not. Total path length is capped, certain characters are not permitted in names, some file types are blocked by policy, and very large files fail. A Windows file server happily holds all of these, which is why a straight copy produces silent skips rather than errors.
Our provider says the migration completed. Files are missing. Who is right?
Both, and this is the most common conversation on this route. The tool completed. It reported what it attempted. It did not compare the result against the source, because comparing is a separate act. Counting is the only way to settle it, and the count is usually the first honest number anyone in the project has seen.
Can the skipped files still be transferred?
Yes, once the cause is remediated. Long paths get restructured, illegal characters get corrected, oversized files get handled separately. The remediation is mechanical. Finding what needs it is the part that requires the reconciliation.
Is the old server safe to turn off now?
Not until the reconciliation is complete and you have signed acceptance. Turning off a file server on the strength of a tool reporting success is how skipped files become lost files. Source data is not deleted as part of a standard project, and decommissioning is your separate decision.
What about the version history and permissions?
Both are checked as part of the same reconciliation, because both are commonly lost alongside the files themselves. Version history retention is a scoping decision. Permission mapping is a design decision. Neither survives being left to a default.