A move to Salla should begin with a transferability check and a reconciliation plan, not a new homepage. Before commissioning the migration, request an inventory of records, URLs and dependencies, a small trial transfer, and a plan for orders arriving during the transition. A successful import message is a technical milestone. A successful migration lets your team sell and support existing customers without losing track of the business.
Start with the reason for moving: difficult product maintenance, excessive operational complexity, or a mismatch between your process and the current platform. Otherwise, the same confusion may simply arrive in a different dashboard. A Salla store launch and rebuild proposal should distinguish destination setup from data transfer and verification.
Decide the destination of each record type
Inventory products, options, inventory, images, categories, customers, open orders, historical orders, vouchers, URLs and subscriptions. Give each a disposition: verified transfer, manual reconfiguration, reference archive, or approved exclusion. The word “complete” is not a substitute for these decisions.
Salla documents different product-import routes for different source platforms; product import does not establish that every historical object will migrate. Salla's platform-import guide.
| Object | Decision to make | Acceptance evidence |
|---|---|---|
| Products and variants | Map the parent and each sellable option | Correct identity, price and description |
| Open orders | Decide where fulfilment and returns continue | Named owner and accessible workflow |
| Customer records | Identify necessary data and its purpose | Authorised access and sample review |
| Images | Establish ownership and file availability | Correct assets remain accessible |
| Old URLs | Keep, redirect or deliberately retire | Tested destination map |
A restricted archive may be more honest and useful than an incomplete import that appears to contain the full history. Have the appropriate business owner determine retention and access requirements. Those decisions should not be improvised by the person configuring the storefront.
Map meaning, not just column names
For every field, record the source name, destination name, format, transformation and approver. Distinguish the merchant's SKU from a platform-generated identifier. They need not remain identical after migration, so retain a stable way to trace the record between systems.
Pay particular attention to empty values, units, colour and size names, and regular versus promotional prices. Does zero mean unavailable, or does it mean the quantity was never supplied? Does a product-family image actually represent every option? A technically valid import cannot answer commercial questions that the merchant has not resolved.
Where integration is required, separate a feasibility check from the build. An API integration and development scope should name the systems, transfer direction, supported records, duplicate-handling rules, error ownership and authorised data. An API's existence is not proof that every field can be written.
Ask how reruns work. If a trial partially succeeds, will the next run update the same records, create duplicates, or require deliberate cleanup? Have the implementer prove the intended behaviour on the trial set rather than discover it during the final import. Keep a record of transformations so a later reviewer can explain why a destination value differs from the original.
Worked hypothetical example: 120 parent products
This is an illustrative scenario, not a LAB case study. A merchant has 120 parent products, chooses 112 for launch and archives eight discontinued items. The selected range includes 36 sellable variant SKUs. Before comparing totals, the team establishes whether each report counts parent products, variants or both. Comparing 112 parents with a mixed total would produce a meaningless discrepancy.
The trial covers five products: a simple item, multiple sizes, unavailable stock, a temporary discount and several images. It reveals a colour label that differs between the stock system and the source file. The merchant resolves the naming rule before transferring the remaining records.
After transfer, parent and variant counts are reconciled separately. Every exclusion has a reason and every unexplained difference has an owner. The report does not hide discrepancies behind a reassuring overall success percentage.
The team also retrieves sample historical orders from their agreed archive and asks an employee to identify what was sold and respond to a customer enquiry. That tests business continuity; it does not imply those orders were imported into Salla.
Plan the cutover and the return route
Specify the final extraction time, who prevents conflicting edits, and how subsequent orders and stock movements are recorded. An order arriving after extraction but before cutover needs an explicit receiving system and stock owner. Otherwise, accurately transferred data may already be obsolete.
Define stop conditions before changing the domain: unexplained price differences, an unavailable essential payment method, or inaccessible open orders. Name the decision-maker and the rollback route that is actually available. Restoring the old storefront does not automatically reverse orders created in the new store; those transactions need separate reconciliation.
Treat URLs as a dedicated workstream within SEO and search readiness. Google recommends relevant redirect destinations and warns against sending unrelated old URLs to a single homepage. Google's site-move guidance. This is not a promise to preserve rankings.
What should close the migration?
The software quality assurance report should connect each test with its record, outcome and evidence: product and variant reconciliation, image checks, ordering, URL behaviour and archive access. Include accepted differences, unresolved items, owners and retest dates.
Agree who may sign off each area. A designer cannot approve stock accuracy on behalf of the warehouse, and a merchant cannot establish a technical transfer result by viewing a screenshot. Both commercial and implementation evidence belong in the acceptance record.
Common mistakes include cancelling the source account too early, importing everything before testing a difficult sample, overwriting newer inventory, and treating a product export as a complete operational backup. Avoid promising universal migration support before checking the actual account and supported transfer route.
Frequently asked questions
Can everything be transferred automatically?
Not as a responsible promise before inspection. Source capabilities, destination support and permissions determine the answer. Test a representative sample, then approve a transfer-and-archive matrix.
Are matching product counts enough?
No. Equal totals can conceal duplicate SKUs, incorrect prices or swapped images. Compare identity, meaning and relationships as well as counts.
When can I close the old store?
After open orders, archive access, URLs and operational responsibilities have an approved destination. A working new storefront alone is insufficient.
Must I redesign during the move?
No. Separating data and operational changes from visual changes can make failures easier to diagnose and retest.
A useful next step
Prepare an authorised source export, difficult product samples and an open-order list. Commission a bounded transfer trial and written reconciliation before committing to the full move.
Sources
Reviewed 26 October 2026: Salla product imports and Google site moves.