For a move into Phoca Cart, distinguish purchase attributes and options from descriptive specifications, then identify the stock method used by the chosen target. Joomla content, access and presentation add separate responsibilities. These meanings define the Next-Cart scope before customer-led or expert-led execution is selected.
Selecting the right migration approach for Phoca Cart requires separating commerce records from the Joomla environment that gives those records operational meaning. Phoca Cart can manage Products, Categories, Manufacturers, attributes, options, specifications, stock, Customers, Customer groups, Orders, Coupons, rewards, currencies, languages, taxes, invoices, payment methods, shipping methods, and point-of-sale activity. It is also modular: plugins, modules, templates, content integrations, access levels, and custom code can change how a particular store behaves.
Supported commerce records can use Standard Migration with customer-led execution or Managed Migration with expert execution of agreed Migration Actions. Eligible Add-ons provide defined data controls. Required handling beyond supported capability needs Custom Migration review, while Joomla, POS and extension implementation keep their own owners.
For Phoca Cart, 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.
Start With the Phoca Cart and Joomla Scope
Phoca Cart is a Joomla e-commerce extension rather than an isolated storefront application. A migration plan should therefore identify which requirements belong to core commerce records, which belong to Joomla content and site structure, which belong to Phoca Cart configuration, and which are created by plugins or custom development.
Phoca Cart attributes can define purchase choices and affect selling values or variations; specifications describe comparison information. Its stock methods distinguish Main Product, Product Variations and Advanced Stock Management, with combination behavior depending on attribute configuration. Identify the actual stock grain rather than treating every option label or specification as an independent sellable unit. Native capability does not establish migration coverage.
| Scope layer | Typical examples | Service-path implication |
|---|---|---|
| Core commerce data | Products, Categories, Manufacturers, Customers, Orders, Coupons, Reviews, images | May fit Standard or Managed Migration when supported and structurally clear |
| Product behavior | Attributes, options, specifications, downloads, stock, related Products, group prices | Requires supported representation, limited standard Demo evidence and separate paid or target-side proof where needed |
| Joomla context | Users, access levels, menus, aliases, modules, languages, content and URLs | Must be separated into migratable data, target configuration, and site implementation |
| Extension layer | Payment and shipping plugins, POS, rewards, newsletters, PDF tools, custom modules | May require Custom Migration or separate target implementation |
| Operational configuration | Tax, currency, language, payment, shipping, invoice, status, template settings | Not recreated automatically by historical record migration |
A store with a small catalog can still require a demanding service path when custom Joomla fields, Product options, Customer groups, plugins, or external integrations are essential. A larger store can remain suitable for Standard Migration when records are conventional and the customer can validate the result independently.
When Standard Migration May Be Enough
Standard Migration is appropriate when the migration path is supported and the required data fits standard behavior. Under this Next-Cart service, the customer is responsible for configuration choices, migration execution, and validation.
A strong Standard Migration candidate generally has:
- clear Products, Categories, Manufacturers, Customers, Orders, and supported content;
- understandable attributes, options, and specifications;
- consistent Product identifiers and image relationships;
- ordinary Customer groups and addresses;
- readable historical Orders without hidden plugin-owned meaning;
- a defined language and currency scope;
- limited custom fields and extension data;
- no assumption that Joomla templates, modules, plugins, or live checkout settings will be rebuilt through migration;
- a team able to evaluate Demo Migration and Full Migration results.
Standard Migration should be selected because the data is supported and the customer can manage the work, not because the store appears visually simple. Phoca Cart can hide substantial meaning behind Product options, Customer group prices, reward rules, payment plugins, shipping plugins, and multilingual configuration.
When Managed Migration Is a Better Fit
Managed Migration fits supported Phoca Cart scope when experts should execute the agreed Migration Actions. It uses the same supported capability as Standard Migration. The customer supplies stock, attribute, Joomla and historical-record meaning, retains manual access and verifies the final result.
Managed Migration can be the better fit when:
- the merchant cannot confidently operate the migration independently;
- several languages, currencies, Customer groups, or Product structures require coordinated review;
- large Product or Order volume creates a significant validation workload;
- agreed migration-action timing requires expert execution, with wider scheduling and issue management separately scoped;
- customer business owners, Joomla administrators and implementation partners have assigned acceptance areas alongside expert execution;
- the source data is supported but inconsistent enough to need disciplined review;
- Expert Handle is required as part of the agreed service.
Managed Migration changes execution ownership, not support for required records. Custom Migration handles tailored extraction or transformation when supported capability is insufficient and can use Self-Execute or Expert Handle. Wider validation services, Joomla coordination and launch management must be expressly included if needed.
Where Add-ons Fit
Add-ons are useful when the main migration remains supported but a bounded change is needed. They can apply per-Data-Type record filtering, expression-based field-value transformation, supported standard field remapping, or eligible database-column remapping without treating the entire Phoca Cart project as custom.
Examples include:
- applying supported Product, Customer, Order, or content field conditions through Data Filter;
- applying expressions to transform supported field values through Data Transformation;
- remapping supported standard source fields to compatible supported target fields with the value unchanged through Advanced Data Mapping;
- mapping supported source database columns to compatible Phoca Cart database columns with the values unchanged through Advanced Database Mapping, provided that the selected Source setup supports Advanced Database Mapping and the requested schema locations are compatible;
- handling selected SEO or content outputs where supported;
- validating the filtered record sets, transformed values, and remapped fields against defined expectations.
Add-ons address defined supported operations. Compatible standard-field or eligible database-column mapping can preserve a source or already transformed value without changing it during mapping. Unsupported extraction of reward or POS records, bespoke attribute interpretation and application behavior need tailored scope or separately owned implementation. Native feature names alone do not settle support.
Phoca Cart supports Advanced Database Mapping as Target. Its availability also requires an eligible exact Source setup and supported, compatible data type, table, field, column and Value Type. Tax is excluded. Neither database placement nor a matching specification field recreates Joomla access, template output, live stock calculation or extension behavior.
The boundary is whether the requirement remains inside supported migration behavior. If it does, an Add-on may be enough. If it requires tailored interpretation, custom logic, or unsupported data, Custom Migration is the correct path.
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.
When Custom Migration Is Needed
Custom Migration should be reviewed when required handling exceeds supported capability. Separate native Phoca Cart records from Joomla or plugin-owned records, then check supported destinations. A POS, reward, custom-field or external-ID label alone does not prove the need for tailored work; unsupported extraction, bespoke interpretation or migration logic does.
Common escalation signals include:
- custom Product fields, attributes, options, or specifications stored outside standard structures;
- Customer-group, reward or price requirements needing unsupported records or bespoke interpretation;
- required POS records or external inventory references whose handling exceeds supported scope;
- payment, shipping, invoice, or tax data stored in plugin tables;
- custom Joomla users, access relationships, menu logic, or multilingual associations;
- custom modules, template overrides, or content integrations that store business-critical records;
- external ERP, accounting, fulfilment, newsletter, marketplace, or CRM identifiers;
- bespoke transformation between source fields and the Target Platform;
- a Custom Platform on either side of the migration path;
- requirements that change standard migration logic.
Custom Migration does not automatically include Joomla upgrades, Phoca Cart installation, extension or plugin development, template reconstruction, POS implementation, payment and shipping configuration, external integration deployment, or a complete Target Store build. Those responsibilities must be explicitly included in the agreed scope.
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 Phoca Cart scope.
How Entity Points Affect Planning
Eligible Products, Customers, Orders and Blog Posts consume Entity Points on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Joomla, specification, stock-method and plugin complexity is assessed separately. Categories, Manufacturers, Reviews, Coupons, attributes, options, Customer groups, rewards and CMS Pages do not become independent counted record types.
Already counted eligible records do not consume Entity Points again merely because another action occurs. Define actual Product identity and new record scope; a specification, option label or plugin dependency does not by itself establish another counted record.
This distinction keeps volume and complexity separate:
| Planning condition | Entity Points effect | Service-path effect |
|---|---|---|
| Many ordinary Products | Requires suitable capacity | May still fit Standard Migration |
| Few Products with custom options or plugin data | Lower volume | May require Custom Migration |
| New Orders created before launch | May consume Entity Points when first migrated | Requires follow-up validation |
| Existing records migrated again on the same path | No duplicate consumption merely because another action occurs | Configuration still needs to remain valid |
Entity Points should be planned before Full Migration, but they should never be used as proof that custom Joomla or Phoca Cart structures are supported.
What Demo Migration Should Prove
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Phoca Cart 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.
Use the following contexts to identify available standard sample checks and separate proof needs:
- simple Products and Products with attributes, options, specifications, or downloads;
- Products using group prices, rewards, stock controls, or multilingual values;
- Customers from different groups and access contexts;
- available standard Orders with discount context, tax, payment, shipping and history; Coupon records and additional invoice handling need separate paid proof where required;
- priority CMS Pages, Blog Posts, menus, aliases, and URLs;
- dependency contexts affected by plugins, modules, POS or external systems, with enhanced or tailored output proved in agreed paid scope;
- examples from each language, currency, or storefront context that matters.
Demo can reveal whether available standard data preserves usable meaning or exposes a gap. Classify each gap using the following ownership choices:
- supported target configuration;
- bounded Add-on requirement;
- Custom Migration requirement;
- separate Joomla or Phoca Cart implementation responsibility.
Enhanced output and live storefront, access, POS and stock behavior need their own paid or target-side acceptance.
A project should not proceed to Full Migration while assuming that higher volume will resolve a structural gap already visible in the sample.
Migration Actions for Phoca Cart
Select the action from the paid migration state and whether the accepted configuration remains valid. Either continuation needs an earlier paid migration; Demo findings instead shape the first paid configuration. Choose the source-data window separately and accept combined output after supported configuration changes.
| Current action | Appropriate situation | Phoca Cart revalidation focus |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid; choose the source-data window independently. | New Products, Customers, Orders, Blog Posts, attributes, options, language values, URLs, and integration identifiers. |
| Continue the Migration with a New Configuration | The same migration path remains correct, but supported filters, mappings, or destination settings need to change. | Product structures, Customer groups, Order statuses, content selection, language scope, URLs, and exclusions. |
| Perform a New Migration | Run the first paid migration or create a distinct result on the same purchased path; define the target effect explicitly. | Full commerce, Joomla, content, plugin, SEO, and acceptance scope. |
These actions do not install plugins, rebuild templates, configure payment or shipping, implement POS, or deploy external integrations automatically. They operate within the agreed Migration Service scope and do not change the fixed purchased Source Platform-to-Target Platform path. A different platform path requires a separate purchased Migration Service.
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 fixed. A different Source Platform or Target Platform 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.
Separate Migrated Records From Phoca Cart Implementation
Phoca Cart combines data, Joomla context, and operational configuration. The migration approach should identify which layer owns each expected outcome before cost and responsibility are agreed.
| Expected outcome | Primary ownership | Service-path implication |
|---|---|---|
| Supported Products, Customers, Orders, Blog Posts, and related records | Migration Service | Evaluate support, mapping, Entity Points, and acceptance criteria. |
| Categories, Manufacturers, attributes, options, specifications, and content relationships | Migration plus target validation | Confirm how supported relationships are represented and which target settings remain necessary. |
| Tax, currency, payment, shipping, invoice, status, and POS operation | Phoca Cart configuration and providers | Historical values can support reference, but live behavior must be configured and tested separately. |
| Joomla menus, modules, languages, access levels, aliases, and templates | Site implementation | Coordinate with migration outputs without assuming complete site reconstruction. |
| Plugins and custom extensions | Extension or development owner | Identify data that needs Custom Migration and behavior that must be reimplemented separately. |
| External accounting, fulfilment, newsletter, CRM, or marketplace systems | Integration owner | Preserve agreed identifiers and redeploy connections outside ordinary migration execution. |
This separation protects the merchant from treating a target-configuration gap as a data defect. It also prevents extension-owned data from being dismissed as implementation when it genuinely must be extracted or transformed through Custom Migration. Demo Migration findings should be classified against this ownership map before the service path is finalized.
Use Practical Scenarios to Select the Service Path
Scenario 1: Standard catalog and historical records. Products use ordinary attributes and options, Customers and Orders are readable, and the target team will configure Phoca Cart. Standard Migration may be enough when Demo Migration confirms the difficult samples.
Scenario 2: Supported but operationally demanding project. Several languages, Customer groups and a large Order history can increase execution workload. Managed Migration may fit when experts should perform the agreed supported Migration Actions. Customer reviewers own acceptance; wider validation, scheduling and launch management require explicit agreement.
Scenario 3: Defined filtering or field-remapping requirement. The merchant needs inactive Products excluded through Product-field conditions, selected Orders excluded through Order-field conditions, or supported standard source fields remapped to compatible supported target fields while keeping their values unchanged. Data Filter or Advanced Data Mapping may address the requirement without Custom Migration. An eligible database-column mapping may instead use Advanced Database Mapping, provided that the selected Source setup supports Advanced Database Mapping and the requested schema locations are compatible.
Scenario 4: Reward, POS or plugin requirements beyond supported scope. Confirm whether required records are native, supported or extension-owned. Unsupported extraction or bespoke interpretation needs Custom Migration review; an eligible compatible field map may fit an Add-on. Installing plugins, configuring POS and live checkout remain separately owned unless expressly included.
Scenario 5: Configuration changes after Demo Migration. Product options, language scope, Customer groups, or content selection need supported adjustment. Apply those findings when preparing the first paid configuration. If a paid migration has already produced an earlier result that remains useful, Continue the Migration with a New Configuration can support intentional changes on the same purchased path. A Demo configuration alone is not a paid configuration to continue.
Scenario 6: A distinct migrated result is required on the same purchased path. Use Perform a New Migration for the first paid run or a distinct result. Define target effects without assuming protected data is erased, then verify agreed scope and customer acceptance. A different Source or Target Platform requires a separate purchased Migration Service.
Each scenario should be supported by representative records and a documented expected result. This makes the final service choice defensible and prevents the platform's broad feature set from becoming a vague reason to over-scope or under-scope the project.
Final Phoca Cart Service-Path Decision
| Evidence | Likely service path |
|---|---|
| Supported records, clear Product structures, ordinary Joomla context, customer-led operation | Standard Migration |
| Supported scope whose agreed Migration Actions need expert execution | Managed Migration |
| Bounded supported record filtering, field-value transformation, supported field remapping, or eligible database-column remapping needs when the selected Source setup supports Advanced Database Mapping and the requested database locations are compatible | Standard or Managed Migration with Add-ons |
| Unsupported plugin records, fields requiring bespoke interpretation, tailored transformations, POS or external references beyond supported scope, or custom Joomla logic | Custom Migration, potentially with Expert Handle and agreed Add-ons |
The decision should be confirmed before Full Migration and tested through Demo Migration. The correct approach preserves the business meaning of Phoca Cart records without implying that the entire Joomla site and extension environment are part of standard data migration. The approved plan should identify the service, Add-ons, Custom Migration requirements, Entity Points Plan, validation owners, target configuration, extension work, and any later paid migration activity that may be needed. This keeps launch responsibility visible and prevents unresolved plugin or Joomla work from being mistaken for an accepted migration result.
Conclusion
Choose the Phoca Cart approach from attribute and specification meaning, the active stock method, required Joomla context and data ownership. Standard Migration is supported customer-led execution; Managed Migration provides expert execution of agreed actions. Eligible Add-ons refine supported output, while Custom Migration handles tailored scope with Self-Execute or Expert Handle.
Use limited standard Demo evidence to expose gaps and agreed paid proof for enhanced or custom output. Keep Joomla access, presentation, live stock and POS acceptance separately owned. Later actions depend on the applicable paid state, an independent source window and verification of combined earlier and later output.
Common Questions
Can Standard Migration be enough for Phoca Cart?
Yes. It can be enough when the migration path is supported, core records are clear, Product structures are recognizable, and the customer can operate and validate the service independently.
When should Managed Migration be selected for a Phoca Cart migration?
Managed Migration fits supported scope when experts should perform the agreed Migration Actions. The customer retains manual access and final verification. Wider Joomla coordination, validation services and launch scheduling must be explicitly included if needed.
Do Add-ons migrate Phoca Cart plugins?
Add-ons provide supported filtering, transformation or compatible mapping; they do not install or reproduce plugin behavior. Required native POS or reward records are not automatically custom. Determine exact support first, then review unsupported extraction, bespoke interpretation or migration logic for Custom Migration and assign implementation separately.
What should Demo Migration prove for Phoca Cart?
Demo examines a limited available standard sample and can reveal gaps around Product choices, Customers, Orders and content. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Enhanced output, extension-linked records, multilingual presentation, Joomla access and live stock or POS behavior need separate paid or target-side proof.
Which Migration Action fits a Phoca Cart follow-up?
Either continuation needs an earlier paid migration. Keep a valid paid configuration or choose a new one for intentional supported changes; the first paid run or a distinct result uses Perform a New Migration. Choose the source-data window separately, verify combined output and define target effects without assuming protected data is erased.
Do Phoca Cart specifications and purchase attributes need the same treatment?
No. Specifications describe comparison information; attributes can affect purchase choices, selling values or variations. Select the destination from the required meaning and confirm supported handling. A readable copied value does not by itself implement filtering, purchasing or Joomla presentation.
Does a Phoca Cart option always have its own stock?
No. Resolve the active Main Product, Product Variations or Advanced Stock Management method and the relevant attribute configuration. Define whether quantity belongs to the main Product, a variation or a combination. Confirm supported data handling and separately verify live stock calculation and purchasing behavior.