Writing · September 24, 2026
Metadata is the first thing you lose in a migration
Move a document library from one system to another — SharePoint to SharePoint, an aging document manager to a new one, a file share into something governed — and the files come across fine. Set them beside the originals and they match. The metadata is a wreck. Half of it is blank, some of it landed in the wrong columns, and the taxonomy that made sense in the old system means nothing in the new one.
That happens because the metadata was never the file's. It was the system's. The columns, the tags, the properties panel, the folder that stood in for a category — all of it lived in the platform and was tied to the file by an identifier the next platform doesn't use. When the file crossed, the metadata stayed home. A migration doesn't lose the metadata by accident; it pulls apart two things that were only ever held together by the system you're leaving.
And it isn't only migrations. Every ordinary way of attaching metadata keeps it somewhere other than the file, and every one of them has a moment where the two come apart.
A system column or a database is the thing you're migrating away from; it doesn't travel with the file, by definition. Extended file attributes ride along on your own disk and are stripped the first time the file crosses a filesystem or an upload. A sidecar file travels only if whoever moves the document remembers to bring it, and a bulk move never does. Even the one method that really does put the metadata inside the file — the document's own properties, the fields a PDF or an Office file can carry — only works for formats that have them: your scans, your drawings, your ZIPs, your CSVs and your proprietary exports either can't hold it or each hold a different, incompatible kind. And writing those properties rewrites the file, so the original you carefully migrated is no longer byte-for-byte the original you started with.
So the metadata can't live in the system, and it can't live in the file's own format. It has to belong to the file itself — something the file carries, not something done to it.
Slipcase is a container format built for that. A Slipcase container — one file, a .slpc — holds a document of any kind together with its metadata and moves as a single unit. A PDF, a scan, a drawing, a ZIP, a proprietary export: each gets the same structured metadata, because the metadata isn't wedged into the document's own format. The container carries both, side by side. Migrate the .slpc and the metadata migrates with it, because there is nothing to leave behind — it is one file.
The metadata lives in a small, readable document that Slipcase calls the flyleaf. It is plain TOML — structured, typed, and written to be read, not a flat handful of strings:
title = "Quarterly Report — Northwind Division" reference = "NW-2026-Q2-014" department = "Finance" prepared = 2026-04-18 retention = "7 years" final = true
Because every container carries its metadata the same way, you can point a query at a whole folder of them and get rows back, the way you would query a table — which is how you check a migrated set for the records that came across without a retention date, or a reference, or an owner.
And the original comes back untouched. Slipcase wraps the document; it does not rewrite it. Open a container and the file that comes out is byte-for-byte the file that went in. So where stamping metadata into a document changes the document, a container leaves it alone: you can annotate a signed contract, a hashed record, a scanned original, and still hand over the exact bytes you were given. In a migration, that is the line between carrying a record forward and quietly altering it.
None of this is locked to my software, which matters most in the place I built it for — you do not put a migration's metadata into a format you would be stuck with. A .slpc is a plain ZIP with a TOML document inside, specified in the open at slipcaseformat.org under a public-domain license. The slipcase command-line tool reads and writes containers in a script or a migration pipeline; Slipcase Desktop does it by hand, a container at a time; and if every tool I make vanished tomorrow, unzip still opens one. The metadata survives because it is part of the file and the format is yours to keep.
I built Slipcase because in a migration the files are the easy part. The metadata is where the value is — the provenance, the retention, the context someone will need in three years — and it should not be the part that gets left behind.
Getting a document library from one system to another with its metadata intact is a good deal of what I am brought in to do, and the part clients underestimate every time. If your next migration is shaping up to carry the files and lose everything that made them findable, that is exactly the kind of problem I like being brought in on.