Phoca Cart preparation must connect the item sold to the Joomla route, buyer context, stock rule, and application that make it usable. An attribute name or file path cannot explain those relationships by itself. Preserve their actual settings and source evidence, then confirm the intended destination consumers before treating the commerce scope as ready.
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.
Source access, evidence and recovery
Identify the actual Source Platform separately from the intended Joomla/Phoca Cart environment. When Phoca Cart is the Source, confirm its administration, applicable database/filesystem/media access, protected files, scheduled processes, and external services. For another Source, collect equivalent commerce, content, account, and file relationships without inventing Phoca IDs. Record source versions and separately confirm destination builds, compatible enabled modules/plugins, template, languages, access roles, and implementation owners.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; Joomla/Phoca Cart administrator when Phoca Cart is the Source | Working accounts and role summary | For a Phoca Cart Source, Products, attributes, Customers, Orders, modules, and configuration are inspectable. Another Source provides access to its own selected records. | Actual Source administration. Native Joomla/Phoca Cart access applies when used by that Source; intended Target administration is confirmed separately. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Available actual Source backups or exports, files/media and protected download/upload evidence, recovery coverage, limits and owner; database export and filesystem archive where that Source provides them | Required records and files are recoverable under the declared Source method; full-Store restoration limits are explicit. Resolve a required recovery gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery capability, including required protected-file relationships. Another hosted platform need not expose Joomla databases or filesystems; an archive does not prove complete Store restoration. |
| Record environment and extensions | Source technical owner; intended Target build owner separately | Actual Source software/components; for a Phoca Cart Source, Joomla, Phoca Cart, PHP, database, template, module, plugin, and language inventory | Version- and extension-dependent records are documented. | Actual Source versions and components. Native Joomla/Phoca Cart inventory is conditional on that Source; intended Target compatibility is independently assessed. |
| Capture customizations | Source development owner; intended Target customization owner separately | Actual Source custom behavior and consuming code; where present, template overrides, custom fields, custom SQL, source edits, and bespoke plugins | Every customization that reads or writes commerce records has an owner. | Actual Source record writers and consumers. Intended Phoca Cart fields, modules, plugins or replacements need their own implementation owners. |
| Map connected systems | Source and continuing integration owners | Feed, ERP, CRM, POS, accounting, payment, shipping, and marketplace endpoints and IDs | Continuing systems and authoritative values are known. | Actual Source and continuing external identifiers and authorities. Future Target POS, price/stock writers and synchronization responsibilities require separate decisions. |
Use the recovery arrangements available in the actual Source environment. Record the evidence date, included records/files, protected and remote assets, missing areas, recovery route and owner. Preserve native Joomla/Phoca Cart database and filesystem backups where accessible, but do not require that infrastructure from another hosted Source. A partial archive can recover evidence without restoring the whole Store or its file-entitlement behavior.
Preserve Product, Category, manufacturer, attribute, specification, parameter, Customer, group, Order/line, status, reward, review, form, feed, and external IDs where present in the actual Source and needed to reconstruct relationships. Keep original database/files/media backups where available, or the Source’s exports/files and recovery evidence, dated and protected with remote-asset coverage, limits and recovery ownership. Record approved source-to-intended changes before normalizing keys or values.
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 and catalogue-only state, actual stock-checking and calculation settings, minimum/multiple quantities, feed keys, external IDs, and supported language associations. Distinguish blank or zero values, untracked/unlimited source behavior, and out-of-stock states from their governing settings. An availability label does not establish which quantity controls selling or that the destination provides the same mode.
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. |
Preserve definitions, option assignments, combination keys, and historical references before normalizing vocabulary. Main-Product, variation, and advanced combination stock modes need different evidence. Record actual attribute type, required/optional choices, real sellable combinations, and minimum-quantity calculation alongside values. Descriptive specifications and parameters need compatible active comparison/filter/search consumers; matching names do not establish equivalent behavior.
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, keep dated opening values separate from continuing synchronization authority. Record current reward/credit balances separately from transaction history and confirm the destination owner of group pricing, visibility, tax, discounts, and loyalty rules. Preserved values do not activate those rules.
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-verification method, SSO/social login, reset flow, and communication owner | Account access is planned without assuming password portability. |
Include Customers with multiple addresses, groups, loyalty, reviews, custom fields, and important Orders. Prepare the exact Source-to-Target password-verification decision or required reset, activation, or first-login handling, with identity-provider and communication owners. Account completeness and active access to protected services or downloads are separate requirements.
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, refunded/adjusted, downloadable, POS, multilingual, and tracked-shipment history where available. Preserve original lines, totals, addresses, numbers, statuses, and references independently of current settings. Record the notification, payment, stock, reward, access, and fulfillment events that must be contained when history is imported. File presence and preserved Order history do not configure current download protection or entitlement rules.
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 | Supported Product/Category association records, term-language evidence, 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. |
Review Joomla routes, viewing access, action permissions, languages, modules, and media together with the commerce records that depend on them. Use associations only where the actual component supports them. Modules need their language, menu assignment, access, and translated content recorded separately. A hidden menu link does not establish the viewing access of its destination. General CMS architecture remains in the Joomla scope.
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.
Confirm Phoca Cart Target implementation prerequisites
The intended Joomla/Phoca Cart environment must be able to use the agreed variation, stock, buyer-group and file relationships. A list of attributes does not supply the effective combination-stock settings, and a stored download path does not configure Customer entitlement. Confirm the required compatible consumers and owners before execution, keeping general Joomla CMS work in its own scope.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended build and access | Target technical owner | Joomla/Phoca Cart build, administration, compatible required modules/plugins, available hosting/storage access and recovery responsibilities | The intended installation and required components are available to their owners. |
| Prepare catalog, stock and buyer-group representation | Target catalog, inventory and pricing owners | Real attribute combinations and stock/minimum-quantity modes, specifications/parameters/tags, group prices/visibility, reward requirements and authoritative price/stock owners | Selected selling and discovery relationships have usable consumers and effective settings; familiar field labels or quantities alone do not establish readiness. |
| Prepare account, route and protected-file consumers | Target identity, site and digital-fulfillment owners | Joomla/Customer/guest links, authentication decision, menus/access/languages, modules/filters, media, Product/attribute/Order file links, protection and entitlement limits | Required accounts, routes and files have compatible consumers and explicit access treatment; a hidden menu or file copy alone cannot establish access. |
| Assign modules, POS and continuing live-operation owners | Target application, operations and integration owners | Required custom/module consumers, feeds/POS and external keys, future payment/shipping/tax/notification/stock/reward/access behavior and historical/test containment decisions | Continuing processes have declared owners; historical online/POS records cannot replay charges, messages, stock/reward changes, access grants or fulfillment. |
Select Representative Migration Test Samples
Record source IDs, SKUs, URLs, linked records, language, group, external keys, original values, reasons, intended representation, agreed exclusions, and reviewers. Include the actual stock and minimum-quantity modes for variation samples, and file/Order/group settings for download samples.
| 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 | Actual Source access, available database/files/media backups or exports, required protected files, recovery method, coverage, limits and owner are confirmed. Required evidence is recoverable under that method; intended Joomla/Phoca Cart prerequisites are independently assessed. |
| 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. |
| Target prerequisites | The intended Joomla/Phoca Cart build, catalog/stock/group representation, compatible account/route/filter/protected-file consumers, access and continuing-operation owners are confirmed. |
The scope is ready when every required relationship has evidence and an accepted destination or retained-system treatment, with compatible enabled consumers and implementation owners. Resolve critical gaps, exclude them explicitly by agreement, or hold the affected scope. Accepted noncritical exceptions need a boundary, scope effect, and owner; a future assignment does not replace required evidence.
Assess recoverable actual Source evidence and the intended Target consumers together. An unresolved stock mode, missing protected-file relationship, unavailable filter consumer or unowned POS authority remains a required gap even if the records are present. Resolve it, agree an explicit exclusion or hold the affected scope before execution. Later validation tests the declared buyer and operating outcomes.
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 actual Source evidence under its available backup or export method, records recovery limits, documents authoritative records, separates historical transactions from live configuration, selects representative samples, and assigns an owner and ready condition to every material dependency.
Carry the evidence package, intended Target decisions and any held scope into Phoca Cart Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first for a Phoca Cart migration?
Identify the actual Source and intended Joomla/Phoca Cart environment. Preserve source records, media, protected files, recovery evidence, and customization ownership before cleanup. When Phoca Cart is the Source, include its administration and applicable hosting/database/filesystem access. Confirm the compatible enabled destination build, extensions, and consumers separately.
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.
Does an attribute list establish advanced combination stock?
No. Preserve the actual stock mode, attribute types, required/optional states, real combination keys, quantities, and minimum-quantity settings. Advanced combinations depend on those definitions; not every theoretical pairing is a sellable item. Confirm the intended build and enabled settings before deciding the destination representation.
Does preserving a download file prepare Customer access?
No. Preserve the Product or attribute link, Order/Customer relationship, protection, expiry, count limits, and relevant status context. Separately assign current entitlement configuration and delivery ownership. Imported history must not unintentionally grant new access, while a stored path alone does not prove that an eligible Customer can retrieve the file.