A month of work, three hours of work
Over 6,000 SKUs of product data migrated between two inventory systems in about three hours.
What this could do for your organization
If your team has a data migration that's been estimated in weeks — an inventory system upgrade, a product catalogue consolidation, a supplier or customer master cleanup, any case where messy data from one system needs to land clean in another — this is the shape of what I do. Raw data out of your current system, reconciled against whatever reference you're migrating into, handed back to your team as a clean import file with every change logged.
The items that demand a human decision — usually a fraction of a percent of the total — come out as a short review queue, each one with the reason attached. Your ops lead spends an afternoon on the ambiguous cases instead of weeks pushing rows around a spreadsheet.
The speed matters. But the point isn't the speed — the point is a transformation your team can defend: every change traceable to the rule that produced it, every flagged item explained, the whole protocol reusable on the next system change.
What your team gets back
Three things come out the other side: a clean import file, field-normalized and ready to drop into the new system; a full audit trail — old value, new value, rule applied for every transformation — so any decision in the output traces back to its reason; and a short review queue of items that couldn't be matched automatically, each one with the specific reason a human decision is needed. The pipeline is a one-time project; the protocol that comes out of it is a reusable asset your team can rerun on the next system change.
How I did it
A friend of mine mentioned over a coffee that a British e-commerce business he invests in was stuck migrating years of product data into a new inventory system. Their internal estimate was about a month. I told him I'd take a look. We did it in about three hours.
I taught my Claude to do the work. I was the teacher of the Claude, the operations manager was the subject-matter expert, and in two hours we taught the Claude what needed to be done. Then the Claude did it.
(People always ask me what "teaching the Claude" means. It means getting Claude to acquire the know-how and the judgment to do the work — not just running it once, but building up what it knows until it can carry the task the next time too. This engagement was a classic example.)
The first thing wasn't moving data. It was finding out what was already in the destination.
No CSV. Just pages.
Then the real work: making the rows say the same thing every time.
Sequenced by dependency, so each pass could trust the last.
99.5% matched automatically. 87 flagged for a human, each with the reason attached.
That engagement produced a protocol I now apply to any inventory-system migration. The full 21-technique version lives in my know-how library.
If you have a migration-shaped problem, the first session looks like this: an hour on your real data. If the shape fits, we keep going.
Related projects
Eighteen years of email, turned into a pattern library
My biggest data job — 18 years of email, mined down to 736 recommendations.
Read the story →
A training module, shortened on demand
Structured content transformation at the document level.
Read the story →
Window and door takeoff from PDFs
Another structured data extraction job, running live.
Read the story →