A retail data migration
QuickBooks Desktop POS→Runit
A move from QuickBooks Desktop POS to Runit needs an explicit map from a style grid, ALU versus item-number/barcode choice, store quantities and an excluded historical receipt to the receiving records.
Plan this migration Data migration: $2,999. Scope confirmed before booking.The records we review.
- Products & variants
- Style, size, and color relationships
- SKUs & barcodes
- Identifiers used across your stores
- Customers
- Supported fields and matching decisions
- Opening inventory
- Quantities mapped to each location
- Existing destination records
- Products and customers already in your next system
The decisions
we make first.
Source access
Review representative exports and the available extraction method.
History & balances
Assess sales history, gift cards, loyalty, and credits separately.
Test & acceptance
Agree the records and checks before the final transfer.
Assess the QuickBooks Desktop POS source
Readable Desktop POS installation and authorized lists/reports; distinguish POS records from the accounting company.
Shopify legacy connector instructions still require Stocky and its API key, while current Stocky guidance says its API ended. Do not promise that legacy workflow is usable now.
Keep an untouched original and a record of account, edition, location coverage and extraction time. The customer must provide full authorized access and be able to access their own data. Do not infer missing fields or access from a vendor family name.
Plan the Runit destination
Runit vendor-confirmed style/customer receiving fields and import process for the agreed implementation.
A style must remain linked to its size/color sellable records. Public read APIs or report exports do not establish a supported inbound style importer.
Inspect existing receiving records before choosing create, match or update behavior. An exported internal ID should remain in a reconciliation crosswalk unless the receiving specification explicitly accepts it.
Directional data decisions
| Dataset | QuickBooks Desktop POS evidence to preserve | Runit decision to confirm |
|---|---|---|
| Products and variants | Complete grouping, source IDs, sellable combinations and item status | Equivalent parent/variant structure and supported receiving fields |
| Identifiers and prices | SKUs, full barcode text, unit and price context | Matching rule, permitted identifier representation and accepted price behavior |
| Customer contacts | Source identity and duplicate candidates, separately from liabilities | Receiving method, existing-profile rules and rejected-row report |
| Location stock | Store/warehouse map, quantity type, unit and snapshot time | Correct receiving location and set-versus-add operation |
| History and commitments | Required receipts, gift cards, credit, loyalty and open orders listed individually | Native receiving method, approved transformation, archive or exclusion for each |
A representative test for this direction
Use a style grid, ALU versus item-number/barcode choice, store quantities and an excluded historical receipt. In the receiving Runit setup, also inspect a full style with an intentionally absent size/color combination, supplier code and two store quantities. Use these illustrative examples to plan your project’s sample and agree expected results before a production import.
Write expected identities, grouping and quantities before the sample load. Compare returned records and rejected rows, approve exceptions and capture changes made after the stock snapshot. Test any proposed history or balance operations separately so an item import cannot silently create a second liability or stock movement.
Official references
- Intuit Desktop POS discontinuation
- Shopify legacy QuickBooks connector migration instructions
- Shopify QuickBooks connector data limitations
- Shopify Stocky discontinuation and transition limits
- Runit implementation coordination
What the vendor documentation establishes
Shopify QuickBooks POS migration: Legacy connector instructions must be assessed against retired prerequisites rather than assumed operational.
Shopify Stocky transition: Stocky APIs stopped on August 31, 2026. A legacy connector depending on them needs a current alternative or explicit vendor confirmation.
Runit implementation coordination: Implementation coordination does not provide a public complete inbound field specification; request an approved receiving template for migrations into Runit.
Verified historical POS export procedure
An Intuit Team answer dated 14 September 2021 describes File > Utilities > Export > Inventory Items in Desktop POS. The wizard selects an Excel destination, worksheet and starting row, then an export template or explicit mapping before validation/export. This establishes a POS-specific extraction procedure, not a current all-edition field specification. Preserve backups; the separate import-template reset instructions in that thread are not needed for an outbound export.
The Intuit-hosted Point of Sale 5.0 guide distinguishes item number, UPC and Alternate Lookup (ALU) and documents customer/report export to Excel. This is historical version 5.0 evidence. It does not establish version 19.0 fields or prove that a store can export complete customer and multi-store stock data today. Do not substitute QuickBooks accounting IIF/CSV instructions for Desktop POS records.
Exact technical evidence still missing
Obtain a version-labelled Desktop POS export field dictionary or vendor-approved synthetic output for item number, ALU, UPC, style/attribute/size links, customer identity/contact columns and each store’s on-hand quantity. The verified historical export wizard is not that schema. Establish whether quantities are by-store or aggregated and which editions expose each field, then map them to Runit.
With the source schema established, align style/child and customer keys plus per-store quantities to the Runit receiving specification chosen for the engagement. No claim of a public generic Runit importer is made.
History, serial records and balances require a separately supported extraction/receiving method or an agreed archive/exclusion. Sqquid’s technical reviewer owns the missing specification and synthetic map with vendor support or an implementation partner. An actual retailer’s access, sample and acceptance remain engagement work; no further owner business-policy approval is requested.
Migration scope and responsibilities
The standard migration fee is $2,999 USD for the confirmed scope.
Tailored to your retailer data
Every migration is unique. Your catalog, barcodes, orders and customer information are unique and proprietary to your business. We work closely with you to tailor the migration for the best possible outcome, agree the included records and define acceptance checks for your stores.
Routes offered subject to feasibility
We offer the currently listed migration routes subject to retailer-specific feasibility and an agreed scope. This includes POS migrations into Runit.
A project lead for your migration
Sqquid assigns a project lead to each migration. The lead is responsible for migration correctness and oversight of the entire migration dataset, including planning and managing data reversal when needed. The reversal method, dependencies and acceptance checks are agreed for your retailer’s systems and data.
Retailer-provided ERP and finance approvers
For ERP-related work, the retailer must provide an ERP approver and a finance approver. They approve the receiving requirements, included retail data, financial treatment and acceptance results within their responsibilities. Sqquid’s project lead coordinates the migration with them; full ERP implementation remains separate work.
Access to both systems
You must provide Sqquid full authorized access to both systems and be able to access your own data. Arrange access through an agreed secure process. Do not put passwords, API tokens, payment information or customer export files into the general enquiry form.
Source data quality
Sqquid is not responsible for migration errors caused by poor data supplied by the customer. Source issues, proposed corrections and exclusions need to be recorded before the transfer is accepted.
Earlier work and guarantee limits
Sqquid does not guarantee a migration that started before Sqquid was hired. Any guarantee is limited to the data migration work performed by Sqquid and expires on the launch date. Record the agreed launch milestone in the written scope; do not assume post-launch guarantee coverage.
Vendor charges and separate work
Vendor charges are passed to the customer in addition to the confirmed migration fee. POS implementation, hardware, payment setup, staff training and ongoing integrations have separate responsibilities and scope. A Sqquid software subscription is not required for the migration service.
Corrections before launch
We correct errors in our own migration work at no additional charge before launch.
Refunds for errors caused by Sqquid
If a migration error occurs and Sqquid is at fault, we will refund the fees the retailer paid us.
Your systems. Your next chapter.
From the first export to the final review.
Tell us where your data is today, and where you’d like to go. We’ll help you understand the next step.
Check my migration Retail data migration for $2,999. Scope confirmed before booking.