Migrating to Storeden requires more than placing records into a new admin environment. Storeden operates as a cloud commerce environment that can connect catalog management, inventory, Order handling, payments, themes, applications, marketplace selling, logistics, API resources, and wider TeamSystem ecosystem records. That operating model changes how migrated data should be interpreted.
A source store may contain products, categories, customers, orders, SEO records, app fields, marketplace identifiers, or ERP references that looked complete in the previous platform. After migration, those same values must support Storeden’s catalog structure, sales-channel readiness, order workflows, integrations, and business reporting. The data model question is therefore not only whether records arrive. The question is whether they still carry the right commercial meaning inside Storeden.
Storeden Data Meaning at a Glance
Storeden migration planning should separate record transfer from operational interpretation. A value that appears as a product option, order note, payment label, shipping method, customer group, custom field, or marketplace reference in the source store may need different handling in Storeden.
| Data area | Meaning to preserve | Storeden ownership question | Why the difference matters |
|---|---|---|---|
| Products | Sellable catalog identity | Product name, description, images, price, inventory, category placement, product visibility, and channel readiness | A product can exist but still be difficult to sell, locate, manage, or publish correctly. |
| Variants and options | Shopper choice and operational SKU meaning | Variant-like choices, attribute values, SKU relationships, stock implications, image logic, and price differences | Option structure affects storefront selection, fulfillment, inventory, and marketplace feeds. |
| Categories and navigation | Product discovery and merchandising hierarchy | Category grouping, menu logic, product placement, filtering expectations, and SEO paths | A migrated catalog can look complete in the back office while shopper discovery becomes weaker. |
| Inventory | Availability and fulfillment confidence | Stock quantities, SKU references, multichannel availability, logistics dependencies, and TeamSystem-connected inventory sources | Stock meaning may depend on more than one channel or system. |
| Customers | Account, buyer, and service identity | Customer profile, billing/shipping history, contact details, company context, and external references | Customer records need to support service, order lookup, account continuity, and marketing use. |
| Orders | Historical commercial context | Products purchased, customer relationship, totals, taxes, payment labels, shipping details, status values, and marketplace origin | Order history is useful only when staff can understand and act on it after migration. |
| Payments and shipping | Historical labels versus live configuration | Preserved order labels compared with active payment, carrier, logistics, and tax setup | Migrated history does not configure future checkout behavior. |
| Marketplace records | Channel-specific selling context | Listing identifiers, marketplace categories, channel prices, availability rules, and order origins | Marketplace continuity may require more than ordinary product and order migration. |
| Apps and API data | Workflow ownership and integration identity | App-owned data, API references, external IDs, automation triggers, and TeamSystem ecosystem connections | Connected workflows may need configuration or separate target design even when standard records migrate. |
| SEO and content | Discoverability and continuity | URLs, redirects, metadata, product descriptions, category content, image names, and theme-controlled pages | Search and user continuity depend on presentation and routing, not only imported records. |
Product Data Becomes a Managed Storeden Catalog
Product records are the visible center of a Storeden migration, but Product meaning extends beyond the Product row. A source Product may include titles, descriptions, codes, SKUs, brands, suppliers, tax classes, regular and promotional prices, visibility, Categories, images, variant relationships, related Products, custom fields, marketplace attributes, and external stock keys.
Storeden needs those values to form a catalog that can be managed centrally and distributed through the intended sales channels. Three ownership layers should be kept separate: the commercial Product seen by the buyer, the operational item managed by staff, and the channel or external-system representation used by marketplaces, inventory services, or accounting systems.
| Source element | Storeden interpretation | Relationship consequence |
|---|---|---|
| Product title and descriptions | Buyer-facing catalog content | Language, formatting, and Product identity must stay attached to the same commercial item. |
| SKU or Product code | Operational or cross-system identity | Variants, Order lines, inventory updates, and integrations must reference the intended sellable item. |
| Images | Product or variant media relationship | Primary, gallery, and variant-specific images should not be flattened into an unordered file list. |
| Regular and promotional price | Commercial value that may be time- or channel-dependent | Historical Order prices remain evidence; future price ownership belongs to the target pricing workflow. |
| Category assignment | Catalog organization | Category membership should not be confused with menu placement or marketplace taxonomy. |
| Visibility or status | Publication state | Active, hidden, draft, and retired Products need an intentional target meaning. |
| Custom field | Descriptive, operational, channel, or integration data | The destination depends on who reads or updates the value after migration. |
A Product is therefore complete only when its identity, variant relationships, Categories, media, pricing context, and external keys describe the same sellable object.
Variants, Options, and Attributes Carry Different Ownership
Size, color, material, package quantity, personalization text, bundle choice, subscription interval, and delivery preference may all appear as “options” in a source export, but they do not necessarily represent the same type of record. Storeden translation should separate a sellable variant from descriptive Product information, Order-line input, application logic, and channel-specific attributes.
The difference matters because a true variant can carry its own SKU, stock, price, image, weight, tax behavior, or marketplace identity. A descriptive attribute may support filtering or Product understanding without creating a separate sellable item. Personalization may belong to the Order line rather than the Product master. Bundle behavior may be calculated by an app or external inventory system.
| Source pattern | Target meaning | Relationship that must remain clear |
|---|---|---|
| Size or color with SKU and stock | Sellable variant | Parent Product, selected values, inventory, price, image, and Order line must point to the same variant. |
| Material or technical property | Descriptive attribute or filter value | Preserve structured meaning without creating false inventory-bearing variants. |
| Personalization text | Buyer input attached to a purchase | Keep the value with the relevant Order line when it must remain historically visible. |
| Bundle or kit | Composite commercial or inventory relationship | Decide whether Storeden, an application, or an external system owns the component logic. |
| Marketplace attribute | Channel taxonomy or listing requirement | Keep it separate from the canonical web-store Product model unless both use the same meaning. |
| ERP-linked code | Cross-system key | Preserve the stable identifier without exposing it as unnecessary storefront content. |
This interpretation prevents a catalog that looks correct visually but no longer identifies the item that is priced, stocked, published, or fulfilled.
Categories, Navigation, and Channel Taxonomies Are Separate Structures
A source Category can act as a catalog parent, menu item, SEO landing page, promotion group, filter rule, reporting segment, or marketplace taxonomy mapping. Storeden should not inherit all of those meanings through one Category record.
| Source structure | Storeden role | Ownership consequence |
|---|---|---|
| Parent-child Category tree | Canonical catalog organization | Product membership and hierarchy remain data relationships. |
| Storefront menu | Navigation presentation | Menu order and labels may reference Categories but are not the Category model itself. |
| Category description and metadata | Landing-page content | Content and SEO meaning remain attached to the appropriate public route. |
| Filter or facet | Discovery logic based on structured values | The underlying attribute must remain consistent across Products. |
| Manual collection or campaign group | Merchandising relationship | It may require curation, rules, or theme presentation rather than a permanent Category. |
| Marketplace Category | Channel-specific taxonomy | Preserve the mapping separately from the web-store Category tree. |
Separating these structures allows the Storeden catalog to support central management while each storefront or marketplace presents Products through its own discovery model.
Inventory Values Need a Declared System of Record
A source quantity can mean physical stock, sellable stock, reserved stock, supplier availability, warehouse stock, channel availability, preorder capacity, or a value synchronized from an ERP. Storeden should receive the inventory value that belongs to its role, together with the identifiers required to keep that value connected to the future system of record.
| Inventory pattern | Meaning | Storeden ownership decision |
|---|---|---|
| One quantity per Product | Simple sellable availability | Storeden may own the value when no other system maintains stock. |
| Quantity per variant or SKU | Availability belongs to the sellable child | Variant identity and stock must remain aligned. |
| ERP or warehouse-managed stock | External operational authority | Storeden may receive synchronized availability while the external system remains authoritative. |
| Marketplace-specific availability | Channel allocation | Keep channel rules distinct from the canonical Product quantity. |
| Bundle stock | Derived from component availability | Preserve component identifiers and the owner of the calculation. |
| Non-stock or service item | Availability is not a physical quantity | Avoid inventing stock relationships that did not exist in the source model. |
The migration boundary should preserve opening quantities where appropriate, but more importantly it should preserve the Product or variant keys that allow future inventory updates to reach the correct record.
Customer and Account Data Carries Multiple Roles
Customer records may represent buyers, account holders, newsletter contacts, company accounts, B2B purchasing contacts, billing recipients, shipping recipients, marketplace customers, CRM records, or TeamSystem-connected identities. Treating all of these as one flat customer list can weaken the target store’s usefulness.
Storeden migration planning should define what customer continuity means for the merchant. Some stores mainly need past order lookup. Others need account access, customer segmentation, B2B relationships, marketing eligibility, invoice references, or integration continuity.
| Customer-related value | Data-model question | Storeden migration concern |
|---|---|---|
| Name and email | Is the customer a real account, buyer record, or contact? | Duplicate or partial records may affect support and marketing use. |
| Billing and shipping addresses | Are addresses complete and tied to the right customer or order? | Staff need addresses for historical order review and customer service. |
| Customer group or segment | Is the value descriptive, pricing-related, or permission-related? | Pricing and access behavior may need target configuration or separate target design. |
| Company or tax data | Is the merchant using B2B or invoice workflows? | Company information may matter for accounting and order history. |
| External IDs | Do CRM, ERP, accounting, or marketing tools rely on the ID? | Preserve or map identifiers when they remain operationally required. |
| Consent and marketing data | Does the source contain legally sensitive preference information? | Do not treat contact migration as permission to reuse marketing records without review. |
A useful Storeden Customer model allows staff to recognize, serve, and segment Customers correctly. Record counts alone do not preserve account, segmentation, B2B, consent, or external-system meaning.
Orders Preserve Historical Commerce Relationships
A Storeden Order is useful when it explains the historical transaction: who purchased, which Product or variant was selected, what quantity and price applied, which discounts and taxes changed the total, how payment and shipping were described, which channel originated the Order, and what status or tracking context followed.
| Historical Order value | Meaning to preserve | Separate target concern |
|---|---|---|
| Product and variant labels | Identity of the purchased item | Current Product structure may evolve without rewriting the historical line. |
| Price, discount, and tax | Commercial snapshot at purchase time | Future pricing, campaigns, and tax rules belong to current configuration. |
| Payment label or transaction reference | Evidence of how the Order was paid | It does not create a live payment connection. |
| Shipping method and tracking | Historical fulfillment context | It does not define current carrier rates or logistics rules. |
| Status and notes | Past operational state | New Order workflows can use different statuses. |
| Marketplace origin | Channel attribution and reporting context | Current listings and synchronization remain separate records. |
This separation keeps Order history readable without pretending that historical labels own future checkout, payment, tax, or fulfillment behavior.
Marketplace and Multichannel Records Form a Parallel Data Layer
Storeden’s multichannel role makes marketplace data a parallel layer rather than a few extra Product fields. Listing identifiers, channel Categories, offer titles, channel prices, availability rules, marketplace attributes, seller references, and Order origins can all relate to the same canonical Product while remaining owned by a specific channel or connector.
| Channel record | Canonical relationship | Ownership boundary |
|---|---|---|
| Listing identifier | Connects a Storeden Product or variant to an external offer | Retain when the future connector or reporting process still uses it. |
| Marketplace Category | Maps the Product to channel taxonomy | Do not merge it into the Storeden storefront Category tree. |
| Channel price | Commercial value for a specific destination | Identify whether Storeden, middleware, or the marketplace publishes the final price. |
| Channel stock | Allocated or synchronized availability | Keep the channel rule separate from physical or canonical stock. |
| Marketplace Order origin | Historical sales-channel context | Preserve on Orders where it supports reporting and service. |
| Feed attribute | Channel-required Product data | Store separately when it does not represent the canonical Product meaning. |
The important relationship is one canonical commercial item to multiple channel representations. Migration should preserve that identity without duplicating every marketplace record as an independent Storeden Product.
Apps, APIs, and TeamSystem Connections Define Record Ownership
Storeden can participate in a broader ecosystem of applications, APIs, accounting, inventory, logistics, marketplace, and TeamSystem-connected workflows. Those connections create records that may appear inside the Store but remain authored elsewhere.
| Record owner | Typical data | Translation rule |
|---|---|---|
| Storeden core commerce | Products, Categories, Customers, Orders | Preserve relationships between supported data types directly in Storeden. |
| Application or connector | Reviews, loyalty data, custom options, feeds, automation state | Determine whether the target application exposes an equivalent record and durable identifier. |
| ERP, accounting, CRM, or warehouse | Product codes, stock authority, Customer keys, invoice references | Keep the cross-system key and do not duplicate the external system’s full model unnecessarily. |
| Marketplace | Listing, offer, taxonomy, and channel status | Preserve only the records needed by the continuing channel workflow. |
| Theme or storefront layer | Layout, blocks, menus, and presentation behavior | Recreate presentation separately from canonical commerce records. |
| API workflow | Import, update, synchronization, or event logic | Treat the workflow as integration design, not as a static migrated field. |
Where the source contains unsupported application tables or proprietary connector data, the migration model should preserve the business meaning and external key only when a defined target owner exists.
Content, URLs, and SEO Data Have Their Own Relationships
Product descriptions, Category copy, pages, Blog Posts, images, metadata, internal links, menus, and redirects may be scattered across the source Store. Storeden should separate content ownership from catalog ownership even when the content appears on a Product or Category route.
| Content or route element | Relationship to commerce data | Target meaning |
|---|---|---|
| Product URL | Public route to a Product | The route can change while Product identity remains stable through internal and external keys. |
| Category URL | Public route to a catalog grouping | Category hierarchy, slug, menu placement, and redirect are related but separate. |
| Metadata | Search description of a public resource | Keep it attached to the correct Product, Category, or page. |
| Rich page content | Editorial or theme-managed presentation | Rebuild through the appropriate content or storefront layer when it is not ordinary catalog text. |
| Images and alt context | Media related to Products or content | Preserve attachment and sequence, not only the files. |
| Internal link | Relationship between public routes | Rewrite when source paths change. |
| Redirect | Continuity rule from an old route | Preserve as routing logic rather than Product content. |
This separation prevents catalog migration from being burdened with theme behavior while still protecting the content and routes that give Products discoverability.
Conclusion
Storeden changes data meaning where a centrally managed Product is represented through variants, Categories, inventory, marketplaces, applications, and external business systems. The same source value may be catalog data, a channel attribute, an Order snapshot, a connector key, or storefront content depending on who owns it and how it is updated.
A coherent Storeden migration model therefore defines one canonical Product identity, preserves variant and Order relationships, declares the inventory system of record, separates web-store Categories from marketplace taxonomies, and retains only the external identifiers needed by continuing integrations. This creates a cleaner multichannel model than copying every source field into the Store without ownership context.
Common Questions
Why is product data more than product import in a Storeden migration?
Product data must support storefront presentation, category placement, inventory confidence, pricing, images, channel readiness, and staff management. A Product record is incomplete when its variants, Category placement, visibility, or marketplace attributes no longer carry the same meaning.
Do migrated orders configure payment and shipping in Storeden?
No. Migrated orders preserve historical payment and shipping information for reference. Future checkout, payment, shipping, logistics, tax, and fulfillment behavior belongs to separate current platform records and operating configuration.
When should marketplace data be reviewed separately?
Marketplace data should be reviewed separately when the source store uses channel-specific listings, prices, categories, attributes, stock rules, order origins, or marketplace identifiers. Those values may not behave like ordinary web-store product fields.
How should custom fields and external IDs be handled?
Custom fields and external IDs should be classified by business use. If they support ERP, accounting, CRM, logistics, marketplace synchronization, or reporting, they may need mapping, structured mapping or dedicated target handling, or separate target design rather than simple field transfer.
Why are record counts insufficient for Storeden data translation?
Record counts do not show whether variants still identify sellable items, inventory belongs to the right system, marketplace records remain linked, Orders retain commercial context, or external identifiers still connect the correct systems. Relationship meaning is the decisive measure.
How should marketplace or channel integrations affect data ownership in Storeden?
Identify which system owns the canonical Product, inventory value, Customer identity, Order status, and external listing ID. Preserve the cross-system keys that remain operational, but do not duplicate integration-generated records as if Storeden were their original source of truth.