An EShop by Ossolution Team preparation package should explain what the buyer selected, which files they may access, and how the purchase connects to Joomla content and identity. Those relationships can be lost in a flat catalog export even when the Product count is complete. Collect the source evidence and settle its intended destination treatment before execution.
EShop preparation must document the relationships behind its Products, Categories, manufacturers, options, attributes, custom fields, attachments, Customer accounts, Orders, taxes, shipping, payment, multilingual content, and Joomla presentation. Product options can carry separate SKU, price, and image data, while attributes and custom fields can describe or filter Products without representing an independent sellable item.
The preparation package should define each action, owner, evidence artifact, and ready condition before execution. It should preserve historical transactions and source relationships while keeping live checkout, payment, shipping, tax, email, template, and module behavior under target-side implementation ownership.
Source access, evidence and recovery
Identify the actual Source Platform separately from the intended Joomla and EShop destination build. When EShop is the Source, confirm access to its administration, hosting, database, filesystem, Product images and attachments, purchase-download files, scheduled processes, plugins, and integrations. For another Source Platform, collect equivalent evidence without inventing EShop or Joomla records. Record source versions and separately confirm compatible destination extensions, enabled settings, and implementation owners.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; Joomla/EShop administrator when EShop is the Source | Working accounts and role summary | For an EShop Source, Products, options, Customers, Orders, reports, and configuration are inspectable. Another Source provides access to its own selected records. | Actual Source administration. Joomla/EShop access applies only when used by that Source; intended Target administration is separately confirmed. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Available actual Source backups or exports, files/media/downloads, recovery coverage, limits and owner; for an EShop Source with suitable access, database export and filesystem/media/download archive | Required evidence can be recovered under the declared Source method; full-Store restoration limits are explicit. Resolve a required gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery capability, including purchased-file evidence where required. Another hosted Source need not expose Joomla databases or filesystems; an export is not proof of complete Store restoration. |
| Record software and extensions | Source technical owner; Target build owner separately | Actual Source software/components; for an EShop Source, Joomla, EShop, PHP, database, template, payment, shipping, plugin, module, and addon inventory | Version-dependent records and dependencies are documented. | Actual Source versions and components. Native Joomla/EShop inventory applies only when present; intended Target versions and compatibility require a separate decision. |
| Capture customizations | Source development owner; Target customization owner separately | Actual Source custom behavior and consuming code; where present, template overrides, custom modules/plugins, source edits, custom fields, SQL changes, and scripts | Every customization that reads or writes commerce data has an owner. | Actual Source record writers and consumers. Intended EShop fields, templates, plugins or replacements require their own Target owners. |
| Map connected systems | Source and continuing integration owners | ERP/PIM/WMS/CRM/accounting/fulfillment/marketplace/feed endpoints and external IDs | Continuing systems and data authorities are known. | Actual Source and continuing external IDs and authorities. Target endpoints, keys and synchronization responsibilities are assigned independently. |
Record the actual Source recovery route, date, covered records/files, missing areas and owner. Retain EShop database, filesystem, media and purchased-download archives where the Source and available access permit them. For another hosted Source, preserve the exports/files or managed recovery that it provides and state their limits. A recoverable file alone cannot establish its Product or Order access relationship, and a catalog export cannot prove full Store restoration.
Preserve Product, Category, manufacturer, option, option-value, attribute, custom-field, Customer, Order, Order-line, status, tax, shipping, payment, attachment, language, and external IDs where present. Date and protect the original database/file/media/download evidence before cleanup. Recovery ownership must cover remote files and the actual source hosting arrangement as well as the local archive.
Prepare Products, Categories, Manufacturers, Media, and Attachments
EShop Products can contain identifiers, descriptions, Categories, manufacturers, prices, stock, dimensions, images, videos, options, attributes, custom fields, attachments, labels, related Products, reviews, metadata, downloadable files, and language associations. Prepare Products by selling behavior and commercial importance.
| Product pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple physical Product | Product ID, SKU, price, tax, stock, Category, manufacturer, images, and sample Order | One record clearly identifies the sold item. |
| Option-heavy Product | Option definitions, values, combinations, separate SKU/price/image data, stock relationship, and Order sample | Every buyable choice can be traced to the correct Product and option values. |
| Downloadable Product | File, Product link, access rule, download history where used, and completed Order | File ownership and Order-based access are documented. |
| Multi-Category Product | Product-to-Category links, priority route, and language | Discovery relationships are preserved without duplicate Products. |
| Attachment-rich Product | Documents, manuals, specifications, file paths, labels, and Product assignments | Non-image assets remain connected to the intended Product. |
| Related/compared Product | Relationship type, linked Product IDs, display purpose, and priority | Merchandising relationships are documented separately from taxonomy. |
Record unpublished, featured, call-for-price, out-of-stock, downloadable, multilingual, limited-quantity, and custom-label cases. These states need intentional destination treatment.
Separate Options, Attributes, Custom Fields, and Product Attachments
EShop options represent buyer selections, including types that do not form independently stocked variants. An option value may carry a SKU component, price adjustment, quantity, or image. Record what the actual Product and option type stores rather than assuming every possible combination has its own inventory record. Attributes describe Product characteristics; custom fields hold additional structured values with their own definitions and consumers.
Product attachments are files made available from the Product page. Purchased downloads instead need Product-to-file relationships, Order-based entitlement, and any download limits. An asset can be recoverable while its intended access is still undecided, so collect both file evidence and the applicable access meaning.
| Structure | Evidence | Ready condition |
|---|---|---|
| Product option | Option name, type, values, ordering, required/default state, Product assignments, and Order-line sample | Buyer-selectable values remain connected to purchases. |
| Option value with commercial data | Product, option/value, SKU component, price adjustment, image, effective quantity/stock ownership, and external key | Buyer-choice data is not flattened into descriptive attributes or assumed to be an independent stocked combination. |
| Product attribute | Attribute group/value, Product assignments, filter/compare use, and language | Descriptive characteristics remain separate from variants. |
| Custom field | Field definition, data type, business purpose, Product assignments, and consuming module/plugin | Custom values have a named owner and editing surface. |
| Attachment | File path, type, label, language, Product link, and access expectations | Product files remain recoverable and correctly related. |
| Extra Product tab or label | Title, content, language, Product assignment, and presentation owner | Editorial content is not confused with Product identity or option data. |
Create a field dictionary that records purpose, owner, value type, Product scope, and migration treatment. Similar names should not be merged when their commercial behavior differs.
Prepare Prices, Stock, Taxes, Discounts, Currencies, and Quantity Rules
EShop pricing can involve regular and special prices, option adjustments, taxes, coupons, discounts, currencies, quantity rules, and Customer-group behavior. Record the effective Product/option stock ownership and checkout rule; an out-of-stock label alone does not explain whether buying is permitted. For each relevant group price or quantity discount, retain its Customer context, threshold, priority, date range, and fallback alongside the amount.
| Commercial area | Evidence to prepare | Ready condition |
|---|---|---|
| Product and option prices | Product/option IDs, currency, regular/special values, dates, and price adjustments | Prices are attached to the correct sellable context. |
| Stock | Product/option quantity, stock status, availability rule, external owner, and synchronization key | The authoritative quantity and sellable-unit identity are known. |
| Taxes | Tax class/rate, geo zone, Product assignment, Customer context, and historical Order samples | Tax configuration is separated from historical tax amounts. |
| Coupons and discounts | Code/rule, value, dates, usage limits, Product/Category scope, and historical Orders | Active promotion rules and historical evidence are distinguishable. |
| Currency | Currency code, rate owner, decimal/rounding expectations, Product prices, and Order currency | Historical and current currency meanings are documented. |
| Quantity rules | Minimum/maximum quantity, packaging, step, bulk price, or custom logic | Quantity behavior is not hidden in notes or template code. |
If an ERP, supplier feed, marketplace, or accounting system owns price or stock, identify whether the EShop value is authoritative, synchronized, or only an opening snapshot.
Prepare Customers, Joomla Users, Addresses, Groups, and Reviews
EShop Customer preparation should connect Joomla users, EShop Customer records, guest buyers, billing and shipping addresses, custom checkout fields, company or tax identifiers, groups, reviews, wish lists, external IDs, and consent relationships where used.
| Account area | Evidence | Owner | Ready condition |
|---|---|---|---|
| Registered Customer | Joomla user ID, EShop Customer ID, email, status, addresses, group, and external IDs | Customer-data owner | Duplicate and cross-system identities have an intended treatment. |
| Guest buyer | Order-level identity, email, addresses, and Order references | Order-data owner | Guest history remains useful without creating an account. |
| Billing/shipping custom field | Field definition, required/display rules, stored values, and Order/Customer ownership | Customer-service owner | Custom Customer data is not lost or assigned to the wrong object. |
| Company/tax identity | Company, tax number, validation state, group, and external account key | Finance/B2B owner | Business identity has a named destination or retained owner. |
| Review or wish list | Product, Customer/guest identity, rating/text/status or wish-list relationship | Catalog/content owner | Customer-generated records remain connected to the correct Product and identity. |
| Authentication | Local password-verification method, SSO/social login, reset flow, and communication owner | Security owner | Customer-profile completeness and account access have separate readiness decisions. |
Include Customers with several addresses, guest Orders, group-based behavior, custom fields, reviews, wish lists, duplicate emails, and important external IDs. Record whether the exact Source-to-Target path can preserve usable password-verification continuity or requires reset, activation, or first-login handling. Identify any Joomla identity provider or group application that must continue, with a communication owner; copying profiles does not activate those dependencies.
Prepare Orders, Statuses, Payment, Shipping, Invoices, and Downloads
Historical EShop Orders should explain the transaction independently of current Store configuration. Prepare Order headers, Customer or guest identity, addresses, Product and option lines, attachments or downloadable items, quantities, prices, discounts, taxes, coupons, currency, payment, shipping, statuses, comments, invoices, refunds or adjustments, and external references.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and status history | Commerce operations | Customer/guest, dates, currency, status sequence, and source channel are documented. |
| Product and option lines | Catalog/order owners | Product IDs, option values, SKU, quantity, price, tax, and snapshot text are complete. |
| Totals and adjustments | Finance owner | Subtotal, discount, coupon, tax, shipping, payment fee, currency, and final total reconcile. |
| Payment and shipping | Finance/fulfillment owners | Historical method labels, transaction/tracking IDs, carrier, and provider ownership are known. |
| Invoice and downloadable access | Finance/digital-fulfillment owners | Invoice numbers/files, Product downloads, limits, and Order relationships are recoverable. |
| Refund/return context | Finance/customer-service owners | Amounts, affected lines, dates, reasons, statuses, and external references are documented. |
| External Order IDs | Integration owner | ERP, accounting, marketplace, or fulfillment keys remain traceable. |
Choose ordinary, guest, option-heavy, discounted, multi-tax, multilingual, downloadable, refunded, and tracked Orders where those patterns exist. Preserve the SKU actually recorded on the purchased line and its Product and option-value links. Some EShop builds form the displayed purchase SKU from the main SKU and selected option SKU components; record that behavior separately from stored history rather than generating replacement historical identities.
Historical prices, discounts, taxes, and totals remain transaction snapshots. Record how target notifications, payment callbacks, stock updates, and digital-access events will be controlled so an imported historical status does not replay the original transaction.
Prepare Joomla Menus, Multilingual Content, URLs, Media, and Presentation
EShop commerce records can be exposed through Joomla menus, modules, templates, product/category/manufacturer routes, search modules, language associations, media, and metadata. These relationships should be inventoried separately from Product data.
| Storefront area | Evidence | Ready condition |
|---|---|---|
| Product, Category, and manufacturer URLs | Source route, alias, record ID, menu context, language, metadata, and destination intent | Priority routes have one keep, change, merge, retire, or redirect decision. |
| Joomla menus and modules | Menu item type, parent, alias, language, access, module position, filters, and selected data types | Store entry points and discovery dependencies are documented. |
| Multilingual records | Product/Category/manufacturer associations, translated options/attributes, menus, metadata, and fallback | Translations are not treated as unrelated duplicates. |
| Templates and overrides | Template, EShop layouts, module chrome, custom tabs, and affected routes | Presentation dependencies are separated from commerce records. |
| Product media and attachments | Images, thumbnails, videos, attachments, downloads, remote storage, and file permissions | Priority assets remain available and linked correctly. |
| SEO and redirects | Metadata owner, SEF/routing extension, sitemap source, redirect rules, and high-value URLs | URL continuity has an explicit owner. |
The broader Joomla scope owns general CMS Articles and Pages. EShop preparation captures only the Joomla structures that materially affect commerce records and routes.
Inventory Addons, Payment and Shipping Plugins, Custom Data, and External Systems
Build a dependency ledger for EShop addons, payment plugins, shipping plugins, search/filter modules, import/export tools, templates, custom fields, CRM, ERP, accounting, fulfillment, marketplaces, analytics, and bespoke code.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| EShop addon/plugin | Name, version, purpose, configuration, owned records, and related Product/Customer/Order IDs | Extension-owned records have a destination or retained owner. |
| Payment/shipping plugin | Provider, stored transaction/tracking data, statuses, and historical Order dependencies | Historical references are separated from live plugin configuration. |
| Import/export workflow | File format, columns, identifiers, option/attribute relationships, and last successful run | Extracted records can be reconciled with database evidence. |
| Custom field/table | Schema, keys, business purpose, and consuming code | Custom records can be interpreted rather than copied blindly. |
| External system | Endpoint, authoritative data types, synchronization direction, IDs, and cutover owner | Cross-system identity and authority are documented. |
| Generated data | Caches, logs, sessions, temporary exports, indexes, and abandoned records | Non-authoritative technical data is excluded deliberately. |
Inactive extensions should remain in the ledger when they created records still required for Orders, Customers, Products, downloads, or reporting.
Confirm EShop Target implementation prerequisites
The intended Joomla/EShop environment must support the agreed buyer choices, account links and file-access meaning. Recovering an option label or download file does not provide a compatible field consumer or purchased entitlement. The Target owners should settle those relationships and the required plugins before execution, keeping the broader Joomla CMS design in its own scope.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended build and access | Target technical owner | Joomla/EShop build, administration, compatible required addons/plugins, hosting/storage access and recovery responsibilities | The intended installation and required components are available to their owners. |
| Prepare catalog choices and purchased-file access | Target catalog and digital-fulfillment owners | Actual option behavior and identities, SKU decisions, attributes/fields, Product attachments, purchased downloads, file links and Order-access limits | Buyer choices and descriptive fields remain distinct; public attachments and purchased resources have agreed separate access treatment. |
| Prepare account and commerce-route consumers | Target identity and site owners | Joomla/Customer/guest links, groups, authentication decision, languages, menu/module routes, media, templates and field consumers | Required identity and commerce presentation relationships have usable destination consumers without absorbing the general Joomla CMS scope. |
| Assign plugins and live operating responsibilities | Target plugin, operations and integration owners | Future payment, shipping, tax, notification, stock and digital-access behavior; historical references, continuing external keys and containment decisions | Historical records remain snapshots and cannot replay charges, messages, stock changes or digital-delivery events; continuing operations have owners. |
Select Representative Migration Test Samples
Record source IDs, SKUs, URLs, language, related records, external keys, and the reason for each sample.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, stock, tax, Category, manufacturer, media, and Order | Establishes the baseline for an ordinary EShop Product and its commercial context. |
| Option-heavy Product | Options/values, separate SKUs/prices/images, stock behavior, attributes, and Order line | Represents buyer-choice and sellable-option relationships. |
| Attribute/custom-field Product | Attribute groups, custom fields, attachments, tabs, filters, and Product route | Represents descriptive and extended Product data. |
| Registered Customer and guest Order | Joomla/Customer IDs, addresses, groups, custom fields, and external IDs | Represents both Customer identity models. |
| Complex Order | Option lines, coupon, tax, currency, payment, shipping, invoice, refund, download, and external reference | Represents historical commercial context. |
| Multilingual route | Associated Products/Categories, translated options, aliases, menus, metadata, and redirect intent | Represents Joomla language and routing dependencies. |
| Extension-owned record | Core record or data type, add-on/plugin owner, custom table/field, and external key | Exposes non-core scope before execution. |
Representative migration test preparation defines the samples and source evidence. Each sample needs original values, linked records, the intended target representation, agreed exclusions, and a reviewer. A digital Product sample should show the file, purchased-access relationship, and limits separately from a freely available attachment. Later target proof and launch interpretation belong to validation.
Complete the Final EShop Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Actual Source access, available database/files/download backups or exports, recovery coverage, limits and owner are confirmed. Required records and purchased files are recoverable under that method; intended Joomla/EShop prerequisites are assessed separately. |
| Catalog | Products, Categories, manufacturers, options, attributes, custom fields, attachments, media, stock, prices, and identifiers are documented. |
| Customers | Joomla users, Customers, guests, addresses, groups, custom fields, reviews, wish lists, and authentication dependencies are classified. |
| Orders | Lines, options, totals, statuses, payment, shipping, invoices, downloads, refunds, and external IDs have evidence. |
| Storefront | Menus, modules, languages, templates, routes, media, SEO, and redirects are documented. |
| Dependencies | Addons, plugins, imports, custom code, external systems, and authoritative owners are recorded. |
| Samples | Representative records cover every material Product, Customer, Order, route, download, and extension pattern. |
| Target prerequisites | The intended Joomla/EShop build, buyer-choice and file-access representation, account/routes, compatible plugins/field consumers, access and live-operation containment owners are confirmed. |
The EShop scope is ready when each material record has a source owner, relationship map, evidence artifact, and intended destination or retained-system decision, with the required destination plugins and field consumers confirmed. Resolve missing option identity, purchased-file access, Customer links, or other required dependencies; agree an explicit exclusion; or hold the affected scope. An owner and future date alone are insufficient. Document the boundary, impact, and owner of accepted noncritical exceptions.
Approve the preparation scope only when the actual Source evidence and intended Target consumers support the same agreed relationships. A missing purchased-file entitlement, option identity or required field consumer remains a scope gap even if the file or Product is present. Resolve it, agree an explicit exclusion or hold the affected work before execution; later validation owns proof of the migrated outcome.
Conclusion
EShop preparation requires coordinated evidence across Joomla, Products, options, attributes, custom fields, attachments, Customers, Orders, taxes, shipping, payment, currencies, multilingual routes, plugins, and external systems. These relationships cannot be represented reliably through a flat Product or Order export alone.
A complete EShop readiness package preserves recoverable evidence, identifies authoritative records, separates historical transactions from current configuration, and resolves the ownership of every material dependency.
Carry the evidence package, intended Target decisions and any held scope into EShop 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 an EShop migration?
Identify the actual Source Store and intended EShop destination build. Secure source records, media, downloads, and recovery evidence before detailed catalog work. When EShop is the Source, include Joomla, EShop, hosting, database, filesystem, plugins, and integrations; separately confirm the destination versions and required enabled extensions.
What is the difference between EShop options and attributes during preparation?
Options represent buyer selections and may carry SKU components, price adjustments, images, or quantities depending on the type and configuration. They do not automatically define independently stocked combinations. Attributes describe Product characteristics and can support comparison or filtering. Preserve their definitions, assignments, and actual commercial behavior separately.
Why should Product attachments and extra tabs be inventoried?
Product-page attachments can contain manuals, specifications, or supporting files, while extra tabs contain Product-specific content. Preserve their files, definitions, assignments, and display purpose. Purchased downloads need separate Order-access evidence, so copying only the main description or file archive cannot settle both requirements.
How should Customer and guest identities be prepared?
Record Joomla user and EShop Customer links, emails, addresses, groups, custom checkout fields, external IDs, and Order relationships. Guest history should remain Order-level evidence rather than being forced into new accounts.
Which EShop Orders should be selected as representative samples?
Include ordinary and guest Orders, Products with options, discounts, coupons, multiple taxes or currencies, downloads, invoices, refunds or adjustments, tracking, and external references used by operations or finance.
How should Joomla and EShop preparation be divided?
Joomla preparation owns general CMS content, users, menus, modules, templates, and access architecture. EShop preparation owns commerce Products, options, Customers, Orders, pricing, stock, and extensions while documenting only the Joomla dependencies required by those records.
Are Product attachments and purchased downloads the same preparation scope?
No. A Product attachment can be available to shoppers from the Product page, while a purchase download depends on its Product, Order, file, and access limits. Inventory both even when they use similar files. Prepare the intended access and ownership separately so recovering a file does not accidentally make a purchased resource public.
Should option Orders be assigned newly generated SKUs during preparation?
Preserve the purchased SKU and original Product and selected-option links first. Record how the installed EShop build constructs current purchase SKUs and how downstream systems interpret them. Any normalization needs an explicit source-to-intended identity decision; current SKU generation is not a reason to rewrite historical Order evidence.