J2Commerce preparation must connect commerce records to the Joomla structures that make them visible and usable. Products can depend on Joomla Articles, Categories, menus, modules, custom fields, user groups, applications, payment extensions, shipping extensions, and template layouts. Specialized Product types can add variants, downloads, subscriptions, bookings, bundles, deposits, or customer-entered data that cannot be understood from the Product count alone.
The preparation package should define each action, owner, evidence artifact, and ready condition before migration begins. It should also separate records that belong to migration scope from live checkout, tax, payment, shipping, notification, cron, and extension configuration that belongs to target implementation.
This preparation should produce a representative J2Commerce sample, expose any mapping or tailored-handling requirement, and separate migration scope from Joomla and J2Commerce implementation before broader execution.
Secure Joomla, J2Commerce, Hosting, and Database Access
Confirm access to Joomla administration, J2Commerce administration, hosting, database, filesystem, media, scheduled tasks, and external services. Record the Joomla version, J2Commerce version, PHP and database versions, active template, enabled languages, installed applications, payment and shipping extensions, and any custom code.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administrative access | Joomla/J2Commerce administrator | Working accounts and role summary | Catalog, Orders, Customers, applications, menus, and configuration can be inspected. |
| Create recoverable backups | Infrastructure owner | Database export, filesystem archive, external media notes, and restoration owner | The source can be recovered without relying on the live Store. |
| Capture the extension environment | Technical owner | Component, plugin, module, template, and application inventory with versions | Every commerce dependency is listed with an owner. |
| Record scheduled and external processes | Integration owner | Cron jobs, webhook endpoints, ERP/PIM/WMS/CRM/payment/shipping connections, and external IDs | Continuing integrations and data authorities are identified. |
| Preserve source identifiers | Migration coordinator | Product, Article, Category, user, Customer, Order, option, variant, subscription, and external IDs | Cross-record relationships can be traced after extraction. |
If the Store originated in J2Store or passed through a major version change, record that lineage. Similar labels can refer to different tables or application versions, and older customizations may still depend on legacy fields.
Prepare Products by Selling Behavior
Do not classify J2Commerce Products only by name or count. Prepare them according to the behavior that must remain understandable: simple sale, variant sale, download, subscription, booking, bundle, service, deposit, personalized item, or application-owned Product type.
| Product pattern | Required evidence | Ready condition |
|---|---|---|
| Simple physical Product | Article/Product ID, SKU, price, tax profile, stock, weight, images, Category links, and sample Order | One record clearly identifies the sellable item and its Joomla content relationship. |
| Variant Product | Option definitions, values, generated variants, per-variant SKU/price/stock/image, and parent Product ID | Every sellable combination can be traced to its parent and selected values. |
| Downloadable Product | File records, access rules, limits, expiry, Product link, and completed Order sample | File ownership and Order-based access evidence are complete. |
| Subscription Product | Product type, plan/variant, billing interval, trial, status, payment dependency, cron dependency, Joomla user-group link, and sample subscription | Recurring state and access relationships have a named owner and target decision. |
| Booking or reservation Product | Resource, date/time rules, capacity, pricing, Customer input, and sample booking | Availability records and booking history are separated from ordinary Product fields. |
| Bundle or grouped Product | Parent Product, component Products, quantities, pricing logic, stock relationship, and sample Order | Component identity and ownership are documented. |
| Personalized Product | Input field definitions, option behavior, buyer-supplied files, price effects, and sample Order line | Buyer-entered data remains distinguishable from reusable Product attributes. |
For each Product type, record which values control identity, price, stock, tax, weight, shipping, access, renewal, or fulfillment. If an application or custom plugin owns part of the behavior, include its tables, keys, and configuration dependency in the evidence package.
Prepare Options, Variants, Custom Fields, and Article Relationships
J2Commerce Products can be connected to Joomla Article content and to J2Commerce option or variant structures. Preparation must distinguish shared Product content from sellable-combination data and customer-entered values.
| Relationship | Evidence | Ready condition |
|---|---|---|
| Joomla Article to Product | Article ID, Product ID, aliases, language, access level, and content fields | Product content is not separated from the Product record accidentally. |
| Product option | Option name, type, values, ordering, price effect, and Product assignment | Reusable choice definitions are documented. |
| Variant | Parent Product, selected option values, SKU, stock, price, image, status, and external ID | Every real sellable unit has a unique traceable record. |
| Custom field | Field definition, context, values, business purpose, and consuming layout/application | Descriptive data is not confused with buyer choice or application state. |
| Customer input | Input definition and sample Order-line value | One-time buyer input remains attached to the purchase context. |
Normalize obvious duplicate option labels only after retaining the original vocabulary and relationships. If “Colour,” “Color,” and “Finish” have different business meanings in the source, do not merge them merely because they look similar.
Prepare Categories, Menus, URLs, Media, and Storefront Discovery
J2Commerce catalog discovery can depend on Joomla Categories, Article ordering, menu items, modules, filters, search, template layouts, and Product media. A Product can be complete in administration but unavailable through the intended route.
Prepare a Product-to-Category map, Category hierarchy, Article ordering evidence, menu-item inventory, module assignments, filter values, priority URLs, redirects, image references, and language assignments. Include routes for Product pages, Category views, account pages, downloads, subscription management, cart, checkout, and important campaign pages.
| Discovery area | Preparation evidence | Ready condition |
|---|---|---|
| Category membership | Product/Article IDs and Category hierarchy | In-scope Products have intentional discovery placement. |
| Menu routing | Menu item type, parent, alias, language, access level, and destination | Priority storefront paths have explicit target routes. |
| Modules and filters | Module position, menu assignment, filter source, and owning extension | Discovery behavior is separated from Product data. |
| Product media | File paths, primary/additional/variant images, alt text, and remote storage notes | Media relationships are traceable to the correct Product or variant. |
| Redirects and metadata | Source URL, target intent, metadata, canonical notes, and routing-extension evidence | High-value paths have one intended treatment. |
Do not assume that migrating Products recreates Joomla menus, module positions, template views, or search/filter behavior. Those are separate target-side responsibilities, but their source relationships must be documented.
Prepare Customers, Joomla Users, Groups, and Addresses
J2Commerce Customer identity may involve Joomla users, guest purchasers, address records, Customer groups, company fields, tax identifiers, membership relationships, and external CRM or ERP keys. Prepare these separately.
| Account concern | Evidence | Ready condition |
|---|---|---|
| Registered Customer | Joomla user ID, Customer ID, email, status, groups, addresses, and external IDs | Duplicate and multi-group cases have an intended treatment. |
| Guest Customer | Order-level identity and addresses | Guest history is not forced into invented user accounts. |
| Customer group | Group definition and related price, tax, access, or discount behavior | Group meaning is documented beyond the label. |
| Company or tax identity | Company fields, tax numbers, validation status, and external account reference | Business-account data has a named target owner. |
| Authentication | Local password, SSO, social login, MFA, reset flow, and communication owner | Account access is planned without assuming password portability. |
If a subscription or membership application changes Joomla user groups after purchase, include the trigger status, Product link, target group, subscription state, and relevant sample Orders. Group assignment is then an application relationship, not merely Customer metadata.
Prepare Orders, Payments, Shipping, Taxes, and After-Sale History
Historical Orders should explain what was purchased and what happened. Prepare Order headers, Order lines, Product/variant references, selected options, customer-entered values, addresses, prices, discounts, taxes, payment labels, shipping labels, statuses, comments, transactions, invoices, refunds, downloads, subscriptions, and booking references where present.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and status history | Commerce operations | Status sequence and timestamps are understandable. |
| Order lines | Catalog and operations | Product, variant, SKU, selected values, quantity, and price are preserved as historical snapshots. |
| Payment evidence | Finance or payment owner | Method label and transaction reference are documented without treating credentials as migrated data. |
| Shipping evidence | Fulfillment owner | Method label, charge, tracking, and shipment context are available where used. |
| Tax and discount evidence | Finance or commerce owner | Applied amounts and labels can be reconciled with totals. |
| After-sale records | Customer service owner | Refunds, downloads, subscription changes, cancellations, or booking status are linked to the Order. |
Create a status glossary explaining what each source Order, payment, shipping, subscription, and booking status means operationally. Similar labels can represent different states across extensions.
Inventory Applications, Plugins, Custom Tables, and Integrations
J2Commerce applications and Joomla extensions can own subscriptions, bookings, bundles, deposits, shipping, payment, discounts, stock synchronization, product feeds, invoices, loyalty, reviews, and custom checkout data. The preparation package must identify the actual owner of each record.
For every important extension, record name, version, tables, fields, primary keys, foreign keys, Product/Customer/Order references, configuration dependencies, scheduled tasks, external services, and current business owner. Classify the requirement as native record, application-owned record, external-system record, target configuration, presentation, or retirement candidate.
External identifiers deserve separate attention. ERP Product IDs, CRM Customer IDs, marketplace listing IDs, warehouse codes, payment transaction IDs, and subscription gateway references may be small fields but critical relationship keys.
The ready condition is reached when no required commerce record remains described only as “custom data” or “app data.” Each active dataset must have a named entity, owner, source evidence, and destination decision.
Separate Migrated Records From Target Configuration
Current tax, payment, shipping, email, currency, cron, checkout, cache, template, and security behavior belongs to target implementation. Historical records can preserve labels and amounts without configuring live behavior.
| Source evidence to prepare | Target-side responsibility kept separate |
|---|---|
| Historical payment labels and transaction IDs | Gateway account, credentials, callbacks, fraud settings, and live payment testing |
| Historical shipping labels and tracking | Carrier accounts, rates, zones, packaging, pickup, and fulfillment configuration |
| Historical tax amounts and tax-profile references | Current tax registrations, rates, exemptions, and calculation settings |
| Product and Customer group relationships | Active pricing, access, and promotional configuration |
| Subscription history and billing references | Current gateway token support, renewal jobs, email, and access automation |
| Existing URLs and metadata | Target menus, template output, search, and redirect implementation |
Preparation is ready when the source evidence explains historical meaning and the target implementation owner accepts responsibility for live configuration. Do not use a successful source export as evidence that checkout or recurring billing is configured.
Select Representative Migration Test Samples
Choose samples that expose J2Commerce’s difficult relationships. Include:
- a simple Product linked to a Joomla Article and Category;
- a multi-option Product with generated variants and per-variant SKU or stock;
- a downloadable Product with file-access evidence;
- a subscription, booking, bundle, or other specialized Product where used;
- a Customer with several addresses or groups;
- a guest Order and a registered-Customer Order;
- an Order with discount, tax, shipping, and payment references;
- a Product with custom fields, customer input, or application-owned data;
- a multilingual or restricted Product route;
- a Product or Order linked to an external identifier.
For each sample, record source IDs, why it was selected, the relationships it exercises, the evidence needed to interpret it, and any target configuration that is intentionally outside migration scope.
Establish the Final Readiness Gate
| Readiness question | Ready condition |
|---|---|
| Is the source recoverable? | Database, filesystem, media, and extension evidence are backed up with a restoration owner. |
| Are Product types classified? | Every in-scope Product family has a type, selling behavior, owner, and representative sample. |
| Are Joomla relationships visible? | Articles, Categories, menus, modules, languages, access levels, and routes are mapped for priority Products. |
| Are Customers and Orders interpretable? | User links, groups, addresses, statuses, totals, and after-sale records are documented. |
| Are applications and custom data owned? | Every active extension dataset has a schema, owner, source key, and destination decision. |
| Is configuration separated? | Live checkout, tax, payment, shipping, cron, and template responsibilities have named target owners. |
| Are samples adequate? | representative migration samples cover variants, specialized Products, Customer/Order states, URLs, and extension data. |
Unknown backups, unclassified Product types, missing variant identity, undocumented subscription or booking data, or unowned extension tables should block the affected scope until evidence is complete.
Conclusion
J2Commerce preparation requires more than a Product and Order export. It must preserve the relationships among Joomla Articles, Categories, menus, users, J2Commerce Products, options, variants, Customers, Orders, specialized Product applications, files, routes, and external systems.
A strong preparation package assigns every action to an owner, records the evidence needed to understand each relationship, separates live target configuration from historical records, and selects representative samples that expose the Store’s real complexity before migration begins.
Common Questions
What should be prepared first for a J2Commerce migration?
Secure Joomla, J2Commerce, hosting, database, filesystem, scheduled-task, and external-system access. Then create immutable backups and a dated environment and extension inventory before cleaning or restructuring records.
Why are Joomla Articles important in J2Commerce preparation?
J2Commerce Products can depend on Joomla Article content, Categories, menus, language, access levels, modules, and routes. The Product record alone may not contain the full storefront identity or discovery path.
How should J2Commerce variants be prepared?
Record the parent Product, option definitions, selected values, variant SKU, stock, price, images, status, and external identifiers. Use representative variants that expose the combinations most likely to lose identity during migration.
What evidence is needed for J2Commerce subscriptions or bookings?
Prepare Product type, plan or resource, schedules, statuses, Customer and Order links, payment references, access rules, scheduled-task dependencies, and representative historical records. Treat live renewal or availability configuration as a separate target responsibility.
Should payment, shipping, and tax settings be included as migrated records?
Historical Orders should retain method labels, amounts, and transaction or tracking references. Live gateways, carrier rates, zones, credentials, and tax calculation belong to target configuration and should have separate owners.
Which records should be chosen for J2Commerce representative migration test?
Choose simple and variant Products, specialized Product types, downloadable files, complex Customers, guest and registered Orders, discounts and taxes, multilingual or restricted routes, custom fields, application-owned data, and external identifiers.