J2Store preparation must account for the fact that Products are built on Joomla Articles and can be extended through several Product types and applications. A Product can depend on Joomla content, Categories, menus, modules, user groups, options, variants, downloads, bundled Products, booking or subscription applications, payment and shipping plugins, template overrides, and custom tables.
A reliable preparation package makes each dependency visible before migration begins. It should define the action, owner, evidence, and ready condition for every major area while keeping historical commerce records separate from live target configuration. Because many J2Store installations are long-lived or highly extended, the package must also document who owns the source platform’s maintenance, recovery, and compatibility decisions.
Confirm Source Access, Recovery, and Lifecycle Ownership
Start with working Joomla Administrator and J2Store access, hosting and database access, filesystem and media access, and access to scheduled jobs or external services. Record Joomla, J2Store, PHP, database, template, and extension versions.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administration access | Joomla/J2Store administrator | Working accounts and role summary | Products, Customers, Orders, applications, and Joomla structures can be inspected. |
| Create recoverable backups | Infrastructure owner | Database export, filesystem archive, media notes, and restoration procedure | The source can be restored independently of the live Store. |
| Record the installed environment | Technical owner | Version inventory for Joomla, J2Store, PHP, database, template, plugins, modules, and applications | The actual source stack is documented, including obsolete or custom components. |
| Assign lifecycle ownership | Business and technical owners | Named owner for hosting, security, compatibility, extension replacement, and recovery | Migration scope is not used as a substitute for maintaining the source or target environment. |
| Preserve identifiers | Migration coordinator | Article, Product, Category, option, variant, Customer, user, Order, application, and external IDs | Cross-record links can be traced after extraction. |
If the Store is no longer actively maintained, record that fact explicitly. Avoid cleanup, upgrades, or extension removal before the immutable backup and schema evidence are complete, because a seemingly unused table or plugin may still own Order or Product history.
Prepare Article-Based Products and Product Types
J2Store uses Joomla Articles as Products. Preparation must preserve both the Joomla Article identity and the J2Store commerce record. Product types can include simple, variable, configurable, downloadable, flexivariable, advanced variable, booking, subscription, grouped, bundled, or application-defined patterns depending on the installation.
| Product pattern | Evidence | Ready condition |
|---|---|---|
| Simple Product | Article/Product IDs, SKU, price, stock, tax profile, weight, images, Category links, and sample Order | Content and commerce identity point to the same sellable item. |
| Variable Product | Options, generated combinations, per-combination SKU, price, stock, weight, image, and status | Every sellable combination is traceable and complete. |
| Flexivariable or advanced variable Product | Combination records, publish state, non-variant inputs, and custom fields | Variant combinations and customer-entered values are separated. |
| Downloadable Product | File records, download limits, expiry, Customer area route, and completed Order sample | Product-to-file and Order-to-access relationships are documented. |
| Grouped or bundled Product | Parent, components, quantities, pricing/discount logic, stock owner, and sample Order | The composition and inventory relationship are explicit. |
| Booking or subscription Product | Resource/plan, schedule, status, payment dependency, Joomla group behavior, and historical records | Specialized application ownership is documented. |
Classify every Product family by what changes when the buyer selects an option: SKU, stock, price, weight, shipping, tax, file access, booking availability, subscription schedule, or customer input. This determines whether the value belongs to a real variant, a Product option, an Order-line input, or an application record.
Prepare Options, Variants, Images, and Customer Inputs
J2Store option structures can produce different outcomes depending on Product type and installed applications. A variable Product may generate a matrix of combinations with independent SKU, price, and stock. An advanced variable Product may combine variant dimensions with free-form input. A grouped Product may reject Products that already have options.
| Preparation area | Evidence | Ready condition |
|---|---|---|
| Option definitions | Names, types, values, ordering, Product assignments, and price effects | Equivalent and distinct option vocabularies are understood. |
| Variant combinations | Parent Product, value combination, SKU, price, stock, image, status, and external key | Each sellable child has stable identity. |
| Customer-entered text or files | Input definition and sample Order-line values | One-time input is not mistaken for reusable Product metadata. |
| Product and variant images | Main, thumbnail, additional, and combination-specific files | Media is attached to the correct Product or variant. |
| Deprecated or unused combinations | Status, Order history use, and retirement decision | Historical references are preserved even if the live combination is excluded. |
Do not regenerate variant matrices before recording the original combinations and their IDs. Regeneration can alter identity or remove data attached to existing combinations. If cleanup is needed, retain a source-to-cleaned mapping ledger.
Prepare Joomla Categories, Menus, Modules, and URLs
Because J2Store Products are Joomla Articles, discovery depends on Joomla Categories, Article ordering, menu items, modules, access levels, languages, template views, and application routes. Prepare these relationships for high-value Products and storefront pages.
| Discovery relationship | Evidence | Ready condition |
|---|---|---|
| Product Article to Category | Article/Product IDs and Category hierarchy | Product placement is intentional and traceable. |
| Category and Article ordering | Source ordering values and menu display rules | Important merchandising order is documented where it matters. |
| Menu item to Store view | Menu type, alias, parent, language, access level, and destination | Product, Category, cart, checkout, profile, download, and account routes are known. |
| Module assignment | Position, menu assignment, language, and owner | Storefront modules are classified as content, presentation, or application output. |
| URL and redirect | Current path, object owner, target intent, and routing extension | Priority paths have one intended destination. |
| Multilingual relationship | Language assignments and Joomla associations | Translated Product and navigation families are traceable. |
A Product export does not recreate Joomla menus or modules. Prepare the content and route evidence needed to distinguish data migration from target template and navigation implementation.
Prepare Customers, Joomla Users, Groups, and Addresses
J2Store Customers can be linked to Joomla users, guest Orders, addresses, Joomla groups, application-specific profiles, tax fields, company data, and external identifiers. Prepare these relationships separately.
| Account pattern | Evidence | Ready condition |
|---|---|---|
| Registered Customer | Joomla user ID, Customer profile, email, groups, addresses, status, and Orders | Duplicate emails and multi-group accounts have a documented treatment. |
| Guest Customer | Order-level identity and addresses | Guest history remains understandable without creating unsupported accounts. |
| Group-based commerce | Joomla group, Product link, trigger Order status, pricing/access effect, and owning application | Group assignment is represented as a business relationship rather than a label. |
| Company or tax account | Company fields, tax ID, exemption status, and external account ID | Business identity has a named owner. |
| Authentication dependency | Password source, SSO/social login, MFA, reset flow, and communication owner | Account access is planned without assuming source credential portability. |
Where an application adds a user to a Joomla group after purchase, capture the Product, selected group, triggering Order status, current membership, and sample history. That workflow may control protected content or services after the sale.
Prepare Orders and Historical Commerce Evidence
Prepare Order headers, Order lines, Product and variant references, selected options, customer inputs, billing and shipping addresses, prices, discounts, taxes, payment and shipping labels, statuses, comments, tracking, invoices, downloads, subscriptions, bookings, vouchers, and application records where present.
| Historical record | Evidence | Ready condition |
|---|---|---|
| Order status history | Status definitions, timestamps, comments, and operational meaning | Each status can be interpreted without relying on the old interface. |
| Product lines | Article/Product/variant IDs, SKU, selected values, quantity, price, and tax | The purchased item remains identifiable even if the live catalog changes. |
| Payment context | Method label and transaction reference | Historical payment evidence is available without moving credentials. |
| Shipping context | Method label, charge, tracking, and fulfillment notes | Historical delivery evidence is distinct from current carrier configuration. |
| Download access | Product file, Order status, limit, expiry, and Customer link | Digital entitlement history is traceable. |
| App-owned history | Subscription, booking, bundle, group assignment, voucher, or loyalty records | Related application records are connected to the correct Order and Customer. |
Build a status glossary for Order, payment, shipping, download, subscription, and booking states. Similar terms such as New, Confirmed, Pending, Failed, or Completed can carry different operational meaning depending on the extension.
Inventory Applications, Plugins, Custom Fields, and Custom Tables
J2Store applications can own grouped Products, bundles, additional fees, bulk discounts, Customer-group actions, bookings, subscriptions, downloads, shipping, payment, analytics, and other records. Joomla plugins, template overrides, and custom tables can extend the same entities.
For every important dependency, document:
- name and version;
- business purpose;
- tables and fields;
- Product, Customer, user, and Order keys;
- scheduled tasks or event triggers;
- external services and identifiers;
- target owner or retirement decision;
- representative source records.
Do not describe the requirement only as “app data.” Name the entity: subscription, booking, bundle component, fee, group assignment, download entitlement, custom checkout field, listing, or integration state. A clear entity definition is necessary before a destination can be selected.
Separate Historical Records From Live Target Configuration
Historical labels and amounts can migrate as evidence, but live tax, payment, shipping, email, cron, template, security, and extension behavior must be implemented separately.
| Source evidence | Separate target responsibility |
|---|---|
| Payment method label and transaction ID | Gateway account, credentials, callbacks, fraud controls, and active testing |
| Shipping method, charge, and tracking | Carrier account, zones, rates, pickup, packaging, and fulfillment setup |
| Historical tax amount and profile label | Current tax registrations, rates, exemptions, and calculation rules |
| Product and Customer group relation | Current access, pricing, or membership automation |
| Download history | Current file protection, Customer area, email delivery, and access policy |
| Subscription or booking history | Current gateway support, scheduled jobs, capacity rules, notifications, and renewal logic |
| Existing Store URLs | Target menus, aliases, template output, redirects, and search implementation |
The preparation package is ready when source evidence and target implementation ownership are both explicit. It should not claim that historical records configure future operations.
Select Representative Migration Test Samples
Choose difficult, relationship-rich samples rather than only clean simple Products. Include:
- a simple Product tied to a Joomla Article and Category;
- a variable or flexivariable Product with independent combination data;
- an advanced variable Product with customer input where used;
- a downloadable Product with access history;
- a grouped, bundled, booking, or subscription Product where used;
- a multilingual or restricted Product route;
- a Customer with multiple addresses or groups;
- a guest Order and a registered-Customer Order;
- an Order with discount, tax, payment, shipping, and tracking evidence;
- an application-owned record or external identifier.
For each sample, record source IDs, linked Joomla and J2Store records, why it was selected, evidence required, and any live behavior intentionally assigned to target implementation.
Establish the Final Readiness Gate
| Readiness question | Ready condition |
|---|---|
| Can the Store be recovered? | Immutable database and filesystem backups exist with a restoration owner. |
| Is lifecycle ownership clear? | Hosting, security, compatibility, extension replacement, and recovery have named owners. |
| Are Product types and variants classified? | Every important Product pattern has source evidence and a representative sample. |
| Are Joomla relationships mapped? | Product Articles, Categories, menus, modules, languages, access levels, and URLs are traceable. |
| Are Customers and Orders understandable? | User links, groups, addresses, statuses, totals, and app-owned history are documented. |
| Are applications and custom data owned? | Each active dataset has a schema, owner, source key, and destination decision. |
| Is target configuration separated? | Checkout, payment, shipping, tax, cron, template, and security responsibilities are assigned. |
| Are unresolved items controlled? | Every unresolved dependency has an owner, deadline, and scope effect. |
Missing backups, unclear lifecycle ownership, regenerated variants without a source ledger, unknown app tables, or untraceable specialized Product history should block the affected scope.
Conclusion
J2Store migration preparation must preserve the connection between Joomla Articles and commerce records while accounting for Product types, variants, files, Customers, Orders, applications, URLs, and long-lived customizations. The preparation package should show who owns each action, which evidence proves the source relationship, and what condition makes the scope ready.
This approach keeps historical records distinct from live target configuration and prevents legacy extension behavior from being hidden inside a generic Product or Order export.
Common Questions
What should be prepared first before a J2Store migration?
Confirm Joomla, J2Store, hosting, database, filesystem, media, and scheduled-task access. Create immutable backups and document the exact source versions and installed applications before cleanup or upgrades.
Why do J2Store Products require both Joomla and commerce evidence?
J2Store uses Joomla Articles as Products. Content, Categories, language, access, menus, and routes can belong to Joomla while SKU, price, stock, options, variants, and Order relationships belong to J2Store.
How should J2Store variable Products be prepared?
Record option definitions and every generated combination with parent Product, selected values, SKU, price, stock, images, status, and external identifiers. Do not regenerate combinations before preserving the original identity map.
What evidence is needed for downloadable Products?
Prepare Product-to-file links, file locations, download limits, expiry settings, Customer-area routes, relevant Order statuses, and representative completed Orders showing access history.
How should J2Store applications and custom tables be documented?
Name the application and entity, record tables, keys, Product/Customer/Order relationships, triggers, scheduled tasks, external dependencies, and representative records. Avoid treating all extension-owned information as generic custom data.
Which records should be chosen for J2Store representative migration test?
Choose Article-based simple Products, variant Products, advanced or specialized Product types, restricted or multilingual routes, complex Customers, guest and registered Orders, digital access, application-owned data, and external identifiers.