Why a Successful Migration Proves Nothing
A program can report on what it did. It cannot report on what you wanted, because it was never told.
A successful migration proves nothing because file failures rarely report themselves. Almost every way a file can go wrong produces no error. Dates shift. Attachments detach. Characters mangle and structure flattens. In every case the software reports success, because from where it stands nothing failed. A completed run is a statement about the tool rather than about the result.
This is the pattern behind most of what this site documents. It is worth stating on its own.
The Migration Failures That Do Not Announce Themselves
Collecting them in one place makes the shape obvious.
| What went wrong | What was reported |
|---|---|
| Every date moved an hour | Success, with a matching count |
| Every accented name became symbols | Success. All the text was there |
| Attachments stopped matching their boundaries | Success. The messages arrived |
| A redaction removed nothing | Saved, with the page looking correct |
| An image lost detail on every save | Saved, still looking fine |
| A deletion removed nothing from the file | Deleted, with a shorter list to show for it |
None of these is a bug. In every row the software did exactly what it was asked and reported honestly on what it did. The gap is between what was done and what was wanted. No program sees that gap, because it only holds one of the two.
Why the Item Count Is the Weakest Check
It is also the first thing everybody reaches for. The reason is understandable.
A count is the only number both sides can produce. It is objective, it is quick and it either matches or it does not. What it measures is whether objects moved. Objects moving is the part that rarely fails.
What a count tests
Did things arrivesource 4,812 items
result 4,812 items
matched
nothing was
droppedA real check. It catches the failure that almost never happens.
What it cannot test
Did they arrive intact4,812 items
every date wrong
every attachment
unreadable
every accent
mangled
still 4,812Not one of the failures on this page disturbs that number.
Migration Failures Live at the Edges
Picking items at random from the bulk of a collection is close to worthless. Here is why.
The things that break are limits, old conventions and unusual content. None of those is distributed evenly. They cluster at the extremes, so checking the middle tests the case that was never going to fail.
-
The largest itemSize limits are silentCeilings exist in most systems and are rarely announced. They hit the biggest thing first and skip it without comment -
The oldest itemOld conventions live hereWritten by software nobody supports, so this is where odd encodings, missing offsets and abandoned formats turn up -
One with several attachmentsStructure is what breaksNot the message. Open the attachments rather than counting them, since a filename in a list proves nothing -
A pair spanning a clock changeThe offset testBoth correct means offsets are being carried. One wrong means every item in that half is out by an hour
Add the folder count separately. Not the item count, the folder count. Flattening a structure keeps every message and loses the arrangement somebody spent years building. The item total stays perfect throughout.
Check Before the Original Goes
Timing matters more than thoroughness here.
Every finding is a correction while the original is still there and a problem once it has gone. The trouble is that everybody wants to delete the source the moment a run reports success, which is exactly when nobody has verified anything.
Keep the source until somebody has opened the result. Not until the run finished. Not until the count matched. Until a person has looked at four things and found them correct. Storage is cheaper than the alternative by a wide margin.
What Can Be Automated And What Cannot
Some of this is a machine's job and some of it is not. The line is clearer than it looks.
| The question | Who answers it |
|---|---|
| Are these bytes identical | A hash, perfectly |
| Did everything arrive | A count, this alone |
| Do the folder totals agree | A script |
| Does this date look right | A person |
| Does this text read correctly | A person |
| Is this the document we meant | A person. Nothing else can |
The top three are cheap and worth automating. The bottom three catch the real failures. None has an automatic version, because each requires knowing what the answer should be.
Hashing is exact and narrow. It proves two files are identical, which is the right check when nothing was supposed to change. The moment a conversion is involved the bytes legitimately differ and the hash goes quiet, which is precisely when you need an opinion rather than a comparison.
Reading a Migration Report Properly
- Note what it counted. Items, usually. Ask whether the thing that could have failed is a thing it counted.
- Look for what it did not mention. A run that skipped six oversized files and said nothing is the commonest version of this. The summary reads identically either way.
- Treat zero errors as zero detected errors. Those are different statements and only one of them is being made.
- Open four things. Largest, oldest, one with attachments, one from across a clock change.
- Compare folder counts. Structure disappears silently and the item total covers for it.
Why This Is Nobody's Fault
It would be easy to read all of this as software being careless. It is not that.
A program can report on what it did. It cannot report on what you wanted, because it was never told. The gap between those two is where every one of these failures lives. Asking a tool to notice that a date is wrong means asking it to know what the date should have been.
That gap is the reason the four checks exist. They are not compensating for bad software. They supply the one thing no tool has, which is somebody who knows what the answer ought to be looking at whether it is.
The failure modes listed here are the ones documented across this site, each with its own article and sources. This page collects rather than establishes them.
Questions People Ask
7 questions, answered in full below.Why does a migration report success when things are wrong?
Because it is reporting what it did rather than what arrived. Moving every object and mangling every date is a completed run by any measure the tool can apply. Nothing failed from where it was standing.
Is a matching item count good enough?
It is the weakest check available. Counting confirms that objects moved and says nothing about their contents. Everything that actually goes wrong leaves the total intact, which is exactly why it feels reassuring.
What should I check instead?
The extremes. The largest item, the oldest, one carrying several attachments and a pair from either side of a clock change. Four items and a few minutes. Together they catch nearly everything.
Why the largest and oldest?
Because limits and old conventions are where things break. Size ceilings hit the biggest items first and usually without a message. The oldest files came from programs nobody maintains, so they carry the odd encodings and the missing offsets.
Can I automate the checking?
Partly. Comparing hashes proves bytes are identical, which is useful when nothing was meant to change. Bring a conversion into it and the bytes differ for good reasons, so judging the result needs somebody to look at it.
When should I check?
While the source still exists. Checking after the original has gone turns every finding into a problem rather than a correction. The pressure to delete the source also peaks immediately after a run reports success.
How much checking is enough?
Enough to have looked at the awkward cases rather than a percentage. Ten items picked at random tell you almost nothing. Four chosen from the edges tell you most of what there is to know.
Sources
Where the figures and behaviour described above were checked.
- Data migration Wikipedia
- Data degradation Wikipedia
- Data validation Wikipedia