Moving an archive is a metadata and access-path problem wearing a data-transfer costume.

The trigger is usually external rather than strategic. Tape drives fall out of vendor support and spares become auction purchases. Archive software reaches end of life and the last engineer who understood its catalogue has retired. Media passes the manufacturer's rated shelf life, which is a statistical statement about degradation, not an expiry date, but auditors treat it as one anyway. Sometimes it is a vendor exiting the market, a data-centre consolidation in Dubai or Riyadh, or simply a floor of ageing hardware drawing power to hold data nobody reads.

None of those triggers give you an open schedule. Each one carries a hard date, and that date sets how much verification you can afford before cutover. Establishing it early changes the design.

A file is not the unit of value in an archive. The unit of value is the file plus everything that lets someone find it, trust it, and prove how long it must be kept.

• Directory structure and path depth. Some targets impose path-length or character limits that the source never had.
• Timestamps. Created, modified, last accessed and archived are four distinct facts. Naive copies collapse them into one and reset the rest to the migration date, which destroys any age-based retention rule.
• Ownership and ACLs. Cross-domain moves and NAS-to-object transitions are where permission models stop mapping cleanly.
• Custom metadata and tags. Case numbers, patient identifiers, study codes. Often held outside the file, in the old archive's catalogue.
• Retention state and the remaining clock. A record with three years left must arrive with three years left, not a fresh full term and not an expired one.
• Checksums and integrity records. The old system's hashes are your only evidence about what the file was before you touched it.
• Stub and link paths. Covered below, because this one strands more projects than the rest combined.

Migration risks and the control that addresses each

Tiering and archiving software leaves a stub, a link or a placeholder in the original location so that applications keep working after the real data has moved to tape, optical or object storage. QStar Network Migrator, for example, replaces the original with a stub when it migrates a file, and the file remains reachable from its original file system path. Those stubs are the archive's user interface. Applications, scripts, DICOM nodes and mapped drives all hold references to them.

When the archive moves, every one of those references has to resolve to the new location, or be rewritten. Two failure shapes are common. Either the stubs are recreated correctly but point at an old server name that no longer answers, or the target enforces a naming rule the source did not and paths shift silently for a subset of files. Neither surfaces during a bulk copy. Both surface the first time a clinician or a case worker requests a fifteen-year-old record.

The practical control is a path inventory taken before anything moves, a documented remapping table, and retrieval testing driven through the actual application rather than through a file browser. Where the old catalogue holds metadata outside the files, that catalogue has to be exported as data in its own right. If it cannot be exported, that limitation belongs in the plan before the contract is signed, not after.

Legacy media is not uniformly readable, and you do not know which parts are not until you read them. A cartridge written in 2011 may have lived in a rack at 30°C for years. Optical platters may have surface damage on a small percentage of the set.

A read-verification pass across the source, before the cutover plan is finalised, converts an unknown into a number. That number changes the design. If a few percent of a tape set turns out to be unreadable, as an illustration, the conversation shifts to specialist recovery, to secondary copies, or to a documented and accepted loss. Discovering it in week nine of a migration turns the same conversation into an incident.

Migration tooling helps here. QStar's Technology Migration Tool is built to read archives written by older or non-QStar software, including LTFS, UDF and Plasmon-era file systems, and supports many-to-one consolidation from low-capacity source media onto current generations. It also runs in time-boxed increments that suspend and resume, which suits a source you are handling carefully.

A big-bang cutover on an archive assumes verification is fast. It is not. Checksum comparison across hundreds of millions of objects takes weeks, and until it completes you have no evidence that the new archive holds what the old one held. A cutover weekend gives you a switch with no proof behind it and no obvious way back.

Parallel running separates the two decisions. The new archive takes all writes from an agreed date. Reads are served from whichever system currently holds the object, with the migration engine transparently retrieving from the source when a request arrives for something not yet moved. The source goes read-only. Bulk movement continues in the background at whatever pace the media allows. This is the pattern the older PoINT Storage Manager migration collateral described in 2016, and it remains the sane shape for a file-system move today, whatever product implements it.

Two things make it reversible. The source stays intact and readable until sign-off, and the write cutover date is recorded so the delta written to the new system is a bounded, identifiable set. If something fundamental is wrong, you fall back to a known state plus a known list of changes. That is a rollback plan. A completed one-way copy is not.

Verification runs at two levels, and they cost very differently. Metadata comparison checks that names, sizes, timestamps and attributes match between source and target. It is fast and catches most structural faults. Full content verification recomputes and compares hashes for the file bodies. It is slow, and it is the only thing that proves the bytes survived.

Most estates use both: metadata verification on everything, full content verification on all high-value or regulated datasets plus a defined random sample of the rest. State the sample rate and the tolerance in the plan. "Ninety-nine point nine percent verified" is meaningless unless someone has decided in advance what the remaining fraction may contain.

Reconciliation is separate from verification. Object counts, total capacity and per-directory totals should agree between source and target, and where they do not, each difference needs a named explanation. Done means the reconciliation report is signed by whoever owns the records, not by the storage team.

The source is not safe to destroy at cutover. It becomes safe when verification is signed off and a defined tail period has passed without a retrieval gap being reported. Six to twelve months is a common range, but it should be set from your own retrieval patterns rather than borrowed.

During that tail you need retained read capability, which means keeping at least one working drive, the software able to mount the old format, and someone who knows how to use it. Budget for it. It is routinely forgotten and then bought back at short notice.

When disposal comes, media sanitisation is a records decision as much as a technical one. Rewritable tape can be cryptographically erased, or degaussed, though degaussing an LTO cartridge wipes its servo tracks and retires the cartridge for good. Written optical WORM has no erase operation, so physical destruction with a certificate is the only path, and the certificate is the evidence your auditor will ask for.

For the target architecture itself, see long-term data archiving, the archive management software that runs the policies, and tape and LTO systems if LTFS is the destination. The full range sits under solutions. If you are holding an archive with a support cliff in front of it, request an assessment and start with the read-verification pass.