How Do I Migrate My Cards From Manual Inventory?

Migrating cards out of manual inventory isn't one job, it's two: get the data in, and trust that it's right. Most of the pain people expect from the first part. Most of the actual risk is in the second.

"Manual inventory" covers more ground than people think when they go looking for a way off it. For some dealers it's a spreadsheet that has grown for three seasons. For others it's a binder with sticky notes, a notebook of buy prices, or nothing written down at all, just a memory of what's in which box. The path off each one is different, but the goal is the same: a searchable record of what you have, what it cost, and what condition it's in, that you can trust at a table without double checking a case.

The mistake is treating this like a single afternoon of data entry. Done that way, it either stalls out after the first forty cards or it finishes and you can't tell whether it's actually right. The faster, more reliable path starts by sorting what kind of manual system you have, then moving the stock that matters first and proving the result before you trust it with everything.

Migrating cards from manual inventory starts with naming what you actually have

Before you move anything, separate your manual inventory into two categories, because they take different paths into an app:

• Structured records. A spreadsheet, even a messy one, where each card already has its own row with some combination of name, set, cost, and condition.
• Unstructured records. A binder, a box, sticky notes, a notebook of buy prices, or cards you can identify on sight but have never written down anywhere.

Most dealers have some mix of both: a spreadsheet for the higher-end singles and a vague sense of everything else. That's fine. The point of sorting first is that a spreadsheet is a data problem (get the columns right, then import), while a binder or box is a scanning problem (pick the cards up one at a time). Trying to force one into the other's process is what turns an afternoon into a lost weekend.

Two different doors into the app

If your records are structured, CSV import is the faster door. CardOps' CSV import is free, and it's built to take an existing file rather than ask you to re-enter what you've already recorded. The work is mostly in getting your columns to match what the importer expects: card name, set, condition, cost, quantity. If your spreadsheet has grown its own dialect over the years, with a "Paid" column instead of "Cost" or three different spellings of near mint, that cleanup is worth doing before you import, not after.

If your records are unstructured, the scanner is the faster door. Point the camera at a card and on-device recognition matches it against a catalog of more than 20,000 Pokemon cards and attaches a live market value, so you're not typing set names and numbers from memory for a box you've never catalogued. For a binder or a backstock box, that beats trying to manufacture a spreadsheet from scratch just so you have something to import.

Start with the stock that earns, not the whole collection

Whichever door you use, don't try to migrate everything before you trust the system. Start with the cards you actually sell from most: the singles that move every show, the ones you'd notice immediately if the record was wrong. That's usually a few dozen to a few hundred cards, not your entire backstock.

This does two things. It gets your fastest-moving inventory live and usable the soonest, and it gives you a small, familiar set to check against your memory of what you have. A bulk box of commons you haven't touched in two seasons can wait; getting it wrong costs you nothing right now. Getting your top sellers wrong costs you a sale at the next table.

Carry over cost and condition, not just card names

It's tempting to migrate just the names and call it done, especially from a binder where cost was never written down anywhere. Resist that. A record of a card with no cost attached can tell you what you have, but it can't tell you what you made when it sells, and that number is most of the reason to be doing this at all.

If your manual records never had a cost field, don't invent one. Enter what you can verify, mark the rest clearly as unknown, and fill it in going forward as you actually remember or dig up an old receipt. A missing cost is honest and fixable. A guessed one quietly wrecks your margin math later and you won't know which cards it happened to.

Condition deserves the same honesty. If a binder's cards were never graded on paper, don't default everything to near mint because that's faster. Grade what you're entering as you enter it. It's the only point in this whole process where you'll have every card in hand at once to look at.

Verify a batch before you trust the rest

Once your first batch is in, whether it came through CSV or the scanner, check it before you move on to the next one. Compare the card count and a rough inventory value against what you expected from your manual records. If a dozen cards are missing or a condition landed wrong, it's much easier to find the cause in a batch of fifty than to untangle it after your whole collection is in.

This single habit is what separates a migration that sticks from one that gets abandoned halfway. A small, verified batch proves the process works before you sink hours into the rest of it. CardOps carries no account and keeps your data on the device and in your own private iCloud, so there's nothing to re-sync or lose between batches, only your own pace to set.

Keep the manual records until the new ones have proven themselves

Don't throw out the binder or delete the spreadsheet the day you finish migrating. Keep it as a reference until you've run at least one real show off the app and the numbers held up: the cards you expected to have were there, the prices you entered matched what you sold them for, and nothing felt like it was missing at the table. One show is usually enough to know. If anything looks off after that, you still have the original source to check against instead of trying to remember it.