A retail data migration
ERPLY→Runit
Plan this direction around a matrix product with custom attributes, an existing SKU and stock in two warehouses, then verify the receiving Runit 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.
Review the ERPLY source
Tenant-authorized product/matrix, customer and warehouse records with original IDs and custom attributes; confirm export coverage.
The Shopify connector describes an ongoing connection; it is not evidence of the complete one-time migration in either direction. Stock registrations are separate from master product creation.
Record the original identifiers, account/edition, included stores, extraction time and any source issues. Preserve an untouched original and verify that files or responses include the full intended record set.
Establish the Runit receiving method
A vendor-confirmed Runit style/customer receiving method and field specification for the chosen implementation.
Public read/access categories do not establish an inbound style importer or the exact permitted account fields.
Agree create, match and update behavior before preparing a full file. Keep a source-to-destination identity crosswalk rather than placing unrelated internal IDs into receiving fields.
Directional data plan
| Dataset | Source evidence | Receiving decision |
|---|---|---|
| Products and options | Full parents, sellable combinations, original IDs and active/archive status | Equivalent grouping, approved fields and existing-record behavior |
| Identifiers and prices | Full barcode/SKU text, units and price context | Accepted identifiers, selling units and price rules |
| Customers | Source IDs, supported contacts and duplicate candidates | Match rules, receiving method and created/updated/rejected records |
| Location stock | Store/warehouse mapping, quantity state, unit and snapshot | Receiving location and verified set/add behavior |
| History and obligations | Required receipts, cards, credit, rewards and open orders listed separately | Approved native method, transformation, archive or exclusion |
Proposed representative test
Use a matrix product with custom attributes, an existing SKU and stock in two warehouses. In Runit, also check a style with an absent size/color combination, supplier code and two store quantities. These are illustrative planning cases. Write expected identities, grouping and quantities before the sample and compare returned records with the approved map.
Investigate rejected rows, changed identities and stock differences. If history or balances are included, test their side effects separately. Record trading changes after the inventory snapshot and approve exceptions before the launch milestone.
Official references
- Erply product importer matching and matrices
- Erply stock quantity importer
- Erply Shopify connector; ongoing connection is distinct from one-time migration
- Runit reports, protected data access and APIs by request
What the vendor documentation establishes
Erply product export: New PIM export supports filters; verify which statuses, groups and warehouses are included.
Erply product importer: Map source fields and matching rules; matrix products require deliberate dimension relationships.
Erply customer export: Customer export is a separate XLS file and supports filters.
Erply customer import: Customer imports have separate mapping and update decisions.
Erply stock import: Stock import creates an inventory registration and adds quantity. Warehouse selection and registration price must be deliberate.
Erply getProductStock: Stock responses distinguish on-hand and reserved inventory. Default output omits zero quantities; completeness must be reconciled. Large responses can require CSV output.
Runit implementation coordination: Implementation coordination does not provide a public complete inbound field specification; request an approved receiving template for migrations into Runit.
Planning this direction with your project lead
ERPLY source records
Use the New PIM product export, separate customers and warehouse stock. Reconcile the stock API’s zero-quantity omissions and distinguish reserved amounts from physical quantities.
Runit receiving records
Coordinate the receiving style/customer/store-stock specification with Runit implementation. Sqquid’s project lead maps the retailer’s records into the agreed receiving format; an ongoing API integration is not a promised one-click migration. Approving that account’s template belongs to the engagement.
Resolve the transformation before loading
Build a source-to-Runit crosswalk for styles and sellable combinations, barcode/SKU text, customers and store quantities. Use the source system’s real grouping: Square variation tokens, Clover option relationships, ERPLY matrix identities and Lightspeed variant rows are not interchangeable Runit style identifiers. Select the applicable relationship for this source rather than flattening every row into a new style.
Acceptance is specific to your retailer
Use the representative case above with the retailer’s actual catalog, customer matches and store quantities. Record the intended result, extraction cutoff, rejects and recovery steps before loading. History, gift cards, credit, loyalty and open orders each need an agreed native method, archive or exclusion. Required account access, sample approval and launch milestones are engagement checks—not a claim of past Sqquid delivery or universal support.
Official method references
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.