Next-Cart

Phoca Cart preparation must distinguish the many structures that can appear beside a Product. Attributes can create variations and affect price, specifications can support comparison, parameters can support filtering, customer groups can change prices and storefront access, downloadable files can depend on Order relationships, and Joomla menus, languages, modules, templates, and access levels control how the Store is reached.

The preparation package should define an action, owner, evidence artifact, and ready condition for every material area. It should preserve source meaning through sample selection, backups, inventories, relationship maps, and explicit readiness decisions.

Secure Joomla, Phoca Cart, Hosting, and File Access

Confirm access to Joomla administration, Phoca Cart administration, hosting, database, filesystem, Product images, downloadable and uploadable files, scheduled processes, and external services. Record Joomla and Phoca Cart versions, PHP and database environment, languages, template, access levels, enabled modules/plugins, payment and shipping methods, and custom code.

Preparation action Owner Evidence Ready condition
Confirm administrative access Joomla/Phoca Cart administrator Working accounts and role summary Products, attributes, Customers, Orders, modules, and configuration are inspectable.
Create recoverable backups Infrastructure owner Database export, filesystem archive, protected download/upload directories, and restoration owner The source can be restored without relying on the live Store.
Record environment and extensions Technical owner Joomla, Phoca Cart, PHP, database, template, module, plugin, and language inventory Version- and extension-dependent records are documented.
Capture customizations Development owner Template overrides, custom fields, custom SQL, source edits, and bespoke plugins Every customization that reads or writes commerce records has an owner.
Map connected systems Integration owners Feed, ERP, CRM, POS, accounting, payment, shipping, and marketplace endpoints and IDs Continuing systems and authoritative values are known.

Preserve Products, Categories, manufacturers, attribute, specification, parameter, Customer, customer-group, Order, Order-line, status, reward-point, review, form-field, feed, and external IDs where they are needed to reconstruct relationships.

Prepare Products, Categories, Manufacturers, Images, and Stock

Phoca Cart Products can include identifiers, descriptions, Categories, manufacturers, images, video, prices, taxes, stock, dimensions, reward points, downloads, tags, labels, language associations, metadata, related Products, and external keys. Prepare records according to selling behavior and operational importance.

Product pattern Evidence to prepare Ready condition
Simple Product Product ID, SKU/EAN/MPN, price, tax, stock, Category, manufacturer, media, and sample Order One record clearly identifies the item sold.
Attribute-based Product Attribute definitions, options, combinations, price effects, stock calculation, images, and Order sample Each purchasable variation and its option values are traceable.
Downloadable Product Product file, attribute-option files, path, expiry, download count, and completed Order Protected file ownership and Order-based access are documented.
Multi-Category Product Product-to-Category links, priority route, and language scope Discovery relationships are preserved without Product duplication.
Reward-point Product Points required/earned, Product link, Customer history, and governing rules Reward relationships are separated from ordinary price data.
POS or submitted Product POS/source context, submitter, status, identifiers, and related Product record Non-standard creation paths have an explicit owner.

Record publication state, catalogue-only behavior, stock status, minimum and multiple quantities, external IDs, feed fields, and language associations. A blank quantity, unlimited stock state, and out-of-stock Product must not be treated as the same condition.

Separate Attributes, Specifications, Parameters, Tags, and Custom Fields

Phoca Cart distinguishes several Product information systems. Attributes can create variations and affect price. Specifications support comparison and filtering without changing price. Parameters provide another filtering structure. Tags and labels primarily support visual or classification behavior. Additional Product fields can carry identifiers, feed values, media, dimensions, and external references.

Structure Evidence Ready condition
Attribute and option Attribute type, required/default state, option values, combination behavior, price effect, image, stock, and Product assignments Buyable choices are not flattened into descriptive fields.
Specification Specification group/value, Product links, comparison/filter use, and language Descriptive comparison data remains separate from variants.
Parameter Parameter/value, Product assignments, search/filter use, and routes Filter relationships are documented without inventing price effects.
Tag or label Type, value, display purpose, Product assignments, and language Visual labels are not confused with core Product Categories.
Additional Product field Field name, business meaning, value type, external consumer, and Product key Operational and integration values have a named owner.

Create a normalized vocabulary only after preserving the source definitions and assignments. Similar labels can represent different behavior, and one Product family may use attributes where another uses specifications.

Prepare Prices, Customer Groups, Taxes, Discounts, and Reward Points

Phoca Cart can associate Products with customer-group prices, control price and add-to-cart visibility by group, apply Product or cart discounts, use multiple taxes and currencies, and maintain reward-point records. Prepare these as relationships rather than isolated numeric fields.

