Migrating Off Spreadsheets

01

What spreadsheets do well

Start here honestly, because migrating too early wastes time and money on a problem you do not have.

A spreadsheet is free, instantly available, infinitely flexible, and requires no decisions about how your data should be shaped. For a seller with a few hundred items on one channel, it is a completely reasonable system, and the discipline of keeping one at all matters far more than what it is kept in. Someone tracking cost basis and sale dates in a spreadsheet is ahead of someone with no records at all in expensive software.

What a spreadsheet cannot do is be in two places at once. Everything that eventually breaks traces back to that single limitation.

02

The signals that it has stopped working

These are specific and observable. If none of them describe you, stay where you are.

• You have sold the same physical item twice. The decisive one. It means your stated availability and your real availability have diverged, and no amount of care fixes it structurally — the spreadsheet does not know a marketplace sold something.
• You are updating the same fact in more than one place. Every duplicate entry point is a future inconsistency. Counting how many places a quantity lives is the fastest diagnostic there is.
• You cannot answer "what is my margin on this category" without an afternoon of work. The data exists but is not connected to the sales it produced.
• You are afraid to touch the file. Formulas nobody remembers writing, columns nobody dares delete. A system you are frightened of is not a system.
• Finding a physical item takes longer than listing it. Location tracking has fallen out of the file and lives only in your memory.
• Adding a second channel feels impossible — and so you have not, even though inventory is aging on the first one.

03

Clean up before you migrate, not after

The single most common migration failure is moving messy data faithfully. You end up with the same inconsistencies, now in a system where they are harder to bulk-edit, and you conclude the software was the problem.

1. Reconcile against physical stock Not a full count necessarily, but enough to trust the numbers. Migrating quantities you know are wrong guarantees the new system starts wrong, and you will blame it.
2. Fix the identifiers Every item needs one unique, stable identifier, and it must be genuinely unique. Duplicates and blanks are what break an import. If you do not have a scheme, adopt one now — our guide to SKU systems covers what makes one durable.
3. Standardise the vocabularies One spelling per condition grade, one name per category, one format per date. Free-text columns accumulate variants — "VG+", "vg plus", "Very Good Plus" — that a machine treats as three different things.
4. Separate facts from formatting Merged cells, colour-coded meaning, notes in the margin, and blank spacer rows do not survive an export. If a colour means something, it needs to be a column.
5. Decide what not to bring Sold-and-closed items from years back, abandoned experiments, duplicate tabs. A migration is the cheapest time you will ever have to leave things behind.

This cleanup is worth doing even if you decide not to migrate at all. Most of the pain people attribute to spreadsheets is actually attributable to inconsistent data, which follows you into any system.

04

What has to come across

It is tempting to bring only what is currently listed. Resist it — historical cost and sale data is what makes the new system able to answer questions the spreadsheet could not.

Photographs deserve special attention because they are the one thing a spreadsheet almost never held properly — they are in a phone, a folder, or already on a marketplace. Getting them attached to item records is often the largest single task in a migration and the largest single payoff, because it is what makes listing the same item on a second channel take a minute rather than an hour.

05

Migrating without stopping trading

You cannot pause a business for a data migration, and you should not try. Move in slices.

1. Export the spreadsheet to a plain CSV and keep an untouched copy of it. This is your rollback, and you should not overwrite it under any circumstances.
2. Import one small, representative batch first — a few dozen items spanning your different categories and edge cases. Check the fields landed where you expected.
3. Fix the mapping and reimport the same batch rather than pressing on. Mapping errors multiply, and finding them in fifty rows is trivial where finding them in five thousand is not.
4. Migrate the active, listed inventory next. This is the part that has to be right, because it is what is trading.
5. Migrate historical and sold data afterwards, when nothing depends on it being immediate.
6. Connect one sales channel and watch it for a week before connecting the second. Two new integrations at once makes any problem twice as hard to attribute.

06

What actually changes afterwards

Worth setting expectations, because the benefits are not evenly distributed.

What genuinely gets better: one item is one record with one quantity, so a sale on one channel adjusts availability everywhere and the double-sale stops happening structurally. Listing the same item on a second channel stops being a retyping exercise. Margin per item and per category becomes a query rather than an afternoon. Bulk operations — repricing a hundred stale listings, rewriting titles across a category — become minutes instead of never.

What does not change: photography still takes as long, sourcing still requires judgment, and bad data still produces bad answers. Software removes the mechanical friction that stops good practices from happening. It does not supply the practices.

This is why the cleanup step matters more than the tool choice. A seller who standardises their grades and identifiers and stays in a spreadsheet is in better shape than one who imports chaos into something expensive.

07

Where Instica fits

Instica is built around the structure this guide keeps pointing at: one item is one record, with one quantity, one cost basis, and one set of photographs — and each connected channel reads from it rather than keeping its own copy. A sale on one marketplace adjusts what the others show, which is what makes the double-sale a structural impossibility rather than a discipline problem.

It imports from a CSV export of the spreadsheet you already have, so the migration path is the one described above. eBay and Shopify connect directly, alongside the other channels we support, and per-channel details like titles and prices stay independent while the underlying item stays shared.

If the signals in the second section describe your situation — particularly the double-sale and the multiple-places-for-one-fact problems — that is the problem it is designed to remove. If none of them do, the honest advice in this guide is to clean up your spreadsheet and keep going.