Moving a collection between apps is a CSV job, and it goes wrong in one predictable place: the file names cards but does not name printings. Every app in this space exports a spreadsheet, and every importer reads one, so the transfer itself is a few clicks. What decides whether the result is your collection or a rough approximation of it is which columns the export carried and whether you checked them before importing.
So the work is front-loaded. Get an export that identifies each copy exactly, look at it in a spreadsheet before you upload it, and expect a review step afterwards for the rows that could not be matched. Skipping the middle step is how people end up with a thousand rows of the wrong printings and no easy way to tell which ones are wrong.
Find the export in each app
Moxfield, Deckbox, TCGplayer and Archidekt can each produce a CSV of a collection. Look for a download or export control on or near the collection view rather than on a deck, and if it is not where you expect it, search that app's own help pages — labels and their exact position move between redesigns, and anything written here about a specific menu would be out of date before you read it.
Two distinctions are worth getting right before you click anything.
- A collection export is not a deck export. Deck lists carry quantities and names but often nothing that identifies a printing, because a deck does not care which printing you play. Exporting your decks and calling it a collection is the single most common way people lose print-level detail.
- Some apps offer more than one export format. Where you get a choice, take the one with the most columns, even if it looks cluttered. You can ignore a column you do not need; you cannot recover one that was never written.
Export the whole collection in one file where you can. A single file imports as a single batch with one review queue, and a batch is far easier to audit than nine partial ones.
Keep the export. Save the original file somewhere outside the app you are leaving, and do not close or delete the source collection until you are satisfied with the result. An export is a snapshot you can re-run an import from, and it is the only version of your data that belongs to neither app.
Check what the CSV has to carry
Open the file in a spreadsheet before importing it and look at the columns. A good export identifies each copy on seven fields.
- Card name. Necessary but never sufficient on its own, because a widely reprinted card exists in many printings at very different prices.
- Set code. The short code for the release the copy came from. This is the field that makes an import meaningful.
- Collector number. With the set code, this pins one specific card in one specific release, including the alternate-art and variant slots that share a name with an ordinary printing.
- Finish. Whether the copy is non-foil, foil or etched. Foil and non-foil copies of the same printing are separate objects with separate prices.
- Condition. The grade you assigned. If the source app never held condition, the import cannot invent it.
- Language. Which printing language the copy is in, which matters for both identification and value.
- Quantity. How many copies of that exact combination you own.
If a file has a Scryfall id column, keep it. It identifies a printing outright and is the strongest thing an importer can match on, which makes those rows the ones least likely to need review.
Columns you can usually ignore are the ones the destination will work out for itself: prices, rarity, colors, mana cost, type line and anything else that follows from the printing. Those are attributes of the card, not facts about your copy. The columns worth defending are the ones only you know — which printing, which finish, what condition, which language, how many.
Set code and collector number together are what make the rest work. A file with those two is a description of physical objects. A file without them is a shopping list, and identifying the printing is the manual work you inherit if you import one anyway. The set index is a useful reference while you check, because it lets you confirm that a code in the file is a real set rather than a typo.
Spot the export problems before they cost you
Four things go wrong often enough to be worth checking every time.
Names only. The export has card names and quantities and nothing else. No importer can turn that into printings, because there is no information in the row that says which printing you own — the choice would have to be a guess, and a guess that silently picks the cheapest or the newest printing is worse than no import at all. Expect those rows to need attention.
Missing or non-standard set codes. Some exports use a set name in full, some use an internal code that does not match the codes the rest of the world uses, and some leave the column empty for older cards. Sort by that column in your spreadsheet and the gaps and oddities group themselves together.
Foil as free text. Finish is often exported as a word in a column rather than as a clean flag, and the wording varies between apps and sometimes between exports from the same app — an empty cell in one file, a word in another, something different again for etched copies. Read what your file actually says before assuming an importer will read it the way you do.
Condition scales that do not line up. Apps use different labels and sometimes different numbers of grades. If the labels in the file are not the ones your destination uses, decide the mapping deliberately rather than letting a default decide it for you, and be conservative — inheriting an optimistic grade is how a collection quietly becomes overvalued.
Fix problems in the spreadsheet before importing, not after. Editing a column in one place is a two-minute job; editing the same mistake across hundreds of created rows is not.
Import and work through the unresolved rows
Import into an empty or nearly empty destination if you can, so that a bad batch can be undone by starting over rather than by unpicking it from cards you already had.
Expect three outcomes per row. Most rows resolve cleanly and become holdings. Some resolve to something, but not to what you meant — usually because the set code was ambiguous or the collector number was missing. And some do not resolve at all and land in a review state, waiting for you to say which printing they are.
That last group is a feature, not a failure. A row held for review is a row the importer refused to guess at, which is exactly what you want from something writing into your inventory. Work through it while the source app is still open in another tab, because the fastest way to resolve a row is usually to look at what the old system said about it.
After the import, spot-check rather than reading everything. Pick a handful of cards you know well — an expensive one, a foil, a card you own in two different printings, and something in a language other than English — and confirm each landed as the right object. If those four are right, the mechanism worked. Taking inventory covers what a good record holds once the import is done, and organizing the collection covers making the physical side match it. If your export came out of ManaBox specifically, importing a ManaBox export walks that file through the same path.
Doing this in ManaArchive
ManaArchive's CSV importer resolves each row by Scryfall id first and then by set code plus collector number, and a row it cannot pin down that way is held in a review state rather than guessed at — so a file carrying only card names will land in review instead of quietly attaching your copies to the wrong printings. Rows that do resolve become printing-level holdings with their finish, condition, language and quantity intact. See how it works if the export you are holding is the reason your collection currently lives in two places at once.