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.
Detailed current operational documentation is not consistently available through a public help center. The preparation package should therefore rely on evidence from the actual source account: exports, screenshots, administrator records, integration notes, and named owners. Avoid assuming exact field behavior, limits, or export coverage from old articles or marketing descriptions.
Confirm the Account, Current Naming, and Selling Scope
Begin by identifying the exact Storeden or TeamSystem Commerce account, primary domains, active languages and currencies, current plan or enabled modules where relevant, theme ownership, sales channels, and TeamSystem or outside-system connections. Record which name appears in the administrator, invoices, API or integration records, and staff procedures.
| 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
TeamSystem Commerce publicly describes centralized catalog and inventory management, Product images and descriptions, pricing, and multichannel distribution. The source account should be inspected to determine the exact Product fields and variant relationships in use. Prepare Products by business pattern rather than assuming one common schema.
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. Use actual account evidence to show which values change stock, price, images, 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 the time of each stock export and avoid bulk cleanup while source authority is still unclear.
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.
| 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. Live payment, checkout, tax, shipping, and logistics settings require separate setup in the new Store.
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
TeamSystem Commerce publicly describes customizable themes, multilingual commerce, and SEO capabilities. The exact content model and available exports should be confirmed in the actual account. 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
Because public operational documentation is limited, the evidence archive should be unusually explicit. Save every available export with its date, account context, selected fields, filter criteria, and checksum. Capture screenshots for relationships not represented in exports, and record any fields or objects that cannot be exported without administrator or support assistance.
| 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 limitation and the person responsible for confirming the current account behavior.
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 a source expectation that describes why the record is representative, which relationships matter, and which evidence must accompany it.
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, limitations, and change log are available. |
| 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 makes source limitations visible instead of replacing them with assumptions. That gives migration configuration a dependable basis even when public field-level documentation is limited.
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?
Use evidence from the actual account, exports, screenshots, integration owners, and support contacts. Record unresolved behavior as a source limitation rather than 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 variant granularity, locations, reservation or synchronization rules, and channel-specific identifiers.
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.