Commercial area Evidence to prepare Ready condition
Product prices Product/variation ID, customer group, currency, amount, date or condition, and source owner Each price is attached to the correct Product and buyer context.
Customer groups Group definition, assigned Customers, visibility settings, price behavior, and automation rule Group meaning is documented beyond its label.
Taxes Tax rate/class, country/region/zone scope, Product/category assignments, and historical Order examples Tax configuration is separated from historical tax amounts.
Discounts and coupons Rule type, Products/Categories, quantity/amount thresholds, group, dates, and historical use Active rules and historical evidence are distinguishable.
Reward points Customer, Product, points earned/spent, balance, and transaction context Loyalty history has a named destination or retained owner.
Stock Product/variation, quantity, calculation method, minimum/multiple quantity, location/POS owner, and external key The authoritative sellable quantity is known.

If an ERP, POS, marketplace, or supplier feed owns price or stock, document the opening values separately from the system that will continue to maintain them.

Prepare Customers, Joomla Users, Forms, Reviews, and Addresses

Customer preparation should connect Joomla users, Phoca Cart Customers, customer groups, billing and shipping addresses, custom form fields, loyalty identifiers, reward points, reviews, newsletter state, and external CRM or accounting keys.

Account area Evidence Ready condition
Registered Customer Joomla user ID, Customer ID, email, status, group, addresses, loyalty number, and external IDs Duplicate and cross-system identities have an intended treatment.
Guest Customer Order-level name, email, billing/shipping values, and Order references Guest history is preserved without inventing an account.
Checkout form field Field definition, type, required/display rules, access level, customer group, and stored values Custom Customer data is not lost or misclassified.
Review Product, Customer/guest identity, rating, text, date, status, and language Reviews remain connected to the intended Product and moderation state.
Reward or loyalty record Customer key, balance, transaction source, and Product/Order context Loyalty data has complete ownership evidence.
Authentication Local password, SSO/social login, reset flow, and communication owner Account access is planned without assuming password portability.

Include Customers with multiple addresses, customer-group pricing, loyalty data, reviews, custom fields, and important Orders. These examples expose relationships that ordinary retail accounts do not.

Prepare Orders, Invoices, Downloads, Shipping, Payment, and POS History

Phoca Cart Orders can include online or POS origin, Order number, token, Customer or guest identity, addresses, Product lines, attributes, taxes, discounts, payment and shipping, statuses, comments, privacy/terms evidence, tracking, invoice/receipt numbers, download links, and external references.

Order evidence Owner Ready condition
Order header and origin Commerce/POS owner Order number, channel, Customer/guest identity, dates, language, and status are documented.
Product lines and attributes Catalog and order owners Product IDs, SKUs, selected attributes, quantities, prices, taxes, and snapshot text are complete.
Totals and discounts Finance owner Subtotal, Product/cart discount, coupon, tax, shipping, payment cost, reward points, and final total reconcile.
Payment, shipping, and tracking Finance/fulfillment owners Historical method labels, references, carrier, tracking, and shipped date are known.
Invoice, receipt, and delivery note Finance owner Numbering, dates, files/layout data, and Order links are recoverable.
Download access Digital-fulfillment owner Files, expiry, maximum download count, Product/attribute relation, and Order are linked.
External references Integration owner POS, ERP, accounting, marketplace, or fulfillment IDs remain traceable.

Choose ordinary, guest, attribute-heavy, discounted, reward-point, refunded or adjusted, downloadable, POS, multilingual, and tracked-shipment Orders where available.

Prepare Joomla Routes, Languages, Access Levels, Modules, and Media

Phoca Cart is fully integrated with Joomla. Menus, access levels, language associations, modules, template overrides, filter/search modules, media paths, and metadata can determine whether migrated commerce records remain discoverable.

Storefront area Evidence Ready condition
Product and Category URLs Source route, alias, menu context, language, metadata, and destination intent Priority paths have one keep, change, merge, retire, or redirect decision.
Joomla menus and access Menu item type, parent, alias, access level, language, and destination Catalog entry points and restricted routes are documented.
Modules and filters Module type, position, menu assignment, attribute/specification/parameter source, and owner Discovery behavior is separated from Product data.
Multilingual associations Product/Category/term associations, languages, menus, and media Translations are not treated as unrelated duplicates.
Template overrides Override files, affected views, custom fields, and module positions Presentation dependencies are recorded separately from commerce records.
Media and protected files Product images, thumbnails, videos, downloads/uploads, remote storage, and filesystem permissions Priority files are available and linked to the correct records.

The broader Joomla CMS scope owns general Articles and CMS Pages. This section captures Joomla structures that directly affect Phoca Cart routes, access, discovery, and commerce media.

Inventory Modules, Plugins, Feeds, Custom Code, and External Systems

Build a dependency ledger for payment, shipping, search, filters, brands, comparison, wish lists, POS, feeds, imports/exports, accounting, ERP, CRM, marketplaces, analytics, and custom modifications.

