Preparing for Storeden requires a reconciled account and channel model, not just a Product file. The evidence must show which catalog combinations, translated labels, stock values, and external keys belong to the actual Storeden or TeamSystem Commerce operation.
Storeden is now presented by TeamSystem as TeamSystem Commerce, while existing accounts and internal business documentation may still use the Storeden name. Preparation should record both names where they appear so the team does not treat the current account, historic exports, marketplace references, or integration documentation as unrelated systems.
Confirm the actual account's export coverage, enabled integrations, historical records, and custom behavior before defining the migration scope. Collect source exports, screenshots, administrator records, integration notes, and named owners for each required area. Establish the available records and relationships from the selected account and workflow evidence rather than inferring them from a platform name or general feature description.
Confirm the Account, Current Naming, and Selling Scope
Identify the actual Source Store separately from the intended Storeden or TeamSystem Commerce account. Record domains, active languages and currencies, plan, roles, enabled modules, theme ownership, sales channels, and TeamSystem or outside-system connections needed at the destination. Record which name appears in the administrator, invoices, API or integration records, and staff procedures. Branding alone does not prove that an integration is connected or that its records are included.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm the source account | Store administrator | Account identifier, administrator screenshot, primary domain | The exact source Store is unambiguous. |
| Record Storeden and TeamSystem Commerce naming | Project owner | Naming cross-reference for account, exports, integrations, and documentation | Historic and current references can be reconciled. |
| List active selling channels | Commerce owner | Website, marketplace, social, B2B, or other channel inventory | Channel-specific records have named owners. |
| Identify TeamSystem ecosystem connections | Systems owner | ERP, accounting, payments, POS, logistics, or other integration notes | Native ecosystem dependencies are visible. |
| Confirm source evidence access | Data or technical owner | Available exports, reports, credentials, support contact | Required records can be collected from the actual account. |
| Start a change log | Project owner | Dated catalog, stock, Customer, Order, app, and URL changes | The evidence set will remain current. |
Prepare Products, Variants, Catalog Fields, and Media
Check whether the chosen Product extraction contains only a basic listing or the fuller details and optional fields needed for the catalog. Prepare the catalog from the actual source account and chosen extraction scope, including selected fields, filters, pages, and related definitions. A short Product list may omit required variant, attribute, image, language, or stock evidence without proving those records are absent.
Record Product identifier, SKU or internal code, title, status, price, tax context, stock, variant or option structure, Categories, brand or manufacturer, images, descriptions, language content, shipping data, marketplace fields, external identifiers, and custom fields visible in the account or exports.
| Product pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Simple Product | Capture identifiers, price, stock, status, Category, media, and content | Product export and page sample | Baseline Product meaning is documented. |
| Variant Product | Record option names, values, combination identifiers, price, stock, image, and status | Variant export or administrator screenshots | Sellable combinations are distinguishable from the parent Product. |
| Channel-specific Product | Record marketplace or channel identifiers, titles, Categories, prices, and availability rules | Channel listing sample | Website and channel data are not conflated. |
| Multilingual Product | Record language ownership, translated fields, route differences, and fallback behavior | Language sample set | Content scope is explicit for each language. |
| Custom or app-enriched Product | Identify fields created by plugins, apps, or integrations | Field dictionary and source owner | Non-core Product data has a disposition. |
| Media-heavy Product | Record original images, documents, videos, and file locations | Media manifest | Original assets can be matched to records. |
Do not infer variant or marketplace behavior from Product names alone. Preserve variant definitions, value codes, translated labels, and their actual Product assignments separately from sellable combination keys, SKUs, price semantics, quantity, images, and status. A translated label is display evidence, not a new combination identity. Use actual account examples to establish whether a price is a full amount or an adjustment and which record owns stock or channel availability.
Prepare Categories, Navigation, Languages, and Discovery
Prepare the Category hierarchy, Product assignments, navigation menus, brand or collection paths, language versions, filters or attributes used for discovery, landing pages, and priority URLs. Multichannel catalog classification should be documented separately from website navigation because a marketplace Category or feed label may not represent the Store's own Category structure.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Category hierarchy | Catalog owner | Parent-child list, status, Product assignments | Every retained Category has a known purpose. |
| Menus and storefront paths | Storefront owner | Navigation map and screenshots | Presentation paths are separated from Category records. |
| Language scope | Content owner | Active languages and translated Product, Category, and page samples | Required localized content is identified. |
| Filters and attributes | Merchandising owner | Field names, values, Product coverage | Discovery data is consistent enough to map. |
| Channel classification | Marketplace owner | Channel Category, feed, and listing samples | External classification is kept separate from website taxonomy. |
| Priority routes | SEO owner | Product, Category, page, brand, and campaign URLs | Important paths have a documented disposition. |
Clarify Inventory Authority and Channel Synchronization
Inventory values may be maintained directly in the commerce account or synchronized from a TeamSystem application, ERP, warehouse, POS, supplier feed, or marketplace workflow. Preparation must identify the authoritative source and the timing of updates. A quantity in an export is only a snapshot unless the stock owner is known.
| Inventory question | Evidence | Ready condition |
|---|---|---|
| Where is authoritative stock maintained? | System list, owner, screenshots, integration note | One source of truth is named for each Product group. |
| Is stock tracked by Product or variant? | Representative Product and variant records | Granularity is documented. |
| Are several locations or warehouses involved? | Location list and allocation examples | Location meaning is explicit. |
| Do marketplaces reserve or synchronize stock? | Channel rules and sample listings | Channel availability is not assumed to equal website stock. |
| Are bundles or component Products used? | Component and stock-decrement evidence | Shared stock relationships are documented. |
| Are negative, preorder, or backorder states used? | Exception Product list | Availability exceptions have owners. |
Capture each stock export's timestamp, Product or combination key, quantity meaning, unlimited or tracking state where used, and channel or location context. Keep opening stock, reservations, pending obligations, and historical movements distinct. Avoid bulk cleanup while source authority is unclear, and document approved consolidation rather than adding website and marketplace quantities that may represent the same pool.
Prepare Customers, Addresses, Segmentation, and B2B Context
Prepare Customer identity, email, account state, addresses, language, consent or communication status, group or segmentation fields, B2B or company context, tax treatment, loyalty or credit data where present, and external identifiers. Use the current account and integrations to determine which fields are native, app-owned, or synchronized. Confirm authentication for the exact Source-to-Storeden path, including verification, supported reset or activation handling, first-login expectations, and Customer communications; a Customer export does not establish password or SSO portability.
| Customer pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Registered Customer | Record identity, account state, addresses, and Order relationship | Customer and Order samples | Account ownership is clear. |
| Guest buyer | Record email and historical Orders without assuming an account | Guest Order set | Guest history remains distinct. |
| B2B or company buyer | Record company, contacts, pricing or tax context, and account owner | B2B sample register | Business relationships are documented. |
| Segmented Customer | Record group, tag, loyalty, or marketing meaning and owner | Segmentation dictionary | Labels have operational definitions. |
| External-system Customer | Record ERP, CRM, accounting, POS, or support identifiers | Field dictionary | Downstream lookup keys are known. |
| Duplicate identity | Record duplicate or shared emails and disposition | Identity exception list | Ambiguous records have an owner. |
Prepare Orders, Payments, Shipping, Logistics, and Channel References
Prepare Orders that represent the Store's real operating patterns: website and marketplace sales, different payment and shipping labels, variant Products, discounts, refunds, cancellations, returns, invoices, tracking, manual adjustments, multilingual details, B2B cases, and external references.
| Order area | Action | Evidence | Ready condition |
|---|---|---|---|
| Channel ownership | Record website or marketplace source and channel identifier | Cross-channel Order samples | Each Order can be tied to its origin. |
| Product detail | Include variant or option selections, SKU, quantity, price, and Product text | Representative Order lines | Purchased configuration remains understandable. |
| Status and logistics | Record status labels, shipment state, tracking, returns, and operational notes | Status dictionary and Orders | Historical workflow can be interpreted. |
| Totals | Identify tax, shipping, discount, fee, refund, and payment amounts | Total-component samples | Financial context is complete. |
| Documents | Record invoice, receipt, or fiscal-document references where used | Document examples and owner | Required historical references are traceable. |
| External IDs | Record ERP, accounting, payment, logistics, marketplace, or POS identifiers | Integration-sensitive Orders | Cross-system lookup requirements are documented. |
Historical payment and shipping labels are evidence of past Orders. Preserve original line text, selected combinations, channel, status codes and labels, prices, taxes, discounts, refunds, dates, and document references. Live payment, checkout, tax, shipping, and logistics settings require separate setup in the new Store. Prepare how history imports will avoid new stock changes, payment or fiscal-document actions, fulfillment, Customer emails, and TeamSystem or other integration events.
Inventory Apps, Plugins, TeamSystem Connections, and External Systems
Create a dependency register for apps, plugins, marketplaces, payment services, logistics providers, accounting, ERP, POS, CRM, analytics, marketing, reviews, feeds, and custom integrations. Storeden's transition into the TeamSystem ecosystem makes it especially important to identify integrations that staff may describe as part of Storeden even though they are managed in another TeamSystem product.
| Dependency field | Required detail | Ready condition |
|---|---|---|
| Product or service name | Current and historic name where different | The dependency can be identified by all teams. |
| Owner and purpose | Business owner, technical owner, workflow supported | Responsibility is explicit. |
| Data objects | Products, stock, Customers, Orders, invoices, content, or channels used | Affected source evidence is known. |
| Direction and timing | Read, write, two-way, scheduled, event-driven, or manual | Source authority is documented. |
| Identifiers | SKU, Product ID, Customer email, Order number, external key | Lookup dependencies are preserved. |
| Transition decision | Reconnect, rebuild, retire, replace, or review | Continuity is not assumed. |
Prepare Content, Themes, SEO Routes, and Redirect Evidence
Confirm how themes, multilingual content, and SEO settings are used in the actual account and which content records and fields the available exports include. Prepare pages, Product and Category content, blog or editorial content where used, images, menus, theme sections, metadata, canonical settings, hreflang or language relationships, internal links, and rewrite or redirect records.
| Content area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Pages and policies | Content owner | Page list, status, route, language, internal links | Retain, rebuild, merge, or exclude decisions are documented. |
| Theme content | Theme owner | Theme backup or screenshots, custom sections, embedded assets | Content stored in presentation layers is visible. |
| SEO metadata | SEO owner | Titles, descriptions, canonical settings, language relationships | Search context is included with the route evidence. |
| Redirects or rewrite URLs | SEO or technical owner | Existing redirect list and priority old routes | Historic continuity rules are available. |
| Media | Content owner | Original images, documents, videos, and Product links | Source files can be matched to records. |
Prepare Exports, Screenshots, Backups, and Source Limitations
Create a recoverable evidence archive for the actual Source Store. Save each available export with its date, actual account context, selected fields, filter criteria, covered pages or related datasets, and checksum. Protect credentials and archives, retain original identifiers and field names with a recovery owner, and log approved normalization separately. Screenshots or support evidence should explain required relationships that the selected export or API scope does not carry.
| Evidence set | Required contents | Ready condition |
|---|---|---|
| Core exports | Product, Customer, Order, Category, stock, content, and channel files where available | Files are dated and attributable. |
| Screenshots and reports | Variants, apps, integrations, settings, languages, redirects, and exceptions | Non-exported relationships are visible. |
| Media and theme archive | Original assets and available theme backup or code record | Source files are recoverable. |
| Support record | Named account contact and unresolved export questions | Evidence gaps have owners. |
| Change log | New and edited Products, stock, Customers, Orders, channels, and URLs | Later source changes can be reconciled. |
Do not fill an evidence gap with an unsupported assumption. Record the affected scope, alternative evidence, and person responsible for confirming the account behavior. Resolve required gaps, exclude them with approval, or hold readiness; an assigned support question is not proof that the input is ready.
Select Representative Migration Test Records
| Sample group | Include | Preparation purpose |
|---|---|---|
| Products | Simple Product, variant Product, multilingual Product, channel-listed Product, low-stock exception, app-enriched Product | Expose distinct catalog and ownership patterns. |
| Customers | Registered, guest, B2B, segmented, duplicate identity, external-ID Customer | Represent account and integration differences. |
| Orders | Website, marketplace, refund, return, different logistics state, invoice reference, external-system Order | Preserve operational context. |
| Discovery and content | Priority Category, language route, landing page, Product URL, redirect | Prepare route and content relationships. |
| Dependencies | Product, Customer, or Order touched by a TeamSystem or outside integration | Include cross-system identifiers in the evidence. |
Each sample should include original identifiers, values, related files, channel and language context, and a source expectation explaining why the record is representative. State the intended Storeden or external representation, approved exclusions, affected relationships, and responsible reviewer. Include a translated variant definition and its actual sellable combinations where used so the packet establishes their different roles before testing.
Complete the Storeden Readiness Gate
| Final gate | Ready condition |
|---|---|
| Account identity | Storeden and TeamSystem Commerce naming, account, domains, channels, and owners are reconciled. |
| Catalog | Products, variants, Categories, languages, media, and custom fields are documented. |
| Inventory | Stock authority, granularity, locations, channels, and exceptions are known. |
| Customers | Registered, guest, B2B, segmented, duplicate, and external-ID cases are understood. |
| Orders | Channel, Product selections, statuses, logistics, totals, documents, and external IDs are interpretable. |
| Dependencies | Apps, plugins, TeamSystem connections, marketplaces, and outside systems have dispositions. |
| Content | Themes, pages, media, SEO fields, language routes, and redirects are prepared. |
| Inputs | Exports, screenshots, media, support contacts, and change log are recoverable; required limitations are resolved, excluded with approval, or held. |
| Samples | Representative migration records cover ordinary and complex source patterns. |
Conclusion
Storeden preparation should reconcile the historic platform name with its current TeamSystem Commerce context while relying on evidence from the actual account. Catalog, inventory, channels, Customers, Orders, content, apps, and TeamSystem connections must be documented by owners who understand their operational use.
A complete evidence archive combines source exports, account records, and integration evidence. It preserves source identities and commercial meaning, names recovery and review owners, and resolves required gaps or holds them before execution. That gives migration configuration a dependable basis without assuming that a Product listing, translated label, or TeamSystem name proves complete delivery scope.
Common Questions
Why does the checklist mention TeamSystem Commerce when the platform title is Storeden?
TeamSystem now presents Storeden as TeamSystem Commerce. Existing accounts, exports, integrations, and staff procedures may use either name, so preparation should record the relationship explicitly.
What should be done when a Storeden field is not covered by current public documentation?
Confirm the field through the actual account, exports, screenshots, integration owners, and support contacts. Record the field's original name, value, parent record, consumer, and unresolved behavior. Resolve required evidence gaps, exclude them with approval, or hold readiness instead of guessing.
Which Storeden Products should be sampled?
Include simple and variant Products, multilingual Products, marketplace-listed Products, inventory exceptions, media-heavy Products, and records enriched by apps or external systems.
How should multichannel stock be prepared?
Identify the authoritative stock system, Product or combination granularity, locations, quantity or unlimited meaning, reservation and synchronization rules, timestamps, and channel identifiers. Keep one shared stock pool distinct from channel-specific values and prepare opening stock separately from pending obligations.
What Order records are most useful for preparation?
Use website and marketplace Orders, refunds, returns, different logistics states, invoice or fiscal-document references, and Orders connected to TeamSystem or other systems.
How should source changes after export be controlled?
Maintain a dated log covering Products, stock, Customers, Orders, channels, apps, and URLs so the migration evidence can be reconciled with the current Store state.
Does a basic Product list prove complete catalog coverage?
No. A basic listing can contain less detail than the catalog requires. Record the actual selected fields, filters, covered pages, related definitions, and sample contents for the chosen extraction. Missing data in a short response may be outside that extraction scope rather than absent from the Store.
Do translated variant labels identify the sellable combinations?
No. Preserve the variant definitions, value codes, translated labels, and Product assignments separately from combination keys and their SKU, price, quantity, image, and status evidence. Translations explain display meaning; the actual combination relationship identifies the sellable unit.