Before migrating into EShop, collect the records that explain a purchase in the actual Source Store. The Product export is one part of that evidence. Selected options, buyer addresses and purchased files may have different evidence owners and recovery methods. Record the actual Source storefront paths separately from the intended Joomla commerce routes.
Prepare two sets of evidence: what can be recovered from the actual Source Store, and what must be ready in the intended EShop destination. For each requirement, identify who can supply it and what must be available before execution.
Source access, evidence and recovery
Identify the actual Source Platform separately from the intended Joomla/EShop destination. Record available source access and recovery methods, then confirm the compatible Target build, required plugins 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; extraction date and documented recovery route | 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, durable keys, data authorities, writers, consumers and update directions are known. | Actual Source and continuing external IDs and authorities. Target endpoints, keys and synchronization responsibilities are assigned independently. |
For an EShop Source with suitable access, preserve dated database, filesystem, Product media, attachment and purchase-download archives, including scheduled processes and plugin/integration evidence. Extend recovery coverage to remote assets and the actual hosting arrangement. Before cleanup, secure the required recovery evidence and settle any scope exclusions or holds.
Preserve source identifiers for Products, Categories, Manufacturers, options/values, attributes, custom fields, Customers, Orders/lines, status, tax, shipping, payment, files, languages and external systems where present. A recoverable file does not establish its Product or purchase-access relationship.
Use migration scope planning when deciding what must move, what can change and what remains in a retained system.
Catalog records and selling rules
Prepare Products, Categories, Manufacturers, Media, and Attachments
Prepare Products by selling behavior and commercial importance. Preserve identity, descriptions, metadata and media, then trace choice, price, stock, logistics, discovery and file-access relationships. Native fields do not establish complete transfer coverage for the selected path.
| Product pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple physical Product | Product ID, SKU, price, tax, stock, weight, dimensions and units where used, 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.
The EShop risk analysis explains why a choice, specification and paid file cannot be treated as interchangeable fields.
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.
Customers and commercial history
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.
| Case | Evidence | Owner | Ready condition |
|---|---|---|---|
| Registered Customer | Actual Source Customer/account IDs, email, status, addresses, groups and external IDs; Joomla/EShop IDs where used | 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 the intended Joomla/EShop account relationships separately from Source evidence. 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
Prepare history from the actual Source so it explains the transaction independently of current EShop configuration. The inventory below covers buyer/address snapshots, purchased choices, amounts, documents, digital access and operational references where required by scope.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and status history | Commerce operations | Customer/guest, dates, currency, status sequence, comments, 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, required Source Order attachments where present, 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.
Joomla presentation and continuing dependencies
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.
For an EShop Source, inventory the native Joomla structures where present. For another Source, capture its actual URLs, content, language and discovery relationships; use the Joomla rows below to define intended Target requirements and owners. Keep Source evidence and Target intentions distinct in the representative multilingual sample as well.
| 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.
| Case | 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 reconcile with available authoritative Source evidence: database records where accessible, or the platform’s supported exports and reports otherwise. |
| 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
Before execution, the Target owners need a compatible Joomla/EShop build, the required plugins and agreed destinations for buyer choices, account links and file access. Confirm which field, module or extension will use each value and how purchased files will stay tied to the buyer’s Order. Keep general Joomla CMS design outside this commerce 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 | Import handling is defined to preserve historical snapshots and prevent unintended charges, messages, stock changes or digital-delivery events; continuing operations have owners. |
For the migration direction and available starting scope, consult the EShop migration landing page. Resolve supported controls and any tailored handling through the EShop approach guide before committing execution work.
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 | Actual Source account/Customer IDs, addresses, groups, fields and external IDs; intended Joomla/EShop identity links separately | 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 | Actual Source buyers/accounts, guests, addresses, groups, fields, reviews, wish lists and authentication dependencies are classified; intended Joomla/EShop identities are defined separately. |
| 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. |
Approve the preparation scope when Source evidence and the intended Target setup agree on each required relationship. Each material record needs a source owner, relationship map, evidence artifact and intended destination or retained-system decision, with required plugins and fields available to the systems that use them.
Resolve missing option identity, purchased-file access, Customer links or other required dependencies; agree an explicit exclusion; or hold the affected work before execution. An owner and future date alone are insufficient. Document the boundary, impact and owner of accepted noncritical exceptions.
Conclusion
Prepare an EShop move with recoverable Source evidence, traceable purchase choices, useful buyer and Order history, and an intended Target that can consume those relationships. Public attachments, purchased Downloads, option identity and live stock policy deserve distinct decisions.
The readiness package defines what must be available before execution. It does not approve migrated output. Carry the evidence, intended Target decisions and held scope into EShop validation priorities.
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 actual Source account/Customer identifiers, emails, addresses, groups, checkout fields, external IDs and Order relationships. Define intended Joomla user and EShop Customer links separately; use them as source identifiers only where present. 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.