QuickBooks to Shopify: Catalogue Moved Once, Moved Correctly

Who this is for

Retailers whose product catalogue lives in QuickBooks. Not because anyone chose QuickBooks as a product database, but because every invoice line item needed an item, every item needed a price and a SKU, and over the years the accounting file quietly became the only complete record of what the business sells.

That works right up until you want a real online store. Then the catalogue is in the wrong place, and the two obvious ways out are both bad: weeks of manual retyping that produces transcription errors nobody finds until a customer orders the wrong thing at the wrong price, or a one-shot CSV import that fails halfway and leaves a half-populated store with no record of which half made it across.

If that is where you are, with a full catalogue in QuickBooks, a store you want to open, and no appetite for either of those paths, this service exists for you.

What we deliver

We build the migration as a pipeline with the properties you would demand of any production system, not as a one-time chore.

Batched, checkpointed progress. Products move in small batches, and the pipeline records what it has done after every batch. If anything interrupts the run, it resumes exactly where it left off, whether the interruption was a dropped connection, an API rate limit, or a deliberate stop. Interruptions cost minutes, never a restart.

Variants carried whole. A product is not just a title. Variants move with their options, SKUs, prices, and compare-at pricing intact, as a unit. A catalogue migration that leaves the variant structure for later has migrated a list of names, not a catalogue.

Collections created once and reused. Categories in the source become Shopify collections, created on first encounter and remembered on every subsequent reference. No run ever mints a duplicate collection or decays the store's navigation.

Idempotent re-runs. Run the pipeline again, against the same export or a corrected one, and it converges on the right answer instead of duplicating the store. This is the property that separates a tool from a script, and it is what makes the migration safe to operate rather than merely possible to execute.

Verification before launch. The migration is not done when the pipeline finishes. It is done when the result has been checked against the source: product counts reconciled record by record, a deliberate sample of variants checked for SKUs, prices, and compare-at values, and a test order placed, because pricing errors that survive every spreadsheet review tend to surface at checkout. All of this happens before the store is announced to anyone.

What happens after launch

A clean migration solves the catalogue problem once, not permanently. From the day the store opens, you have two systems that both believe they know the product list: QuickBooks keeps receiving purchases and adjustments because the accounting still lives there, and Shopify keeps selling. The two records start to drift immediately.

Keeping them aligned is its own project, with its own failure modes: sync conflicts, partial updates, the question of which system wins when they disagree. We scope it separately rather than bolting it onto the closing days of a migration. The right order of operations is the boring one: move the catalogue correctly first, then decide how the two systems stay in agreement. A migration pipeline built properly becomes the foundation that work stands on.

Proof

We built this pipeline for NRG Alternatives, a lighting retailer in Belleville, Ontario whose full catalogue (products, variants, options, collections) lived in QuickBooks and now lives on Shopify, moved in checkpointed batches with every API write routed through an isolated, credential-scoped gateway. The reasoning behind the approach is written up in full in our article on QuickBooks to Shopify migration.

Questions owners ask