Recording Migration Acceptance Report

Converted is not an acceptance criterion; verifiable is

At the end of a migration the usual delivery statement is that everything has been converted. That sentence cannot be checked and cannot be handed to internal audit or to a regulator, because it says nothing about how many recordings there should have been, how many actually arrived, how many are missing, and which ones. Only one shape of statement can be checked: a count taken against the records of the source platform database, giving a total, a success count and a missing count, with every missing item traceable to a specific call. The first is a conclusion; the second is a report a third party can recompute. The point of acceptance is not to trust the vendor. It is that anyone holding the same data arrives at the same numbers.

The baseline is the source database, not the export folder

The denominator decides whether the report means anything. Count the files in the export directory and the success rate comes out near one hundred percent every time, because the calls that never made it out are not in the denominator at all and the gap hides itself. The correct denominator is the number of qualifying call records in the source platform database: fix the scope first by date range and business scope, count the records inside that scope, and confirm that number in writing before the export starts. Success rate is then usable audio divided by that baseline, and the missing rate is the difference divided by the same baseline. Usable needs a definition too: the file decodes, its duration agrees with the database record, and it resolves back to a primary key in the source. All three, or it does not count.

The time distribution of the gaps beats the total

A report that says 0.8% missing and stops there has said nothing. The same 0.8% spread evenly across ten years usually means occasional physical damage to individual files or media. Concentrated in three particular months, it usually points at something that changed in that window: a system configuration, a codec version, a batch of storage media. Concentrated in the same hour of every day, it usually means the archiving job of that era was colliding with the daily traffic peak. So the missing list has to be plotted by month, by week and by hour of day, and the root cause tends to surface on its own. The total tells you whether there is a problem. The distribution tells you where it is, and whether the remaining gap is still worth the effort of recovery.

Separate the root causes, because they are different failures

Missing is not one phenomenon. It is several unrelated ones added into a single number. Media level damage: physical bad blocks on tape or disk, showing up as read errors or as data that comes back shorter than it should be. Codec level failure: the file reads fine but decoding fails or produces noise, which usually traces back to non standard encoding parameters or a proprietary variant in use at the time. And the category that gets overlooked most often: the source record itself is empty. The call was set up and the record was written, but nothing was ever captured, or the audio was already lost in some system operation years ago. That last group was not created by this migration and has to be listed on its own. Otherwise it is counted as a migration failure, and the problems that can actually be fixed are buried inside it.

Random, time stratified and agent based sampling differ

Reconciliation proves the counts line up. It does not prove the content is right, and sampling is what covers that layer. Purely random sampling gives an unbiased estimate of overall quality and belongs in the summary section of the report, but the sample naturally concentrates in the years holding the most data, and the earliest material may not be drawn at all. Time stratified sampling forces coverage of every year and every media batch, and exists specifically to catch systematic problems confined to one period. Sampling by agent or by extension catches problems tied to the recording channel, such as a handful of channels that were mono or ran at the wrong level from the start. Each method has a blind spot the others cover, so a formal acceptance runs all three and reports the results separately rather than merging them into one pass rate.

What an acceptance report has to contain

1. The definition of scope: date range, business scope, the inclusion and exclusion rules, and the resulting record count from the source database, which is the baseline. That number is confirmed in writing before the export begins.
2. The three core numbers and how they were derived: success count, missing count and success rate, together with the stated test for success (it decodes, the duration agrees with the record, it resolves back to a source primary key).
3. A line by line list of the missing items, each carrying the source primary key, the call time and a failure category (media damage, decode failure, empty source record, other), so that any entry can be looked up again.
4. The time distribution of the gaps, by month and by hour of day, with an explanation for every visible cluster, or an explicit note where the cause could not be identified.
5. Sampling results: method, sample size, pass count, fail count and the specific problems found, with random and stratified results kept apart instead of merged into one rate.
6. The raw material needed to recompute everything: the query used to count the source database, the export manifest and the output of the verification scripts. The receiving side should reach the same numbers without the vendor.

How Shanghai Wanchun approaches it

We work on parsing and migrating historical call center recordings, and the verification report is part of the delivery alongside the audio and the metadata rather than a note written up at the end of the project. The baseline is agreed before work starts, the tests for success and for missing are written down instead of being explained afterwards, gaps are listed item by item and classified by cause, the time distribution and the sampling results are delivered with them, and every number comes with the raw material needed to recompute it. The aim is a report that can go straight to internal audit or to a regulator: not one that asks them to believe the migration is complete, but one they can verify for themselves.