When evaluating Storeden as a prospective Target Platform, the migration approach should match the required Next-Cart Migration Service, supported Add-ons where applicable, responsibility level, scope, and validation burden.
Selecting the right Storeden migration approach means matching the service to the actual catalog and connected workflows. Storeden is now branded TeamSystem Commerce. The destination can involve product and variant data, order history, marketplace channels, apps and business-system connections, but the exact supported migration path and actual target setup must be established separately from those native capabilities.
The right approach is not determined by platform name alone. It depends on the shape of the source data, the target Storeden setup, the amount of execution support the merchant wants, and whether the expected result requires supported data migration, optional Add-ons, Custom Migration, or post-migration target configuration.
A Storeden project should be selected through evidence: catalog samples, customer and order examples, marketplace dependencies, app-owned values, TeamSystem or external identifiers, SEO continuity requirements, and Demo Migration results. The decision should be clear enough that everyone understands what Next-Cart is migrating, what Storeden must be configured to handle, and what the merchant or connected providers must prepare outside the migration itself.
For Storeden, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
Storeden Approach Selection Principle
A Storeden migration approach should answer two questions at the same time: how much migration support is needed, and how much customization is required. These are related, but they are not the same.
For the catalog, distinguish the main Product identifier from each child-variant SKU. Variant attributes and images describe a specific choice, while inventory can belong to the main Product or child SKU. An ERP or marketplace reference may identify another record altogether. Scope must say which identity owns the required price, quantity, image and relationship; copying several identifiers into text does not establish the correct selling or integration model.
A merchant may have clean supported data but need included expert-led execution. That points toward Managed Migration. Another merchant may be comfortable with self-managed execution but require custom handling for app data, marketplace identifiers, or external-system references. That points toward Custom Migration. A third merchant may only need supported record filtering, field-value transformation, or field remapping, which may fit an Add-on rather than a custom project.
| Decision factor | What it means for Storeden | Likely service implication |
|---|---|---|
| Supported data structure | Products, Customers, Orders, Categories, Reviews, Coupons, CMS, and SEO values fit supported migration behavior. | Standard Migration or Managed Migration may be sufficient. |
| Execution burden | The merchant needs included expert-led migration execution rather than self-performing key steps. | Managed Migration may be more appropriate than Standard Migration. |
| Add-on need | Eligible records need a data-type-specific condition, a field value needs an expression, or a source field needs a compatible target destination. | Data Filter, Data Transformation, or Advanced Data Mapping may improve the result while staying within supported scope. |
| Custom or unsupported data | App data, marketplace relationships, custom product logic, or external/TeamSystem references need handling beyond eligible compatible supported fields. | Custom Migration review is required. |
| Target configuration dependency | Payments, logistics, themes, apps, channels, or integrations must be configured in Storeden. | This is target setup work and should not be confused with migrated data. |
| Evidence uncertainty | Demo Migration samples do not yet prove that the selected path fits the real store. | Review the approach before approving Full Migration. |
The safest approach is the lightest path that still protects the expected result. Choosing a heavier path without evidence can waste effort. Choosing a lighter path despite unsupported requirements can create launch risk.
When Standard Migration Can Fit Storeden
Standard Migration can fit when the source store has clean supported data, the merchant can prepare the target Storeden store, and the expected result does not depend on custom migration logic. This is most likely when catalog structure is understandable, product options are not unusually complex, orders are needed mainly for historical review, customers and addresses are ordinary, and the merchant can configure Storeden payments, logistics, themes, apps, and marketplace channels separately.
Standard Migration is strongest when the merchant has enough internal clarity to review Demo Migration results, identify errors, and continue with Full Migration once the sample result is acceptable.
| Standard-fit signal | Storeden interpretation | Evidence to confirm |
|---|---|---|
| Catalog data is clean | Products, images, prices, categories, and stock values fit supported target structures. | Product samples display correctly in Storeden. |
| Product options are predictable | Variants or options do not require bespoke transformation. | Variant products retain SKU, price, stock, and image meaning. |
| Customer data is ordinary | Customers, addresses, and order links do not depend on unusual account logic. | Representative customer histories remain understandable. |
| Orders are historical records | Past orders are needed for service and finance review, not to rebuild live checkout rules. | Order samples show products, totals, payment labels, shipping labels, and status meaning. |
| Storeden setup is owned separately | Theme, payment, shipping, logistics, apps, marketplaces, and integrations will be configured in the target store. | Migration acceptance is not tied to unfinished configuration work. |
Standard Migration should not be selected simply because the store is small. A smaller store with app-owned data, custom product behavior, or external identifiers may still need Custom Migration. A larger store with clean supported structures may remain standard if the merchant can manage preparation and review.
When Managed Migration Is a Better Fit
Managed Migration is appropriate when the data can remain within supported migration capability, but the project needs included expert-led migration execution. The need is operational assistance, not necessarily customization.
This can be valuable for Storeden projects where the merchant has a meaningful catalog, customer/order history, SEO concerns, or launch timeline, but does not want to manage each migration step independently. Managed Migration can help reduce execution burden while keeping the migration within supported structures.
| Managed-fit signal | Why it matters | What still remains outside migration |
|---|---|---|
| The merchant wants expert execution | Agreed Migration Actions are performed by specialists on request; the customer retains manual access and verification. | Target Storeden settings still need merchant or platform-side configuration. |
| Data is supported but review workload is high | Product, customer, order, and SEO samples require organized review. | Business decisions about scope, exclusions, and target setup remain the merchant’s responsibility. |
| Launch timing needs coordination | The merchant assigns the review and launch schedule; expert execution follows the agreed migration request. | Live payment, logistics, app, channel, and integration readiness still need separate confirmation. |
| Internal team capacity is limited | The merchant may not have time to manage each migration step alone. | Custom requirements still require Custom Migration if they go beyond supported behavior. |
Managed Migration includes expert execution of supported Migration Actions; sample interpretation, business review, launch coordination and final approval remain assigned separately. It does not expand capability. Test eligible compatible supported mapping for custom fields and identifiers first; unsupported app extraction, marketplace relationships, external-system logic or transformation beyond Standard Add-on scope require Custom Migration review.
Where Add-ons Can Help
Add-ons help when the data remains within supported migration behavior but needs more control. For Storeden, they are most relevant when the merchant wants to filter records through field-based conditions for each data type, transform field values through expressions, or remap source fields to compatible target fields.
Storeden does not support Advanced Database Mapping as Target. Supported values can still use eligible compatible Advanced Data Mapping destinations. Source database access or a TeamSystem connection does not remove the Target gate.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| Add-on | Storeden use case | Boundary to keep clear |
|---|---|---|
| Data Filter | Apply supported Product, Customer, Order, CMS Page, or Blog Post field conditions so only matching records migrate. | Estimated entity numbers are not filters; each condition must be explicit. |
| Data Transformation | Apply expressions to transform supported labels, names, statuses, or other field values during migration. | Expressions do not create custom app migration or unsupported logic. |
| Advanced Data Mapping | Remap supported source fields to compatible Storeden target fields. | Mapping must preserve field meaning and stay within supported platform capability. |
Add-ons are useful when the merchant can clearly describe the data type condition, transformation expression, or source and destination fields. If the Add-on itself needs modification beyond available behavior, the requirement moves into Custom Migration because customized handling is required.
When Custom Migration Is Required
Custom Migration is required when the expected Storeden result needs handling beyond supported migration and Standard Add-ons: unsupported app data, custom-field interpretation, Custom Platform extraction, marketplace relationships, bespoke transformations or external-system logic. An external or TeamSystem identifier alone is not enough to make the migration custom if an eligible compatible supported field can retain its required meaning.
Storeden projects can require Custom Migration when the business depends on data that is not ordinary catalog, customer, order, category, content, or SEO migration output. This is especially important when the previous store used apps, ERP connections, marketplace feeds, B2B logic, bespoke checkout behavior, custom order metadata, or integration IDs that staff still need after launch.
| Custom Migration signal | Storeden example | Why Standard Migration or Add-ons may not be enough |
|---|---|---|
| App-owned data carries business meaning | App fields control promotions, customer groups, marketplace listings, or fulfillment context. | Standard migration may not include unsupported app data. |
| External identifiers require non-standard handling | ERP, accounting, warehouse, POS, CRM, or TeamSystem-related IDs are required after launch. | First test eligible compatible supported fields and expressions. Custom work is needed when extraction, relationships or required behavior exceed those capabilities. |
| Product behavior is bespoke | Bundles, configurable products, nonstandard variants, custom fields, or channel-specific attributes affect selling. | The data may not fit ordinary product/variant structures. |
| Marketplace values need special handling | Marketplace IDs, channel categories, listing statuses, or origin references must be preserved. | Channel data may differ from standard storefront catalog data. |
| Orders contain custom operational metadata | Payment references, logistics IDs, fulfillment notes, tax labels, or external references require special interpretation. | Historical order import may not preserve the expected operational context without custom work. |
| Custom Platform source is involved | The source system is bespoke or lacks predictable export structure. | Custom interpretation is needed before migration rules can be applied. |
Custom Migration defines the tailored scope. Self-Execute keeps the agreed Migration Actions with the customer; Expert Handle includes expert execution when accepted. Neither execution choice automatically covers marketplace activation, ERP coordination or the merchant’s final verification.
Custom Migration does not automatically include app installation, marketplace setup, payment or shipping configuration, theme implementation, TeamSystem integration deployment, or complete Storeden reconstruction unless expressly agreed.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Storeden scope.
Entity Points and Migration Scope Impact
Entity Points measure eligible record volume rather than Storeden complexity. Products, Customers, Orders and Blog Posts consume their locked capacity on their first successful migration within the same purchased migration and fixed Source-to-Target path. Categories, CMS Pages, Reviews, Coupons, variants, marketplace references, app data and identifiers can affect scope without becoming separate counted Data Types.
For later Storeden activity, previously counted eligible records remain counted once within the same purchased migration and fixed Source-to-Target path; marketplace, logistics, app, and business-system complexity is assessed separately. Newly eligible Product, Customer, Order, and Blog Posts records may consume Entity Points when they are migrated for the first time.
| Scope signal | What Entity Points indicate | What still needs separate evaluation |
|---|---|---|
| Large Product catalog | Counted Product volume | Variants, marketplace mappings, inventory ownership, images, and custom attributes |
| Large Customer base | Counted Customer volume | B2B roles, consent, duplicate identities, CRM references, and app-owned fields |
| Extensive Order history | Counted Order volume | Payment, tax, fulfillment, marketplace, and external-system context |
| Blog content | Counted Blog Posts volume | CMS Pages, landing pages, SEO paths, media, and theme reconstruction |
Entity Points should support plan-capacity decisions, while Demo Migration and scope review determine whether Storeden-specific structures require Add-ons, Custom Migration, target configuration, or accepted exclusions.
Migration Actions and Later Migration Actions
Migration Actions should be selected according to what changed after the earlier migration activity: only the data, the supported configuration, or the complete project basis.
| Current action | Storeden use case | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | New eligible records were created while the approved scope and configuration remain suitable. | Check newly migrated Products, Customers, Orders, and Blog Posts plus representative regression samples. |
| Continue the Migration with a New Configuration | Supported filtering, mapping, data type selection, or configuration must change. | Revalidate every affected Product, variant, Customer, Order, content, marketplace, and external-reference field. |
| Perform a New Migration | The target plan or intended Storeden result has materially changed enough that the previous migrated output should no longer remain the working basis, while the purchased Source Platform-to-Target Platform path remains unchanged. | Validate the refreshed target result and confirm that the previous migrated output is no longer treated as authoritative. |
These actions do not rebuild themes, configure live payments and shipping, reconnect marketplaces, deploy apps, or restore TeamSystem and external-system integrations automatically. Those responsibilities must remain explicit in the final scope.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path and actual Store identities fixed. A different Source Platform, Target Platform, actual Source Store or actual Target Store requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Demo Migration as the Approach Checkpoint
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Storeden approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
| Demo sample | What it should prove | What failure suggests |
|---|---|---|
| Variant product | Options, SKU, stock, price, and images remain meaningful. | Mapping or Custom Migration review may be needed. |
| Marketplace-sensitive product | Inspect standard supported references where available; channel reconstruction or tailored listing relationships need separate paid proof and target setup. | Marketplace data may need separate handling. |
| Customer with order history | Account details, addresses, and order links are understandable. | Customer/order relationship review is needed. |
| B2B or company-related customer | Inspect supported standard company or group context where available; enhanced fields and live B2B rules need separate proof. | B2B logic may require Custom Migration or target setup. |
| Complex order | Products, discounts, taxes, payment labels, shipping labels, and fulfillment context remain readable. | Order-history meaning may require mapping or custom review. |
| External-system record | Inspect supported standard references where available; Add-on routing or tailored ERP, warehouse or TeamSystem output needs agreed paid proof. | Integration-dependent data may require Custom Migration. |
| Priority URL or content page | SEO and content continuity can be evaluated. | Redirect, CMS, or manual content planning may be incomplete. |
Use the limited Demo result to confirm supported standard assumptions and diagnose missing scope. If marketplace relationships, app dependencies, external IDs or stock identity remain unresolved, qualify their supported destination or tailored handling before broader execution. Enhanced or Custom Migration output must pass agreed paid proof, while live channels and integrations require separate target checks.
Warning Signs the Approach Is Too Light
A Storeden approach may be too light when it focuses on record movement while ignoring operational dependencies. This is most common when merchants assume the target platform will recreate old workflows automatically.
Common warning signs include:
- marketplace products or orders matter, but channel identifiers are not included in scope review;
- TeamSystem, ERP, accounting, warehouse, CRM, POS, or API references are operationally important but not sampled;
- apps or plug-ins control pricing, customer groups, fulfillment, marketing, or reporting;
- product options, attributes, filters, or stock rules are treated as plain text;
- B2B behavior is expected without confirming account, price, tax, or approval logic;
- orders are accepted without checking payment, shipping, fulfillment, refund, tax, or logistics context;
- live checkout, payment providers, logistics, marketplaces, and apps are confused with migrated history;
- SEO review is delayed until after launch;
- Demo Migration samples include only easy records.
When these signs appear, the project should not proceed to Full Migration without approach review. The next step may be better Demo Migration sampling, Add-on configuration, Custom Migration review, or a clearer separation between migration scope and Storeden setup.
Conclusion
The right Storeden migration approach starts with supported Product and child-SKU meaning, then assigns execution. Standard Migration fits customer-led supported work; Managed Migration includes expert execution of agreed supported actions. Add-ons provide bounded filtering, expressions and field routing. Custom Migration covers requirements beyond those capabilities, with Self-Execute or Expert Handle stated explicitly. Marketplace and TeamSystem references should be judged by their required relationship and supported destination, not their name alone.
Demo is an early check of limited supported standard output. Marketplace, app and external-system examples also inform scope review, but enhanced or tailored results need agreed paid proof. The selected path should account for live channel and integration setup separately before Full Migration is approved.
Common Questions
Is Standard Migration enough for a Storeden migration?
Standard Migration can be enough when the selected Storeden path supports the required Product, variant, Customer, Order and other agreed records and the merchant can execute and verify the migration. Supported mapping may preserve a compatible identifier without Custom Migration. Unsupported extraction, app relationships or bespoke logic need tailored scope; target setup remains separately owned.
When should Managed Migration be selected instead for a Storeden migration?
Managed Migration is useful when the data fits supported migration capability but the project needs included expert-led execution. It helps with process burden, but it does not replace Custom Migration when customization is required.
How do Add-ons differ from Custom Migration for Storeden?
Add-ons support bounded filtering, value expressions and compatible field routing. Storeden does not support Advanced Database Mapping as Target. Required app extraction, unsupported relationships, Custom Platform interpretation or logic beyond those boundaries needs Custom Migration. External identifiers can remain standard when an eligible compatible supported destination is sufficient.
What should Demo Migration prove for Storeden before Full Migration?
Demo examines limited standard samples available in the active path, such as main Product versus child-SKU meaning and readable Customer or Order relationships. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Validate enhanced marketplace references or tailored external-system data through paid activity and check live integrations separately.
Which Migration Action should be used for Storeden?
After an earlier paid migration, reuse the last saved configuration only while the accepted Product, variant, marketplace and external-reference assumptions remain valid. Use Continue the Migration with a New Configuration when supported settings change, or Perform a New Migration for a new result on the same purchased path and actual Store identities. The first paid run also uses that new action. Choose newly added records or applicable previous-state continuation separately, and review combined output without assuming protected target data is erased.
Does every Storeden marketplace or external identifier require Custom Migration?
No. First identify what the reference means and whether an eligible compatible supported field can preserve it. A readable ERP ID can differ from a channel listing relationship that drives synchronization. Unsupported extraction, relationships or bespoke logic require Custom Migration; live marketplace and business-system connections still need target setup.
Does a Product CSV cover the whole Storeden project?
No. Selecting CSV, XLS or XML as Source Platform requires Custom Migration, whose included standard file workflow covers Products only. Customer, Order and other required Data Types must be agreed explicitly. A supported platform’s File Upload method is different. Product data does not establish marketplace activation, apps or TeamSystem integration readiness.