What document metadata survives a move into Clio
When you upload documents into Clio, some metadata travels with the file and some doesn't — and most of the confusion comes from treating two different things as one. This is the field-by-field reference: what comes along inside the file, what your old system kept that doesn't reconstruct, and how to hold onto whatever you actually need.
Two things people call "metadata"
When a document moves into Clio, the question "did my metadata survive?" splits into two very different answers — and conflating them is what makes people think Clio rewrote their files when it didn't.
Metadata inside the file travels with it. Author, the file's own created and modified dates, tracked changes, PDF properties, image EXIF — those are part of the file's bytes, and Clio stores the file as you uploaded it. They come along untouched.
Metadata your old system kept about the file does not. The categories, tags, custom fields, prior version history, and the system's own date and matter-link records lived in that system's database, not in the file — so a plain upload brings the file, not the surrounding records. Clio then applies its own: it dates the document by when you added it, and starts its own version history from that point. The table below sorts every common case into the right column.
What survives, what doesn't, how to keep it
Labelled by field, not by the bare word "date" — because the file's own Created property and Clio's add-date field are two different things.
- The file's own Created / Modified property (the timestamps baked into the file)
- Author and last-saved-by (Office document properties)
- Tracked changes and comments inside the document
- PDF document properties and image EXIF data
Embedded in the file's bytes — Clio stores the file as-is, so these come along.
- Clio's Date field shows the upload date, not the file's original matter date
- Your old system's prior version history (Clio's own history starts at upload)
- Old-system categories, tags, custom fields, and retention flags
- Evidence-system chain-of-custody / integrity trail
Held in the old system's database, not in the file — a plain upload leaves it behind. Clio does have native Document Categories, though, so you can reapply that grouping after the move.
- Keep the source export / archive read-only for reference
- Use a paid migrator that maps metadata and versions across
- Bake the key fact into the filename or a per-matter manifest (e.g.
Contract_2019-03-12_v3) - For evidence, keep the original in its system of record
Decide what matters before the move — the cheap options happen at upload time.
Why Clio "changed" a date it didn't touch
This is the single most common surprise, so it's worth stating plainly. There are two dates, and they answer different questions:
The file's Created property answers "when was this document actually made?" It lives inside the file and travels with it; opening the file's properties in Clio (or after downloading it) still shows the real date.
Clio's Date column — the one in the matter's Documents list — answers "when did this arrive in Clio?" That reads as the upload date. It isn't overwriting the file's date; it's a separate field about the document's life in Clio.
So when a guide says "original dates don't carry over on a manual upload," it means Clio's Date column reflects the add-date — not that the file forgot when it was created. If you sort a matter's documents by Clio's date column and they all cluster on migration day, that's expected; the documents themselves still know better.
Separate from those two dates, Clio also has an editable Received date you can set on a document — at upload it lets you add the date you received the documents, and it stays editable afterward (via Create a copy). That gives you a real field to record the date a document was actually received, alongside the filename convention above.
Clio's history starts at upload
Clio keeps document version history natively: upload a revised copy of a document and Clio tracks the versions, retaining earlier ones so you can view them. There's no one-click revert button in the web UI, though — to make an older version current, you add it back as a new version (the "+" icon next to Version history). That capability is real and it works going forward; confirm current details in Clio's help center.
What a move doesn't do is reconstruct the history your old system kept. A contract that went through ten tracked revisions in a prior document-management system arrives as one current file, and Clio's version count begins at one — from the moment of upload. The prior trail isn't hiding somewhere in Clio; it simply wasn't part of the file you uploaded.
For most matters that's fine — the current version is what the work needs. Where the full revision trail is genuinely important, that's the case for a paid migrator that maps version history across, or for keeping the source system's archive accessible. Decide which matters need it rather than assuming the trail came along.
Does Clio change my files' dates when I upload them?
+It depends which date you mean — and that distinction is the whole confusion. The file's own Created and Modified dates are properties baked into the file, and they travel with it. Separately, Clio's Documents list shows a date column that records when the document was added to Clio, which will read as the upload date, not the file's original date. So both can be true at once: Clio's date column shows today, while the file itself still carries its real created date inside its properties. Nothing about the file's embedded dates is rewritten; what you're seeing is Clio's own add-date field, a different thing.
Does Clio keep version history when I move documents in?
+Clio has its own version history — upload a new version of a document and Clio tracks revisions from that point forward. What a move doesn't do is rebuild the version history your old system kept. A document that had ten revisions in a prior document-management system arrives in Clio as a single current file, and Clio's version count starts from that upload. If the prior revision trail matters, it has to be preserved separately — a paid migrator that maps versions across, or the archived source kept for reference.
What metadata actually travels with the file?
+Anything embedded inside the file itself: Office document properties (author, last-saved-by, the file's own created/modified timestamps), tracked changes and comments, PDF document properties, and image EXIF data. Clio stores the file as you uploaded it, so these embedded properties come along untouched. What does not travel is metadata your old system held in its own database about the file — categories, tags, custom fields, the link to a matter — because that data lived in the system, not in the file.
What doesn't come across from my old document system?
+Three things, in order of how often they bite: your old system's date/organization metadata (Clio dates the document by when it was added), its prior version history (Clio's history starts at upload), and any custom metadata it stored about documents — categories, tags, custom fields, retention flags, and the database links between a file and its matter. For evidence systems, the chain-of-custody and integrity record stays with the source system; Clio logs its own document activity, but that is not the same as an evidentiary custody trail.
How do I preserve original dates or version history that matters?
+Decide what you actually need before the move, because the cheap options happen at upload time. Keep the source system's export or archive read-only for reference. For matters where the full history is important, a paid migrator can map document metadata and versions across. For a handful of files, bake the key fact into the filename or a per-matter manifest — 'Contract_2019-03-12_v3' carries the date and version a glance, even though Clio's own date field shows the upload day. For evidence, keep the original in its system of record.
Is embedded metadata ever a confidentiality concern?
+Worth a thought. Embedded properties travel with the file, which is usually what you want — but it also means author names, tracked changes, and earlier-draft comments ride along. That matters most when a document leaves the firm, not when it moves between your own systems, but the same property data that survives a move into Clio is the data to scrub before a document goes to opposing counsel or a client. Treat 'metadata survives' as a feature internally and a checklist item externally.
Keep going
Clio document management
How matter documents are organized in Clio — folders, naming, versions, search, and permissions.
Read guide →Verify your Clio migration
The pre-cutover checklist — reconcile document counts, spot-check matters, and account for what doesn't carry.
Read guide →What Clio's data migration moves
What a standard migration includes and excludes, and why documents are a separately scoped workstream.
Read guide →