Switching reference managers feels simple until you realize your tags and ratings did not come along. You point the new app at your image folder, the import runs, and you get the images — but the years you spent tagging are gone. Somewhere between the old app and the new one, the metadata disappeared. Now you have a folder of untagged images and no easy way to get the tags back. This scenario is surprisingly common, and the frustration is entirely preventable.
Why tags get lost in migration
Every reference app stores metadata differently. This fundamental difference is the root cause of most migration failures. Some apps write metadata directly into the image files using EXIF or XMP — if you open the images in a different app, the data is there. Others store metadata in their own database or sidecar files — the data exists only inside that app's folder structure and database.
The problem emerges at export time. Apps that write to EXIF can export images with their metadata intact. Open the images anywhere, and the tags and ratings are still there. Apps that store metadata in a database have to export both the images AND the metadata file. If the export tool only copies images, the metadata stays behind. Some apps offer partial export where you get images and ratings but not notes, tags or keywords. You get back a folder of images with some data, but not all of it.
This is not always the source app's fault. Sometimes the destination app simply cannot import the format the source app uses. The tags exist in the old app's database, but the new app does not know how to read them. This is why knowing what you are importing into matters as much as knowing what you are exporting from.
How to spot a failed migration before it becomes permanent
The worst time to discover a failed migration is three weeks later, when you have deleted the original app and rebuilt your workflow around the new one. By then, recovering the lost metadata is expensive or impossible.
During migration, take these steps before committing to the switch. First, count your metadata in the source app. How many images have tags? How many have ratings? How many have notes? Write these numbers down. Export or import into the new app and let the process complete entirely. Then count again in the new app. Do the numbers match? If you had 8,000 tagged images and the new app shows 2,000 with tags, something failed.
Search for specific tags. Pick a tag you know you used extensively and search for it. In Coii Ref, a query like tag:texture should find hundreds of images if you tagged consistently. If it finds none, the tags did not make it. Spot-check images by opening a few in the new app and verifying the tags are actually there. Do not just assume the app shows them; actually open them and look.
If the numbers do not match, the migration lost data. Do not proceed further. Keep the original app installed and try a different export or import method. The cost of this caution is a few hours. The cost of ignoring failures is years of manual re-tagging.
Why running both apps in parallel is the safest path
The safest migration route is not to migrate all at once. Instead, run both apps side by side for at least a week. First, export or copy your images to a folder — do not move them yet; keep the originals in their current location. Point the new app at the copy. Let the import or index run to completion. Verify the metadata came across by using all three verification methods: count, search, and spot-check.
Run both apps for a week. Use the new app as your primary and keep the old one open for reference. During this week, if you notice a missing tag or a query that should work but does not, go back to the old app and re-check. This is your safety window. If the migration lost a thousand tags, you discover it when you can still go back and fix it.
Only after a week of confidence, delete the old app's library — or archive it to cold storage for emergencies. This approach costs a few days of parallel work and a bit of disk space. The payoff is that you catch failures before they are permanent. If migration lost data, you can fix it without losing access to the original.
Different apps, different export quality
The export experience varies widely depending on which apps you are using. Understanding what to expect helps you prepare. Eagle to Coii Ref: Eagle does not have a native importer in Coii Ref, but you can export everything from Eagle and point Coii Ref at the exports. EXIF metadata (dates, dimensions) comes through. Eagle's own metadata (tags, notes) does not export into the image files, so you have a choice: keep the tags in Eagle and treat it as read-only, or export and lose them.
For refern, Coii Ref will eventually have native importers. For PureRef, the situation is different: PureRef stores notes on the board, not on the images. Export from PureRef gives you the images; the board layouts and notes do not transfer. Pinterest doesn't export metadata at all; you get images only. Re-tagging is manual or requires a tool that can read the Pinterest board structure, which most cannot.
For any app-to-app migration, check the destination app's documentation first. It is the only reliable source of what will actually transfer. Do not rely on assumptions or what worked for someone else's app setup.
~/Pictures/Reference- Fabric
- Architecture
- People
- coii-thumbnailswritten by Coii Ref
- coii-proxieswritten by Coii Ref
- coii.dbwritten by Coii Ref
How Coii Ref prevents metadata loss
Coii Ref stores metadata in multiple places by design. Embedded EXIF goes into the image files themselves (if the format supports it). For formats that do not, XMP sidecar files store metadata beside the images. The workspace database indexes everything for fast search. When you back up the workspace folder or move it to another Mac, all three come along. This redundancy means your metadata does not depend on any single storage location.
When you migrate from another app, Coii Ref tries to preserve what exists. If the source app exported images with EXIF metadata intact, Coii Ref reads it on import. If the source app has a supported importer, metadata comes across through path matching. For other sources, you export to a folder, point Coii Ref at it, and whatever EXIF or XMP the original app wrote is immediately queryable.
The key difference: Coii Ref never locks metadata into its own proprietary database. If you ever switch apps again, you can export from Coii Ref and the metadata travels with the images because it is stored in the files themselves. This portability is the real insurance against future migrations going wrong.
Avoiding the problem next time you choose a tool
If you are choosing a reference manager now, ask these questions before you commit. Does it write metadata into the images (EXIF/XMP) or only into its database? Can it export complete libraries with metadata intact? If metadata matters to you, test the export during the trial. Export a folder, open the images in another app, and verify the tags are there.
If you ever need to switch again, the metadata will travel with you instead of getting trapped in the old app. This is also why many professionals use tags and ratings sparingly in commercial apps and do most of their organization in folders, which are portable and always readable. A folder structure survives every app change. A tag system is only as portable as the app allows.
The honest truth: if you have spent years building tags in an app that does not export them into the images, your metadata is trapped. That is not a reason to avoid tagging now — tags are worth having — but it is a reason to choose an app that does not lock them in. The best time to prevent a migration disaster is before you start tagging, not after you have thousands of tags to recover.
Read how to tag reference images consistently for tagging strategies that survive app changes. The guide to what is a reference manager explains the category. And what happens to my library if the app shuts down covers the long-term risk of metadata that lives only in an app's database.
For those migrating from a specific app, check our pages on whether Eagle copies your files — this affects what you can recover during export. If you are interested in how reference managers differ fundamentally, see what is a DAM and image organizers that don't move your files — these explain the architectural choices that make metadata portable or trapped.
The 30-day trial for Coii Ref includes the full import capability. If you use another app, export a folder and point Coii Ref at it. Check that your tags came through by running a search. If they did not, you know before you commit. If they did, you have a second set of migrations to verify before deciding to switch permanently.
The hidden cost of vendor lock-in
Metadata stored in proprietary databases is a form of vendor lock-in. You are free to take your images whenever you want, but the years of organization and tagging stay behind in that closed database. This is not intentional malice on the part of app developers; it is simply a consequence of how they chose to build the app. But the consequence for you is real: your metadata becomes increasingly valuable the longer you use the app, but simultaneously becomes increasingly difficult to move.
This is why choosing your first reference manager carefully matters more than switching later. The transition costs for metadata are high enough that many people stay with apps they have grown to dislike simply because leaving behind years of tags feels impossible. Some people handle this by importing data into new apps anyway and accepting the loss of metadata as an inevitable cost of change.
Others take a different approach: they use tags sparingly and invest in folder organization instead. A well-designed folder structure is portable, searchable by any app, and survives forever. A tag system is only portable if the app lets it be. The choice between these approaches should be yours to make, not forced on you by an architecture decision made years ago.
Building a migration workflow that works
For large libraries with extensive metadata, establish a permanent migration workflow rather than a one-time export. Keep the original app running in parallel with the new one for months if needed. This is not just backup; it is a hedge against discovery. Weeks into using the new app, you might realize that a thousand images lost their tags and the only way to recover them is to have the old app still available.
Document what metadata came across and what did not. In a spreadsheet, list which apps you are migrating from, what metadata each app supports, and what the import process preserved or lost. Over time, this becomes institutional knowledge that guides your next migration. Share this information with colleagues and peers. The more people understand the real costs and constraints, the better informed choices everyone can make.
Test imports incrementally, not all at once. Import a representative subset first — a hundred images with the most important tags — and verify completeness before committing to the whole library. This catches configuration errors and mismatched formats early when the fix is simple rather than late when re-migrating the entire library is the only option.