J2Store preparation begins with two connected identities: the Joomla Article that gives the item its content and route, and the commerce records that explain selling and purchase history. Long-lived installations can add several generations of applications and customizations. Preserve those relationships and their owners before cleaning data or deciding how the prospective destination will represent them.
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.
Source access, evidence and recovery
Identify the actual Source Platform and the precise Joomla/J2Store line intended for the destination. When J2Store is the Source, confirm working administration, hosting/database access where available, filesystem, media, scheduled jobs, and service evidence. For another Source, collect equivalent records and relationships without inventing J2Store IDs. Record source versions separately from the destination build, compatible enabled applications, access roles, and implementation prerequisites.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administration access | Actual Source administrator; Joomla/J2Store administrator when J2Store is the Source | Working accounts and role summary | For a J2Store Source, Products, Customers, Orders, applications, and Joomla structures can be inspected. Another Source provides access to its own selected records. | Actual Source administration. Native Joomla/J2Store access applies when that installation is the Source; intended Target administration is separately confirmed. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Available actual Source backups or exports, files/media, recovery method, coverage, limits and owner; database export, filesystem archive and restoration procedure where that Source provides them | Required Source evidence is recoverable under the declared method; full-Store restoration limits are explicit. Resolve a required gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery capability. Another hosted Source need not provide a Joomla database or filesystem; an export may recover selected evidence without restoring the whole Store. |
| Record the installed environment | Source technical owner; intended Target build owner separately | Actual Source software/components; for a J2Store Source, version inventory for Joomla, J2Store, PHP, database, template, plugins, modules, and applications | The actual source stack is documented, including obsolete or custom components. | Actual Source stack and application owners. Native Joomla/J2Store versions apply only when used by the Source; intended Target line and app compatibility are independent. |
| Assign lifecycle ownership | Source business and technical owners; intended Target maintenance owners separately | 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. | Actual Source and intended Target lifecycle ownership are separate decisions. A migration does not supply environment maintenance, security or application replacement. |
| Preserve identifiers | Migration coordinator | Actual Source content, Product, classification, choice/variant, Customer/user, Order, application and external keys; Article, Category, option and variant IDs where present in that Source | Cross-record links can be traced after extraction. | Actual Source keys and relationships only. Do not invent J2Store or destination identifiers for records from another platform. |
Record the actual Source recovery method, evidence date, included records/files, missing areas and owner. A hosted export can protect selected evidence without restoring a complete Store. Keep native Joomla/J2Store database, filesystem and media backups where access permits them; resolve, agree exclusion or hold a required coverage gap.
Record who maintains the actual installed line and each required application. The original J2Store project is archived, while later J2Store/J2Commerce lines have different stewardship and support arrangements. Do not infer that every installation has the same maintenance status or that a newer line supports its old applications. Before cleanup, upgrades or extension removal, keep original database/files/media backups where available, or the actual Source’s exports/files and recovery evidence, dated and protected with coverage, limits, recovery owner and remote-storage notes.
Prepare Article-Based Products and Product Types
J2Store uses Joomla Articles as Products, so preparation must preserve both Article identity and the linked commerce record. Depending on the actual installation, requirements may involve simple, variable, configurable, downloadable, flexivariable, advanced variable, booking, subscription, grouped, bundled, or custom patterns. Record which type and compatible application actually owns each requirement; similar labels on a later J2Commerce line do not establish equivalent support.
| 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 depend on the Product type and installed application. Variable families can have combinations with independent commerce values; other types can separate selected variant dimensions from text, files, or other buyer input. Record the actual relationship and settings instead of applying one matrix rule to every type. Grouped Products also need a component-eligibility decision from their actual owning application.
| 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. |
Preserve the original combinations, IDs, values, status, and historical references before changing variant definitions. Distinguish additive regeneration from deleting and rebuilding a matrix: their effects depend on the actual build and application. Any cleanup or rebuild needs a source-to-intended identity ledger so discontinued combinations remain interpretable in Order history.
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 | Customer identity and account access have separate readiness decisions. |
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. Record the exact Source-to-Target password-verification decision separately, including reset, activation, or first-login handling when needed and the owners of identity-provider and customer communications.
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. Preserve purchased values and totals as historical snapshots, including discontinued variants and application references. Record which destination events must be contained so importing a status cannot unintentionally charge a buyer, grant new access, change stock, send email, or create fulfillment work.
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.
Confirm J2Store Target prerequisites and separate live configuration
The intended Joomla/J2Store line needs its own maintenance owner and compatible applications. A Source Article link, variant or download entitlement cannot establish that the destination has the code needed to interpret it. Confirm the actual selling model and continuing consumers before execution, keeping historical application records separate from active renewal, billing, access and configuration. Familiar Product-type names are insufficient evidence of compatibility between lines.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended line, access and lifecycle owner | Target technical and business owners | Joomla/J2Store line and build, administration, compatible required apps/plugins, available hosting/storage access, maintenance, security, replacement and recovery responsibilities | The intended environment and its support/maintenance responsibilities are explicit; required compatible components are available and enabled. |
| Prepare commerce, content and account consumers | Target catalog, identity and site owners | Article/Product links, actual Product types and real combinations, option identity, buyer inputs, images/files, Categories/menus/modules, languages, groups and authentication decision | Required sellable, content, account and route relationships have an agreed usable representation without rebuilding historical identities by assumption. |
| Confirm specialized and continuing application ownership | Target application and integration owners | Downloads/entitlements, grouped/bundled records, subscriptions/bookings or other actual requirements, compatible consumers, related history/keys and retained-system or exclusion decisions | Required application-owned records have a usable destination or retained owner; historical references do not establish live billing, access or renewal authority. |
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, including required compatible applications and their active consumers. Download history does not configure current file protection, and subscription history does not establish transferable billing authorization or working renewal jobs. Assign those prerequisites independently from the preserved records.
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, original values, intended destination representation, agreed exclusions, and a reviewer. Include the actual application/build context for specialized or legacy records. These source expectations prepare subsequent migrated-outcome proof; they do not replace validation.
Establish the Final Readiness Gate
| Readiness question | Ready condition |
|---|---|
| Can the Store be recovered? | Dated, protected actual Source recovery evidence exists, with method, coverage, limits and recovery owner. Native database/filesystem backups are retained where available; required recovery gaps are resolved, explicitly excluded by agreement or held. |
| 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? | Required gaps are resolved, explicitly excluded by agreement, or held; accepted noncritical exceptions state their owner, deadline, boundary, and scope effect. |
| Can the intended Target use the agreed scope? | The intended Joomla/J2Store line, access, lifecycle responsibilities, compatible enabled applications and required commerce/content/account consumers support the agreed representation; live configuration remains separately owned. |
Missing required Source recovery evidence, unclear lifecycle ownership, changed variant identities without a source ledger, unknown app tables, or untraceable specialized history should block the affected scope. Resolve each required gap or agree an explicit exclusion before proceeding with that scope. An owner and future deadline alone cannot make a required relationship ready.
The final preparation decision connects recoverable actual Source evidence with the intended environment’s usable consumers. An unowned lifecycle dependency, missing real combination or unavailable specialized consumer cannot be cleared by assigning a future owner alone. Resolve it, agree its explicit exclusion or hold the affected scope before execution. Later validation owns proof of the migrated relationships and operating result.
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.
Carry the evidence package, intended Target decisions and any held scope into J2Store Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first before a J2Store migration?
Identify the actual Source Store and intended Joomla/J2Store line. Secure source records, media, scheduled-process evidence, and available backups, exports/files or recovery evidence before cleanup or upgrades; record their coverage and limits. When J2Store is the Source, include its administration and applicable hosting/database/filesystem access. Record the precise versions, application owners, and destination prerequisites separately.
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.
How should J2Store lineage and maintenance responsibility be recorded?
Record the exact installed line, Joomla version, custom modifications, application versions, and the party responsible for maintenance and compatibility. The original project and later J2Store/J2Commerce lines have different stewardship. Prepare the destination support and application decisions for that exact environment; a familiar name is insufficient evidence.
Can every option-bearing Product be included in a grouped Product?
Do not assume so. The documented Group Products application for the compatible J2Store/J2Commerce 4.x environment accepts eligible simple, configurable, and downloadable components without options. An older or customized application needs its actual eligibility contract. Preserve component identity, stock/pricing ownership, and the agreed destination composition before considering the group ready.