Liscaragh Migrate › Help › Understanding your audit trail and reports

Understanding your audit trail and reports

Every action Liscaragh Migrate runs writes two things: a per-file audit record and a readable report built from it. This page explains what each one actually contains, how the different report types differ, and how to keep them as evidence once the migration is over.

The audit record comes first

Every migration is a self-contained job, usually one per client, with its own logs, reports and state kept apart from every other job on the machine. Nothing about one job's history can bleed into another's.

As a run works through the files, each one gets a logged outcome, copied, skipped, failed or repaired, written to that job's audit record. This is the authoritative verdict on the run, not a summary count: if a report and the audit record ever seem to disagree, the audit record is correct, because the report is generated from it.

What a run's HTML report contains

Every action that produces a result, Check readiness, Preview, Upload, Sync new and changed, Verify files arrived and Compare sizes, opens a single self-contained HTML report when it finishes, built from that run's own audit record. It is one file, so it is easy to archive or send to a client.

A full migration report (Upload or Sync) is structured in two parts:

• Run details. The who/what/when/how of the run: run type, source, number of projects or sources involved, start and finish times, the copying window, who ran it and on which computer, the app version, how many uploads ran in parallel, any speed limits or filters that were active, whether name tidying was on, and which audit file the report was built from.
• Run insights. The 10 largest files in the run, the 10 slowest uploads, and every file that hit a retry along the way. Zero-byte files are named individually rather than just counted.

Below that sits the full per-file listing, deliberately complete rather than trimmed, with jump links at the top so you can go straight to the section you need.

Reports differ by what the action actually checked

A report always matches the action that produced it:

• Check readiness produces a readiness report: a one-letter grade from A (migrate as-is) to D (blocked on storage) with a one-line verdict, an "Action needed before migration" block listing anything that needs a human decision, a separate section for issues tidied automatically with no action needed, the largest files in the job, and how many gigabytes are sitting in duplicate files. A duration estimate appears once the job has completed a real upload to measure actual throughput from; it deliberately says nothing rather than invent a number before that.
• Preview produces a readiness-shaped report from a dry run: nothing is copied, but you get the same size and blocker picture up front.
• Verify files arrived produces a per-project present, missing and out-of-date breakdown, confirming every expected file actually landed at the correct size.
• Compare sizes produces a per-project count and byte overview of source versus destination, alongside a CSV listing exactly which folders differ and by how many files on each side.

Because each report is generated from that run's audit record rather than shared logic bolted on afterwards, the numbers in a report and the numbers in the underlying CSV always agree.

Two documents built to be handed to someone else

Two further outputs go beyond an internal record and are built specifically to be shared:

• Completion certificate. A one-page certificate issued once a job is fully copied, synced and verified, meant for a client to sign off against.
• Provenance pack. A manifest of every migrated file's path, size, content hashes and original modified date, countersigned by an independent RFC 3161 timestamp authority. Only the manifest's own 32-byte hash ever leaves the machine, so the tamper-evidence does not require sending your file listing anywhere.

See completion certificates and provenance packs for how to issue each one, what makes the provenance pack independently checkable, and why both refuse on a preview or an unfinished run.

Checking nothing has moved since

A migration's audit record stays useful after the run finishes. Check for drift compares the audit record of every landed file against the destination as it stands today, using the same read-only inventory walk Sync uses, and reports three buckets with evidence: files that have changed (a different size, or a later modified date than the migration moment), files that have been deleted, and files that have been added since. It is the way to settle "did the migration lose my edits" with actual dates rather than a guess, and it stays useful right up to cutover.

Where reports and logs actually live

Each job keeps its own logs and reports folders, reachable from inside the app with the Open log and Open report tiles rather than by browsing to them by hand. Log file names start with what you did, so a folder full of them stays readable at a glance.

Every log, report and outcome record is stamped with the exact app version that produced it, so any file you are sent or asked to look at can be tied back to a specific build without asking first.

Keeping records as evidence

Reports and audit files are treated as the customer's own migration record, not disposable output. A few things follow from that:

• Uninstalling the app never deletes a job's reports, audit records or resume state. They are left in place regardless of how the app itself is removed.
• Clear job data is the one action that does remove them, and it says so plainly before you confirm: it warns that this permanently deletes your proof that a migration ran, audit CSVs, HTML reports and provenance packs included, and points at Job > Export job as the way to back up first.
• Job > Export job zips the whole job, settings, mappings, logs, reports, resume state and audit files, into one archive you choose the destination for. Job > Import job brings an exported job back, with its history intact, on the same or a different machine.

If you need help interpreting something in a report or a log, 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.