Destination requirements
Review required fields, identifiers, and relationships.
POS to Acumatica
Define the retail records your Acumatica environment needs before planning the transfer.
Review my ERP migrationRecords to assess
Conceptual migration planning. Record support is confirmed before booking.
Review required fields, identifiers, and relationships.
Agree how destination data will be matched and reviewed.
Define counts, quantities, and the treatment of exceptions.
The proposed data work concerns stock/nonstock items, customers, warehouses, branches and enabled attributes/subitems. The ERP implementation owner must approve the objects, dependencies and permitted method before a migration is accepted. This is a scoped retail data assessment within a wider implementation.
Use the exact tenant release’s implementation and data-integration documentation to select an approved import scenario or interface. The documentation portal is a starting point, not evidence that a generic scenario fits every configured tenant.
R Series item/matrix identity and store quantities, with a separate customer extract and explicit liability requirements.
An item import can add quantities to existing stock. Confirm the specific operation before repeating a partial load.
Keep source IDs, field definitions, unit/currency context and the chosen extraction time with the map. Review duplicates and missing source values with the retailer rather than silently inferring replacements.
Item class, unit, warehouse and organizational relationships must be configured by the ERP lead. Ongoing commerce synchronization is separate from an approved one-time retail opening position.
| Retail source evidence | ERP decision requiring approval | Acceptance evidence |
|---|---|---|
| Product/variant identities and units | Correct item type, related records, units and existing-record behavior | Trace each included source ID to its accepted receiving record |
| Customer identity and duplicate candidates | Correct customer/business-partner identity and company scope | Created, matched, rejected and unresolved records reconciled |
| Store quantities and movement cutoff | Company/location/warehouse map and approved stock operation | Each item-location quantity checked independently |
| Retail liabilities and opening values | Finance-selected treatment and date; separate from master data | Approved controls by identity, company and currency |
| History and unsupported relationships | Native method, transformed reference, readable archive or exclusion | Known historical lookup and an approved exception register |
Start with a matrix with multiple sizes, an existing item and location-specific quantities. In Acumatica, verify one stock and one nonstock item, a warehouse-specific quantity and an existing customer in the approved branch. These are illustrative test choices. Use an approved test environment and record the expected identities, quantities and exceptions before loading.
The ERP lead accepts master data and relationships. The retailer’s finance owner independently accepts any values or liabilities. Check the possible effects on posting, notifications, stock and connected systems before treating a test as safe to repeat.
Share the editions, locations, implementation lead and required retail records through Check my migration. Hardware, training, full ERP configuration and ongoing integrations remain separate work. Scope eligibility is confirmed before accepting the standard migration fee; no complete ERP conversion is implied.
R Series item import/export: New records leave System ID blank; existing records retain it. Store Quantity on Hand adds inventory rather than replacing it. Matrices and serials have separate rules.
R Series customer import: Customer templates go through Retail Imports. Custom fields are excluded; confirm actual supported characters and columns before preparing data.
R Series customer data: Customer exports and identity management are distinct from item exports.
Acumatica 2025 R2 import scenarios: Import scenarios specify target form, provider, object and mapping. Portal existence is no longer the only evidence, but the tenant scenario and owner approval are still missing.
The standard migration fee is $2,999 USD for the confirmed scope.
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.
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.
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.
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 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.
$2,999 for the confirmed data migration scope.
ERP configuration is a separate workstream.
Accounting history and balances need individual assessment.
Confirm my project scope