An EasyStore migration needs evidence of the item being sold and the Joomla experience that will make it usable. A parent Product file can omit the variant, image or buyer relationship that a required workflow depends on.
Prepare the actual Source records and recovery evidence first. Establish intended EasyStore, Joomla and presentation prerequisites separately. Each required input needs an owner, an obtainable evidence artifact and an explicit ready condition before execution.
Source access, evidence and recovery
Identify the actual Source Platform and the intended Joomla/EasyStore environment separately. An EasyStore destination does not make the Source a Joomla installation. Record source versions, available access and recovery methods, then establish the compatible Target build and its owners.
| Action | Owner | Evidence to collect | Ready condition |
|---|---|---|---|
| Inspect selected records | Actual Source administrator | Working roles and access to required records, fields and relationships. | The agreed source scope is inspectable; EasyStore/Joomla access is required only when that is the actual Source. |
| Secure recovery evidence | Source recovery or platform owner | Available backups/exports, media, extraction date, included areas, exclusions and recovery route. | Required evidence is recoverable; full-store restoration limits are explicit. A Product archive is not a site backup. |
| Record components | Source technical owner | Actual source software, extensions, templates, modules and commerce dependencies. | Each dependency has an owner; intended Joomla/EasyStore compatibility is assessed separately. |
| Capture customizations | Source development owner | Overrides, snippets, custom addons, APIs/webhooks, direct database changes and code consuming records where present. | The business purpose and data interpretation are understood; target replacements have separate decisions. |
| Map connected systems | Continuing integration owners | ERP/PIM/WMS/CRM, accounting, fulfillment and marketplace endpoints, keys and authority. | Continuing systems, update directions and intended Target writers are identified. |
For an EasyStore Source with suitable access, retain database, filesystem and media backups alongside the Joomla, EasyStore, SP Page Builder, template, plugin, payment and shipping inventory. Another hosted Source may provide exports and managed recovery instead. Record what its method can actually restore; do not assume database or filesystem access.
Protect dated evidence for source Products, variants, Categories, tags, brands, collections, Customers, Orders, coupons, reviews, refunds, media and external identifiers. Include Joomla user and menu IDs only where that Source uses them. Resolve required recovery gaps, explicitly exclude affected scope by agreement, or hold it.
Prepare Products, Variants, Categories, Brands, and Collections
Prepare Products by selling behavior. Preserve identity, content/media, pricing, tax, inventory and logistics inputs, then record the classification, merchandising, access and metadata relationships that the intended store needs. Native EasyStore fields do not establish complete coverage for the selected migration path.
| Product pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple Product | Product ID, SKU, price, discount, tax state, stock, Category, brand, images, and sample Order | One record clearly identifies the item sold. |
| Variant Product | Variation types/values, generated variants, per-variant SKU, price, discount, stock, weight, package, image, and visibility | Every real sellable combination is traceable to its parent and selected values. |
| Out-of-stock or preorder Product | Stock status, continue-selling state, release date, quantity, and responsible inventory system | Availability meaning is not reduced to a blank or zero quantity. |
| Multi-Category or collection Product | Category, tag, brand, collection, and campaign relationships | Discovery and merchandising structures are not collapsed into one taxonomy. |
| Specification-heavy Product | Additional-data keys/values, display purpose, search/filter use, and Product assignments | Descriptive specifications remain separate from variants. |
| Upsell/cross-sell Product | Source Product, linked Products, relationship type, and priority | Merchandising links are preserved separately from Categories. |
Record unpublished, featured, sale, restricted-access, minimum/maximum quantity, continue-selling, identifier, and metadata cases. These states may require different destination treatment.
Prepare Variant Libraries, Product Options, Pricing, and Inventory
EasyStore variation types can be reused across Products, while generated variants carry the price, stock, identifiers, weight, package, and visibility settings used for those combinations. Prepare the actual variant records and their selected values before changing the matrix. Product Options also holds upsell and cross-sell links; Additional Data describes specifications. Those three structures need different relationship evidence.
For Products with variations, EasyStore moves pricing and inventory work to the variants. Base Unit and Cost Per Unit settings are not available for that variation model. If the Source Store relies on unit comparisons or cost reporting for variant families, record the requirement and its intended destination owner before declaring that family ready.
| Structure | Evidence | Ready condition |
|---|---|---|
| Variation type and values | Name, display type, values, color data, ordering, and Product assignments | Reusable variant vocabulary is documented. |
| Generated variant | Parent Product, selected values, SKU, GTIN/UPC/EAN/ISBN, price, discount, stock, weight, package, image, visibility, and external key | Every purchased combination has independent evidence. |
| Product-level pricing | Regular price, discount type/value, tax state, base-unit data, cost, and currency | Parent-level values are not substituted for variant-specific values. |
| Inventory | Product/variant quantity, track state, stock status, continue-selling rule, min/max quantity, and external owner | The authoritative sellable quantity is known. |
| Additional Data | Key, value, Product assignments, display purpose, and external source | Specifications remain separate from buyer choices. |
| Upsell/cross-sell | Relationship type, linked Product IDs, Categories/collections/brands used for selection | Merchandising relationships are traceable. |
If the source catalog contains large option matrices, preserve the real combination count, original IDs, selected values, and relevant environment limits in the technical evidence. Do not generate missing combinations merely to make the matrix look complete. Record whether stock is tracked as a quantity or represented by a manual availability status, together with the continue-selling rule and any external inventory authority. A zero quantity and an untracked stock state need different interpretations.
Prepare Customers, Joomla Users, Addresses, Reviews, and Identity
EasyStore Customers can be connected to Joomla users, Orders, addresses, reviews, company or tax data, consent, and external CRM or ERP identifiers. Guest buyers need separate treatment because their Order history can remain useful without a persistent account.
- Registered Customer. Evidence: Actual Source Customer/account IDs, email, status, addresses and external IDs; Joomla/EasyStore IDs where present Owner: Customer-data owner Ready condition: Duplicate and cross-system identities have an intended treatment.
- Guest buyer. Evidence: Order-level identity, email, addresses, and Order links Owner: Order-data owner Ready condition: Guest history is preserved without inventing a user account.
- Address. Evidence: Billing/shipping values, country/state, default state, and Customer/Order ownership Owner: Customer-service owner Ready condition: Saved addresses and historical Order snapshots are distinguishable.
- Review. Evidence: Product, Customer/guest identity, rating, text, status, date, and language Owner: Catalog/content owner Ready condition: Reviews remain attached to the correct Product and moderation state.
- Company/tax information. Evidence: Company, tax number, validation state, and external account key Owner: Finance/B2B owner Ready condition: Business identity has a named destination or retained owner.
- Authentication. Evidence: Local password-verification method, SSO/social login, reset flow, and communication owner Owner: Security owner Ready condition: Customer-profile completeness and account access have separate readiness decisions.
Select Customers with multiple addresses, guest Orders, reviews, duplicates, important external IDs, and high-value Order histories. Record the exact Source-to-Target authentication decision: an explicitly supported path may preserve usable password-verification continuity; another path may require reset, activation, or first-login handling. Keep credentials out of the evidence ledger and assign the communication and identity-provider dependencies to their owners.
Prepare Orders, Coupons, Refunds, Taxes, Shipping, and Payment Evidence
Historical evidence from the actual Source must explain what was purchased and what happened. Use the following inventory to prepare useful history for the intended EasyStore result, including invoices and notes where required by scope.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and status history | Commerce operations | Customer/guest, dates, status sequence, currency, and source channel are documented. |
| Product and variant lines | Catalog/order owners | Parent Product, variant, SKU, selected values, quantity, and snapshot text are complete. |
| Coupons and discounts | Marketing/finance owner | Coupon code, rule, line/order discount, and historical effect are documented. |
| Tax and shipping | Finance/fulfillment owners | Historical tax amounts, shipping charge, method label, carrier, and tracking are retained. |
| Payment context | Finance owner | Method label, transaction/reference IDs, status, and provider ownership are known. |
| Refunds and adjustments | Finance/customer-service owners | Partial/full refund amounts, affected lines, dates, reasons, and external references are documented. |
| External Order IDs | Integration owner | ERP, accounting, marketplace, or fulfillment identifiers remain traceable. |
Live coupon, tax, shipping, payment, checkout, and refund processing belongs to target configuration. Historical Orders preserve the purchased values, labels, amounts, and references from the transaction; do not recalculate them from current rules. The destination owner must also prevent historical imports or representative tests from triggering unintended customer notifications, charges, stock changes, or fulfillment work.
Prepare Joomla Menus, SP Page Builder, Routes, Media, and SEO
EasyStore Products can be displayed through Joomla menu items and SP Page Builder addons. Menus, page-builder layouts, template positions, Product blocks, media, metadata, and redirects therefore need explicit preparation evidence.
| Storefront area | Evidence | Ready condition |
|---|---|---|
| Product and Category routes | Source URL, alias, Product/Category ID, menu context, metadata, and destination intent | Priority commerce routes have one keep, change, merge, retire, or redirect decision. |
| Joomla menu items | Menu item type, parent, alias, language, access, selected Category, and hierarchy behavior | Store entry points and Category views are documented. |
| SP Page Builder layouts | Page ID, EasyStore addon types, filters, Product sources, custom styling, and linked routes | Presentation dependencies are separated from commerce records. |
| Product media | Images, video, alt context, variant media, remote assets, and file paths | Priority media can be traced to the correct Product or variant. |
| Connected CMS content | Landing pages, buying guides, Blog Posts, internal links, Product blocks, and campaigns | Commerce-linked content has an owner and route decision. |
| SEO and redirects | Metadata owner, canonical data, sitemap source, redirect rules, and high-value URLs | Route continuity has an explicit owner. |
The general Joomla CMS inventory belongs to the Joomla scope. EasyStore preparation captures the Joomla and SP Page Builder relationships needed by commerce data and routes. Record which layouts consume each Product field or filter and which addon belongs to Storefront, Single Product, or Collections. A Single Product-only addon cannot be assumed to work in a Storefront layout.
Inventory Extensions, Custom Data, Imports, and External Systems
Build a dependency ledger for payment, shipping, tax, reviews, analytics, import/export, SP Page Builder addons, custom fields, ERP, PIM, CRM, accounting, fulfillment, and marketplace connections.
- EasyStore extension/integration. Evidence to prepare: Name, version, purpose, configuration, owned records, and related core IDs Ready condition: Extension-owned records have an intended destination or retained owner.
- SP Page Builder addon. Evidence to prepare: Addon type, page/layout IDs, Product source, filters, and custom code Ready condition: Presentation structures are not mistaken for Product data.
- Import/export workflow. Evidence to prepare: File format, column definitions, Product/variant identifiers, relationships, and last successful run Ready condition: Exported files can be reconciled with the authoritative database records.
- Custom field/table. Evidence to prepare: Schema, keys, business purpose, and consuming code Ready condition: Custom values can be interpreted rather than copied blindly.
- External system. Evidence to prepare: Endpoint, authoritative entities, synchronization direction, IDs, and cutover owner Ready condition: Cross-system identity and authority are documented.
- Generated data. Evidence to prepare: Caches, logs, sessions, indexes, abandoned imports, and temporary files Ready condition: Non-authoritative technical data is excluded deliberately.
Inactive extensions remain relevant when their records still support Orders, Products, Customers, refunds, or reporting. For imports, preserve the actual field set, SKU identity rules, media archive, and extraction date. Matching SKUs can update existing EasyStore Products, so any intended reuse, correction, or collision must have a recorded decision before an import is treated as a safe input. A supported field does not by itself establish agreed migration coverage.
Confirm EasyStore Target implementation prerequisites
The intended Joomla/EasyStore environment needs its own build and ownership decisions. Source variation records, Joomla identities and commerce-linked layouts do not establish that the destination can consume them. Confirm the catalog model, compatible components and presentation dependencies before execution, while keeping general Joomla CMS preparation with its own scope.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended environment and access | Target technical owner | Joomla/EasyStore build, administration, required extensions, hosting/storage access and recovery responsibilities | The intended installation and compatible required components are available to their owners. |
| Prepare variant and account representation | Target catalog and identity owners | Variation types/values, real generated combinations, per-variant price/stock/media, account links and path-specific authentication decision | Selected catalog and identity relationships have an agreed usable representation; unavailable unit/cost requirements have a replacement, retained owner or agreed exclusion. |
| Confirm commerce presentation consumers | Target site and layout owners | Required SP Page Builder addons/layout contexts, Joomla menu routes, Product sources, media, filters and custom code | Required layouts can consume the selected records in the intended context; Product data alone does not establish presentation readiness. |
| Assign live operation and integration owners | Target operations and integration owners | Future payment, shipping, tax, coupon, refund, notification and stock behavior; external identifiers and writer/containment decisions | Live behavior and continuing systems have owners, with historical/test records isolated from unintended charges, notifications, stock changes or fulfillment. |
Select Representative Migration Test Samples
Record source IDs, SKUs, URLs, related records, external keys, and the reason for each sample.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, tax, stock, Category, brand, images, and Order | Establishes the ordinary Product baseline. |
| Variant Product | Variation library, generated variants, SKUs, prices, stock, images, visibility, and Order line | Represents parent–variant relationships. |
| Specification/merchandising Product | Additional Data, tags, brand, collection, upsell/cross-sell, and Product route | Represents descriptive and merchandising structures. |
| Registered Customer and guest Order | Actual Source Customer/account IDs, addresses, reviews, Order links and external IDs; intended Joomla/EasyStore identity links separately | Represents both identity models. |
| Complex Order | Variant line, coupon, tax, shipping, payment, refund, tracking, and external reference | Represents historical commercial context. |
| SP Page Builder route | Page/layout, EasyStore addons, Product source, menu link, media, SEO, and redirect intent | Represents presentation and routing dependencies. |
| External-system record | Product/variant/Customer/Order ID, authoritative system, sync direction, and key | Exposes integration ownership before execution. |
Representative migration test preparation owns sample selection and evidence. Each sample should include the related records, original values, intended target representation, expected exclusions, and reviewer. A variant sample, for example, needs its selected values, individual SKU, stock mode, media, and purchased Order line, rather than only the parent Product. Actual migrated proof and launch interpretation belong to validation.
Complete the Final EasyStore Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Actual Source access, available database/files/media backups or exports, recovery coverage, limits and owner are confirmed. Required evidence is recoverable under that method; intended Joomla/EasyStore prerequisites are assessed separately. |
| Catalog | Products, variants, Categories, tags, brands, collections, specifications, media, pricing, stock, and identifiers are documented. |
| Customers | Actual Source buyer/account identities, guests, addresses, reviews, company/tax data and authentication dependencies are classified; intended Joomla/EasyStore account relationships are defined separately. |
| Orders | Lines, variants, discounts, coupons, taxes, payment, shipping, refunds, tracking, and external IDs have evidence. |
| Storefront | Menus, SP Page Builder layouts, routes, media, connected content, SEO, and redirects are documented. |
| Dependencies | Extensions, imports, custom data, external systems, and authoritative owners are recorded. |
| Samples | Representative records cover every material Product, Customer, Order, route, refund, and integration pattern. |
| Target prerequisites | The intended Joomla/EasyStore build, catalog/account representation, compatible extensions, SP Page Builder consumers, access and live-operation containment owners are confirmed. |
The EasyStore scope is ready when each selected record can be traced to its source owner, related records, evidence artifact, and intended destination or retained system, and the required destination consumers are available. Resolve a missing required variant, media asset, identity link, or layout dependency; explicitly exclude the affected requirement by agreement; or hold that scope. Assigning an owner and deadline alone does not make a critical gap ready. Any accepted noncritical exception should state its boundary, impact, and owner.
Readiness requires both recoverable Source relationships and an intended Target that can use them. Neither can replace the other. A missing required layout, identity link or variant input remains a hold until resolved or explicitly excluded from the agreed scope.
Conclusion
Prepare an EasyStore move with recoverable Source evidence, traceable catalog and buyer relationships, readable transaction history and usable Target prerequisites. Record the selected samples and the people who can explain their required meaning.
Preparation establishes what must be available before execution. It does not certify migrated output. Carry the evidence package, intended Target decisions and any held requirements into EasyStore validation priorities.
Common Questions
What should be prepared first for an EasyStore migration?
Identify the actual Source Store and the intended EasyStore destination environment. Secure access to source records, media, and recovery evidence, then record the destination build, compatible extensions, and owners. When EasyStore is the Source, that includes Joomla, EasyStore, hosting, database, filesystem, SP Page Builder, and integrations.
Why do EasyStore variants need separate evidence from the parent Product?
Each variant can carry its own SKU, standardized identifier, price, discount, stock, weight, package, visibility, and image relationship. Parent-only evidence can therefore omit the actual sellable records.
How should Categories, brands, collections, and tags be prepared?
Document each structure independently, including Product assignments and storefront use. Similar labels do not prove that the structures serve the same discovery or merchandising purpose.
What Order evidence should be collected?
Prepare Product and variant lines, Customer or guest identity, addresses, discounts, coupons, taxes, payment and shipping context, statuses, tracking, refunds, and external IDs used by support or finance teams.
Why should SP Page Builder be included in preparation?
EasyStore addons can select and display Products, Categories, filters, reviews, prices, and cart functions inside page layouts. The layouts and data sources are presentation dependencies, not ordinary Product fields.
How should Joomla and EasyStore preparation be divided?
Joomla preparation owns general CMS content, users, menus, templates, and extensions. EasyStore preparation owns Products, variants, Customers, Orders, refunds, coupons, reviews, and commerce integrations while documenting only the Joomla dependencies required by them.
Does an EasyStore Product export replace a full preparation archive?
No. The Product export packages catalog CSV data with associated media, and its variation fields depend on configuration. Check the actual field set and relationships against the required scope. Customers, Orders, Joomla routes, layouts, integrations, and recovery evidence need their own artifacts; do not infer complete coverage from the presence of a Product ZIP.
How should Base Unit and Cost Per Unit requirements be prepared for variant Products?
EasyStore does not provide those settings for Products with variations. Preserve the source unit-comparison and cost-reporting requirements, identify the compatible destination representation or retained reporting owner, and settle the affected scope before execution. Do not treat parent values as proof that the variant family can preserve that behavior.