An engraving input and an independently stocked shirt size need different migration evidence. The first may need its entered text and price adjustment preserved; the second also needs a reliable sellable identity and inventory relationship. Calling both an “option” does not settle their treatment in EShop.
Use those requirements to decide what Next-Cart needs to transfer, which supported controls apply and who will execute the work. Keep any required Joomla or plugin implementation under its own agreed scope.
What the Right EShop Approach Must Decide
The Joomla extension by Ossolution Team appears as eShop in the current platform selection. Confirm the actual Source, intended compatible Target build and included records through the EShop migration overview.
| Decision area | What to evaluate | Why it matters for EShop |
|---|---|---|
| Supported data fit | Products, Categories, Manufacturers, Customers, Orders, Reviews, Coupons, options, attributes and related records, fields and relationships in the selected path. | Confirm actual supported scope and compatible destinations. A supported record type does not establish every field or relationship. |
| Execution ownership | Whether the customer can perform the agreed Migration Actions or needs expert execution. | Standard and Managed Migration share supported capability. A large ordinary catalog can remain standard scope while benefiting from expert execution. |
| Bounded Add-on controls | Actual record conditions, value operations, field routing or database-level mapping needed. | Choose available Standard Add-ons for defined requirements; processing order, schema and path eligibility matter. |
| Nonstandard handling | Unsupported extraction, schema, relationships, extension data or bespoke interpretation. | Assess the unresolved gap through Custom Migration. A custom field or external identifier alone does not establish that need. |
| Target implementation | Joomla menus, modules, templates, URLs, languages, plugins, checkout, tax, emails and notifications. | Assign named implementation owners. These tasks are included only when explicitly agreed, separately from historical record transfer. |
Purchase options, descriptive attributes, custom field definitions, public attachments and purchased Downloads serve different purposes. Establish the required selection, price, identifier, image and stock effects in the installed model; a SKU component alone does not prove independent combination stock. Before choosing execution ownership, identify the supported destination for each item and how the storefront, staff or an integration will use it.
The preparation checklist supplies concrete records for that assessment; the risk analysis explains the relationships a broad field list can miss.
When Standard Migration Can Fit EShop
Standard Migration can fit a merchant team able to run the Next-Cart workflow and validate supported Products, Categories, Manufacturers, Customers, Orders, Reviews, Coupons and common catalog fields. The Source structure needs to be clear enough for those records to move without bespoke interpretation.
For EShop, Standard Migration fit depends on distinguishing options from attributes and inventory rules. Options collect purchase choices or inputs; a text or file input is not automatically an inventory-tracked variant. Attributes describe specifications used for comparison. Product quantity, stock-checkout policy and any option-related inventory must be identified in the actual installation. Choose supported destinations from those meanings rather than treating all catalog fields as interchangeable.
| Case | Meaning | Check |
|---|---|---|
| Clean catalog records | Products, categories, manufacturers, images, descriptions, prices, and stock values are consistent. | Product pages can be reviewed without heavy data cleanup or interpretation. |
| Understandable product options | Source choices such as size, color, package, or format have clear meaning. | Purchase inputs should retain their intended meaning and readable Order-line output. |
| Clear attributes and specifications | Technical values are descriptive rather than purchase-controlling. | Attribute or custom-field placement can be reviewed without custom logic. |
| Ordinary customer and order history | Customers, addresses, order lines, statuses, coupons, vouchers, tax, shipping, and payment labels are readable. | Historical data remains useful for service and reporting. |
| Merchant-led validation is realistic | The team can review samples, compare records, and manage configuration follow-up. | Standard execution does not remove the need for target review. |
Store size alone is a poor basis for this choice. Confirm clear Source data, a suitable destination structure and no essential unsupported custom behavior.
EShop also distinguishes Product Attachments offered on the public Product page from files assigned as purchased Downloads. Preserving a file path does not establish the required buyer entitlement.
Customer Groups can affect Product visibility and commercial rules; matching a group label alone is insufficient.
Assign supported record handling, target configuration and any tailored access requirement separately.
When Managed Migration Fits the Work
Managed Migration is appropriate when EShop scope fits supported capability but experts should perform the agreed Migration Actions. A large catalog, multilingual content or detailed Order history may increase execution workload. The customer still defines option, inventory, file-access and business acceptance requirements and verifies the result.
Managed Migration does not automatically solve custom data or unsupported logic. It improves execution ownership when the migration path is otherwise suitable. If the project needs bespoke interpretation, custom-field transformation beyond supported Data Transformation scope, unsupported extension handling, or custom migration logic adjustment, Custom Migration should be reviewed instead.
| Case | Reason | Boundary |
|---|---|---|
| Large product catalog | A greater execution workload after the customer defines samples, relationships and acceptance. | Large volume alone does not mean custom handling is required. |
| Detailed order history | Orders may include options, vouchers, coupons, tax, shipping, payment labels, comments, and status history. | Historical readability still depends on available source and target fields. |
| Multilingual storefront | Customer owners define language and route expectations; experts execute agreed supported migration actions. | Joomla language setup may require target implementation beyond migration. |
| Launch pressure | The merchant needs expert execution within an agreed migration window. | Target configuration and business approval still need merchant participation. |
| Multiple internal owners | Marketing, operations, support, finance, and technical teams may validate different records. | Managed execution does not replace ownership of business decisions. |
Agree the expert-executed actions and assign internal approvals separately. Wider launch management, Joomla implementation, plugin setup and bespoke data interpretation are included only when expressly agreed; unsupported requirements need Custom Migration review.
Where Add-ons Support EShop Migration
Standard Add-ons address bounded needs available in the active migration. Establish the required operation and supported field or destination before selecting one. Several supported Add-ons can work together without automatically requiring Custom Migration.
Supported controls and processing order
| Add-on | Possible EShop need | Qualification |
|---|---|---|
| Data Filter | Exclude archived Products, test Orders, old Customers or inactive records through approved conditions. | The field and condition must be available for that data type. Capacity quantities do not select records. |
| Data Transformation | Change supported labels, statuses or other source values through an available operation or expression. | The operation must express the intended change; it does not recreate arbitrary source business logic. |
| Advanced Data Mapping | Route a source or already transformed value to a compatible supported EShop field. | Mapping routes the value unchanged. It does not create unsupported field structures or behavior. |
| Advanced Database Mapping | Route eligible values through supported database-level fields or columns. | eShop is eligible separately as Source and Target. The actual Source setup, record type, schema/table, field/column and Value Type must also be compatible and supported. |
Processing follows Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping. Filtering selects records, transformation changes supported values, and mapping routes the resulting values unchanged. Review earlier-stage output before defining later rules.
Scope boundaries beyond supported controls
Check whether the actual Source-to-eShop path supports the required tax-related records, fields and compatible destinations. Historical Order tax and live tax configuration remain separate requirements. A stored value also needs the intended EShop, Joomla or integration consumer.
For optional fields or records, state which filtering, transformation or compatible mapping operation is needed. Generic preservation is not itself an Add-on operation. To reduce launch noise, Data Filter can exclude archived Products, test Orders or inactive records where approved conditions are supported; the business must agree those exclusions before execution.
A Tailored Add-on modifies Standard Add-on behavior; a Custom Add-on supplies bespoke logic. Both require Custom Migration review. Assess only the portion that supported controls cannot express.
Consult the Add-ons decision guide for the shared concepts. Operational field and schema qualification belongs in Add-on documentation. The database-mapping eligibility reference identifies the supported Source and Target roles; the requested destination still needs its own compatibility check.
When Custom Migration Should Be Reviewed
Custom Migration should be reviewed when the EShop migration depends on data or behavior that cannot be handled safely through standard migration capability and available Add-ons. Possible triggers include Custom Platform data, unsupported extraction or extension records, schema and relationship gaps, bespoke interpretation, Tailored Add-ons, Custom Add-ons and custom migration logic. First check whether supported fields and controls can express the requirement; plugin ownership, a custom field or an external key alone does not settle that question.
Evidence for nonstandard data
A source store may depend on extensions, template overrides, modules, custom tables or external systems. Investigate what those dependencies do before deciding whether standard handling is sufficient.
| Case | Gap | Evidence |
|---|---|---|
| Custom checkout fields with business rules | Field display, validation, email output, invoice output, or order meaning may be bespoke. | Field list, sample orders, screenshots, and target expectations. |
| Unsupported extension data | Records may not belong to standard product, customer, order, or category structures. | Extension names, database samples, export examples, and ownership notes. |
| Plugin-owned payment or shipping behavior | Historical labels may migrate, but live behavior may depend on plugins or custom code. | Plugin list, method examples, order samples, and future behavior requirements. |
| Integration identifiers | ERP, accounting, CRM, fulfillment, inventory, or affiliate identifiers may need preservation. | Source field list, sample values, destination expectation, and integration owner. |
| Custom product fields or tabs with operational meaning | Values may affect fulfillment, compliance, selection, or reporting. | Product examples and business explanation for each field. |
| Tailored or Custom Add-on work | A Standard Add-on needs project-specific modification, or bespoke Add-on functionality is required. | Reviewed and quoted through Custom Migration, with the required output and acceptance criteria defined explicitly. |
Custom Migration should be discussed early when the source store includes hidden dependencies. Waiting until after Demo Migration can make the review harder because the sample may already be missing the records that explain the real requirement.
Execution and implementation boundaries
Joomla template work, extension installation, payment or shipping plugin configuration, and site redesign are not automatically included 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 EShop scope.
How Demo Migration Should Test the Approach
Optional Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed EShop 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.
Available sample evidence
Use ordinary records and risk-bearing contexts to define the evidence needed: Product options, attributes, Manufacturers, purchased Downloads, public Attachments, custom fields, Customer Groups, Order discounts, tax, shipping and payment history, multilingual content and extension dependencies. Include only available standard records in Demo. Coupon records are excluded, and file entitlement, custom behavior and target presentation need separate agreed proof where they exceed standard sample coverage.
| Case | Review | Decision |
|---|---|---|
| Product options | Available supported purchase inputs and Order-line meaning; identify price, identifier, image and inventory implications without assuming every option controls them. | Whether standard handling preserves shopper choice. |
| Attributes and product fields | Specifications, custom fields whose required handling exceeds supported mapping scope, tabs, attachments, and extra product information. | Whether a supported destination fits, or Add-on/custom output needs paid proof; public Attachments and purchased Downloads have different acceptance needs. |
| Customers and groups | Customer identity, addresses, Joomla user relationship, customer groups, and account history. | Whether customer continuity is understandable. |
| Orders and commercial history | Order lines, statuses, coupons, vouchers, tax, shipping, payment labels, comments, and custom fields. | Whether available standard history is useful; Demo excludes Coupon records and does not prove custom checkout output. |
| Joomla presentation | Menus, aliases, modules, templates, multilingual pages, metadata, and SEO-sensitive paths. | Whether target implementation responsibilities are separate from migration scope. |
| Custom or unsupported data | Third-party identifiers, plugin-owned records, bespoke fields, and old extension data. | Whether Custom Migration should be reviewed before proceeding. |
Proof beyond the Demo result
Use the limited Demo result to choose supported execution, a specific Add-on, tailored scope or a target-implementation task. Managed Migration is an execution choice, not a broader data capability. A clean standard sample does not prove Add-on output, custom checkout handling or the complete storefront; agree the required paid and target-side proof, then resolve it before accepting the affected output.
Entity Points and EShop Scope Planning
Entity Points provide capacity for eligible Products, Customers, Orders and Blog Posts. Eligible records count on their first successful migration and remain counted once within the same purchased migration, fixed Source-to-Target path and applicable actual-store context. A Product with all of its variations counts as one Product for Entity Points.
Plan previously counted records separately from eligible records first transferred during later activity, including records from newly included eligible data types. A repeated action or distinct later result does not by itself reset usage. Categories, Manufacturers, Reviews, Coupons, Joomla users, options, attributes, fields and plugin data can affect scope without becoming additional counted types.
| Planning question | EShop implication |
|---|---|
| How many eligible records are expected? | Size capacity for eligible Products, Customers, Orders and Blog Posts. A Product with all of its variations counts as one Product. |
| Which records were already counted? | Records counted on their first successful migration remain counted once within the same purchased migration, fixed Source-to-Target path and applicable actual-store context; another action alone does not count them again. |
| Which eligible records have not yet been counted? | Plan capacity for eligible records first successfully transferred during later activity, including newly included eligible data types. A distinct later result does not itself reset usage. |
| How complex are Products and their relationships? | Options, attributes, public Attachments, purchased Downloads and custom fields affect supportability, mapping and validation. They do not become extra independently counted types. |
| Which extensions or external systems remain involved? | Confirm supported destinations, continuing consumers and any required Custom Migration or separate Joomla implementation, even when counted volume is modest. |
Capacity and selection are separate. Use the Entity Points reference for current counting rules, and supported selection and filtering to define which records move. Complex options, download entitlements, external keys and Joomla dependencies require support and implementation decisions; a larger Entity Points Plan does not establish that capability. Confirm current eligibility and purchase requirements when actual stores, platform selections or direction change.
Migration Actions for EShop
Choose how the next activity relates to the paid configuration, then decide its actual records and processing behavior independently.
Action and configuration decisions
| Action | Configuration decision | Revalidation consequence |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Reuse an earlier paid configuration after confirming it remains suitable. | Check actually processed records and affected options, stock, Categories, Manufacturers, images, buyer links, paid files and priority paths. |
| Continue the Migration with a New Configuration | Review supported changes to selection, filters, mapping or other configuration. | Recheck changed rules and their effect on earlier and later output and every required consumer. |
| Perform a New Migration | Start the first paid run or a fresh migration cycle under the applicable purchased setup. | Establish fresh evidence for the intended result and protected Target changes; do not infer automatic clearing. |
Every Migration Action stays within the fixed purchased Source Platform-to-Target Platform path. A different platform path or reverse direction requires a separate purchased Migration.
Either continuation action requires an earlier paid migration; Demo alone does not establish that paid configuration. An action does not itself select an additional-data window, resume an interrupted execution, clear Target data or create new capacity.
Carried state and affected records
The Additional Option Continue the previous migration carries the most recent migration state. For selected supported data types, records not transferred in that state form the later delta, while supported relationships can use the carried context. This is not a creation-date-only rule or a general edit-sync mechanism, and it is unavailable in Demo.
When existing Source Products, options, Customers, Orders, refunds, coupons or linked content change, confirm the intended update behavior through actual selection, options and agreed handling. Revalidate combined earlier and later output, including protected Target edits. Clearing remains a separate explicit decision; active-execution recovery has its own controls.
These actions do not implement live payment, shipping, tax, emails, Joomla pages or unsupported behavior. Use Migration Actions and Additional Options for the current distinctions. Confirm actual store identity, platform eligibility and purchase requirements when the setup changes.
Compare the Three Migration Services and the Add-on Layer
Standard, Managed and Custom are the three Migration Services; Add-ons apply separately to eligible bounded needs. Compare supported scope, execution responsibility and interpretation required. Choose the least complex combination that covers the required outcome and can be validated.
| Decision layer | Best fit | Main boundary |
|---|---|---|
| Standard Migration | Clean supported records and confident customer-led execution and validation | Does not perform Joomla implementation or unsupported-data handling |
| Managed Migration | Supported migration whose agreed actions need expert execution | Does not convert custom extension data into standard scope |
| Add-ons | Bounded record filtering, field-value transformation, or field remapping requirements | Does not replace Custom Migration or target development |
| Custom Migration | Unsupported extension data; custom fields or external IDs whose required handling exceeds supported controls; bespoke transformation or migration logic | Final scope and price depend on the agreed custom work |
The comparison should be applied after the EShop evidence is understood. Choosing a more involved service path cannot compensate for an undefined target representation, missing extension ownership, or an acceptance standard that no reviewer can apply.
Use the service comparison after the required outcome and its owners are clear.
Signs the Chosen Approach Is Too Light
An EShop approach is too light when the migration plan assumes that the target extension will automatically reproduce behavior that actually depends on custom source logic, target configuration, Joomla implementation, or unsupported records. The warning signs usually appear during preparation or Demo Migration review.
| Case | Cause | Response |
|---|---|---|
| Products appear but buying choices are incomplete | Options, variant values, or custom product selections were not interpreted correctly. | Review whether a supported source field needs Advanced Data Mapping or whether the source behavior requires Custom Migration. |
| Attributes become confusing or misplaced | Specifications, filters, custom fields, and checkout choices may be mixed together. | Reclassify fields before final execution. |
| Orders exist but are not useful for support | Order lines, option values, totals, statuses, payment context, shipping context, or comments lack meaning. | Expand order samples and review field handling. |
| Customer groups lose business purpose | Group assignment may affect pricing, tax, access, reporting, or customer service. | Confirm group meaning and target configuration. |
| Live checkout is expected to work automatically | Payment, shipping, tax, email, and checkout behavior need target setup and testing. | Assign target-side configuration ownership. |
| Joomla presentation is ignored | Menus, modules, templates, aliases, metadata, and redirects may not be ready. | Separate migration validation from Joomla implementation work. |
| Custom fields are treated as ordinary records | Field meaning may depend on old apps, extensions, plugins, or custom code. | Test supported mapping first; review Custom Migration only when the required interpretation or handling exceeds that scope. |
Match the response to the demonstrated gap. Better preparation, a more representative Demo sample, Managed Migration or supported Add-ons may be enough. Review Custom Migration for nonstandard migration data or logic, and keep Joomla or plugin implementation separately owned. Settle that classification before relying on the result for launch.
Conclusion
Agree the required EShop outputs before choosing the service: purchase choices, descriptive information, stock policy, Customer Group treatment and file access. The scope should distinguish supported transfer, any bounded Add-on rules, approved nonstandard handling, who executes the Migration Actions and separately agreed Joomla or plugin implementation.
Use optional Demo for the available standard sample, paid proof for enhancements or tailored output, and implementation evidence for the required consumers. Later activity needs an explicit configuration decision, actual processing scope and revalidation of affected earlier and later relationships.
Carry the agreed requirements into EShop validation priorities.
Common Questions
What evidence should be prepared for Custom Migration review in an EShop migration?
Prepare actual Source examples for the required fields, extension records, purchase choices and buyer or Order relationships. State their business purpose, intended destination, continuing consumer, owner and pass condition. Check supported controls first, then assess any unresolved nonstandard handling through Custom Migration.
When is Managed Migration better for EShop?
Choose Managed Migration when experts should perform the agreed Migration Actions within supported capability. The customer supplies option, stock, file, group and language requirements, retains manual access and verifies the result. Wider coordination, launch management and Joomla setup must be included explicitly if required.
Do Add-ons replace Custom Migration?
Standard Add-ons can handle available filtering, transformation and compatible routing. They do not replace approved nonstandard handling. A custom field alone does not force Custom Migration, but an unsupported relationship or bespoke operation can require it. Tailored Add-ons and Custom Add-ons belong to Custom Migration.
What should Demo Migration test before choosing the final approach?
Examine the available standard Products, options, attributes, Customers and Orders. Demo is optional and reduced; Add-ons and Customization are unavailable, and Reviews and Coupon records are excluded. Enhanced output, purchased-file access, multilingual presentation and plugins need agreed paid or implementation proof when outside that sample.
Can live payment, shipping, and tax behavior be migrated automatically?
Historical payment, shipping and tax references can explain old Orders. Future checkout requires the intended EShop configuration, compatible plugins and tests. Importing history does not recreate credentials, rates, eligibility, notifications or live payment behavior.
Should EShop options and attributes use the same migration treatment?
No. Options collect purchase choices or inputs; attributes describe comparison information. Establish any required price, identifier, image or stock effect in the actual setup. Select supported transfer, configuration or tailored handling from that purpose, rather than from a shared field label.
Does migrating an EShop attachment preserve purchased-download access?
No. A public Product attachment and purchased Download serve different access purposes. Prove the correct file, Product and qualifying buyer/Order relationship, including denial of unrelated access. Stored data alone does not implement a required permission or extension consumer.