Dependency Evidence to prepare Ready condition
Phoca module or plugin Name, version, purpose, Product/Customer/Order dependencies, and configuration Extension-owned records have an intended target or retained owner.
XML/CSV feed Feed definition, Product fields, category mapping, identifiers, consumer, and schedule Channel data is separated from the canonical Product model.
POS integration Location/device context, Product/stock authority, Customer/Order IDs, and synchronization process Online and POS histories are not merged incorrectly.
Custom table or source edit Schema, keys, business purpose, and consuming code Custom records can be interpreted rather than copied blindly.
External system Endpoint, data authority, sync direction, IDs, and cutover owner Cross-system identity remains usable.
Generated data Caches, thumbnails, logs, temporary feeds, sessions, and indexes Non-authoritative technical data is excluded deliberately.

Open-source customization makes source inspection especially important. A familiar field name may have acquired local behavior through custom code or SQL changes.

Select Representative Migration Test Samples

Record the source IDs, SKUs, URLs, related records, language, customer group, external key, and reason for each sample.

Sample Evidence to prepare Preparation purpose
Simple Product Price, stock, tax, Category, manufacturer, images, and Order Establishes the ordinary Product baseline.
Attribute variation Attributes/options, required/default state, price/image/stock effects, and Order line Represents buyable variation behavior.
Specification/filter Product Specifications, parameters, tags, Categories, and filter modules Represents descriptive and discovery relationships.
Customer-group case Customer, group, Product price/visibility, form fields, and Order Represents segmented commerce.
Complex Order Guest/registered identity, attributes, discounts, taxes, rewards, payment, shipping, tracking, and invoice Represents historical commercial context.
Downloadable Product/Order Files, protected path, attribute-option file, expiry, count, and Order Represents digital fulfillment.
Multilingual route Associated Products/Categories, aliases, menus, metadata, and redirect intent Represents Joomla language and routing scope.
POS or extension record Core entity, channel/extension owner, external ID, and related Orders Exposes non-core dependencies before execution.

Representative migration test preparation defines samples and source evidence. Later pass, watch, or block decisions belong to the validation workstream.

Complete the Final Phoca Cart Readiness Gate

Readiness area Ready condition
Access and recovery Joomla, Phoca Cart, hosting, database, protected files, backups, and restoration ownership are confirmed.
Catalog Products, Categories, manufacturers, attributes, specifications, parameters, media, downloads, stock, prices, and identifiers are documented.
Customers Joomla users, Customers, groups, forms, addresses, reviews, rewards, and authentication dependencies are classified.
Orders Online/POS origin, lines, attributes, totals, statuses, payment, shipping, invoices, downloads, and external IDs have evidence.
Storefront Menus, access, languages, modules, filters, overrides, URLs, SEO, and media are documented.
Dependencies Plugins, modules, feeds, custom code, external systems, and data authorities have owners.
Samples Representative records cover every material catalog, Customer, Order, route, download, POS, and extension pattern.

The Phoca Cart scope is ready when every material record has a source owner, related-record map, evidence artifact, and destination or retained-system decision.

Conclusion

Phoca Cart preparation requires coordinated evidence across Joomla, Products, attributes, specifications, parameters, customer groups, Customers, Orders, downloads, POS, routes, modules, plugins, feeds, and external systems. These structures must be separated by business meaning before migration execution begins.

A strong preparation package secures recoverable backups, documents authoritative records, separates historical transactions from live configuration, selects representative samples, and assigns an owner and ready condition to every material dependency.

Common Questions

What should be prepared first for a Phoca Cart migration?

Confirm Joomla, Phoca Cart, hosting, database, filesystem, protected download/upload directories, and extension access. Create recoverable backups and record the software and customization inventory before detailed catalog work begins.

What is the preparation difference between attributes and specifications?

Attributes can create Product variations and affect price, image, stock, or buyer selection. Specifications describe Products for comparison and filtering without changing price. Their definitions and Product assignments should remain separate.

Why should parameters and tags be inventoried separately?

Parameters can support filters and searchable values, while tags and labels usually support visual or classification behavior. Combining them can change storefront discovery and archive meaning.

How should customer-group data be prepared?

Record group definitions, assigned Customers, Product prices, display and add-to-cart settings, attribute visibility, discount rules, and any automatic assignment criteria. The group label alone is not sufficient evidence.

Which Orders should be included in the sample ledger?

Include online and POS Orders, guest and registered buyers, attribute-heavy lines, discounts, taxes, reward points, refunds or adjustments, downloads, tracking, invoices, and external references used by support or finance.

How should Joomla and Phoca Cart preparation be divided?

The Joomla scope owns general CMS content, users, menus, modules, templates, and access architecture. Phoca Cart preparation owns commerce Products, Customers, Orders, attributes, stock, rewards, and extensions while documenting only the Joomla dependencies required by those records.