An EasyStore by JoomShaper migration is better prepared when the team can explain both the item being sold and the Joomla page that presents it. A variant with correct stock is still an incomplete input if its image, Customer context, or storefront route cannot be traced. Preparation should turn those dependencies into a recoverable evidence package before execution.
EasyStore preparation must connect commerce records to the Joomla and JoomShaper structures that present and manage them. Products can depend on variants, Categories, tags, brands, collections, images, inventory, coupons, reviews, Customers, Orders, refunds, Joomla menu items, SP Page Builder layouts, payment and shipping integrations, and external systems.
EasyStore preparation should connect every required action to an accountable owner, a recoverable evidence artifact, and an explicit ready condition. It should preserve source facts without treating live checkout, payment, shipping, tax, notification, or page-builder behavior as migrated records.
Source access, evidence and recovery
Identify the actual Source Platform and the intended Joomla, EasyStore, and SP Page Builder environment first. If the Source Store already uses EasyStore, confirm access to its administration, hosting, database, filesystem, Product media, scheduled tasks, and integrations. Otherwise collect equivalent evidence from the Source Platform; do not assume it has EasyStore records or Joomla access. Record the source versions and separately confirm the intended destination build, compatible extensions, enabled features, access roles, and implementation owners.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; Joomla/EasyStore administrator when EasyStore is the Source | Working accounts and role summary | For an EasyStore Source, Products, variants, Customers, Orders, coupons, reviews, and configuration are inspectable. Another Source provides access to its own selected records. | Actual Source administration. Joomla/EasyStore access applies when the Source uses that installation; intended Target administration is confirmed separately. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Available actual Source backups or exports, filesystem/media files, coverage, limits and recovery owner; for an EasyStore Source with the required access, database export and filesystem/media archive | Required evidence is recoverable under the declared Source method, with any full-Store restoration limits explicit. Required recovery gaps are resolved, explicitly excluded by agreement or held. | Actual Source recovery capability. Another hosted Source may provide exports and managed recovery rather than database/filesystem access; a catalog archive is not proof of full Store restoration. |
| Record the extension environment | Source technical owner; Target build owner separately | Actual Source software/components; for an EasyStore Source, Joomla, EasyStore, SP Page Builder, template, plugin, module, payment, and shipping inventory | Every commerce dependency has an owner. | Source component inventory. Native Joomla/EasyStore/SP Page Builder versions apply only when used by that Source; intended Target compatibility is assessed separately. |
| Capture customizations | Source development owner; Target customization owner separately | Actual Source customizations and consuming code; where present, custom addons, template overrides, snippets, API/webhook code, and direct database changes | Custom behavior that creates or interprets records is documented. | Actual Source behavior and record ownership. Intended EasyStore addons, overrides and replacement consumers require their own Target decisions. |
| Map connected systems | Source and continuing integration owners | ERP/PIM/WMS/CRM/accounting/fulfillment/marketplace endpoints and external IDs | Continuing systems and data authorities are known. | Actual Source and continuing external identities and authorities. Target endpoints, stock writers and synchronization responsibilities are assigned independently. |
Protect the actual Source evidence with the recovery method that is available in that environment. Record the extraction or backup date, included records/files, missing areas, recovery route and owner. Keep database and filesystem/media backups where an EasyStore Source permits them, but do not ask another hosted Source for Joomla infrastructure access. A Product archive may recover catalog evidence without restoring Customers, Orders, routes, layouts or the whole Store. Resolve a required recovery gap, agree an explicit exclusion or hold the affected scope.
Preserve Product, variant, Category, tag, brand, collection, Customer, Order, coupon, review, refund, media, Joomla user, menu, and external IDs where they exist in the Source Store. Keep the evidence archive dated and protected, with database and file coverage, remote assets, and a restoration owner. Confirm that the recovery method covers the actual source environment; a catalog export is a narrower artifact than a recoverable site backup.
Prepare Products, Variants, Categories, Brands, and Collections
EasyStore Products can contain names, aliases, descriptions, images, video, prices, discounts, costs, tax state, identifiers, stock, dimensions, Categories, tags, brands, collections, specifications, upsell/cross-sell links, access, metadata, and variants. Prepare Products by selling behavior rather than count.
| 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.
| Account area | Evidence | Owner | Ready condition |
|---|---|---|---|
| Registered Customer | Joomla user ID, EasyStore Customer ID, email, status, addresses, and external IDs | Customer-data owner | Duplicate and cross-system identities have an intended treatment. |
| Guest buyer | Order-level identity, email, addresses, and Order links | Order-data owner | Guest history is preserved without inventing a user account. |
| Address | Billing/shipping values, country/state, default state, and Customer/Order ownership | Customer-service owner | Saved addresses and historical Order snapshots are distinguishable. |
| Review | Product, Customer/guest identity, rating, text, status, date, and language | Catalog/content owner | Reviews remain attached to the correct Product and moderation state. |
| Company/tax information | Company, tax number, validation state, and external account key | Finance/B2B owner | Business identity has a named destination or retained owner. |
| 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. |
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 EasyStore Orders should explain what was purchased and what happened. Prepare Order headers, Customers or guests, addresses, Product and variant lines, quantities, prices, discounts, coupons, taxes, shipping, payment labels, statuses, notes, tracking, refunds, invoices, and external references.
| 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.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| EasyStore extension/integration | Name, version, purpose, configuration, owned records, and related core IDs | Extension-owned records have an intended destination or retained owner. |
| SP Page Builder addon | Addon type, page/layout IDs, Product source, filters, and custom code | Presentation structures are not mistaken for Product data. |
| Import/export workflow | File format, column definitions, Product/variant identifiers, relationships, and last successful run | Exported files can be reconciled with the authoritative database records. |
| Custom field/table | Schema, keys, business purpose, and consuming code | Custom values can be interpreted rather than copied blindly. |
| External system | Endpoint, authoritative entities, synchronization direction, IDs, and cutover owner | Cross-system identity and authority are documented. |
| Generated data | Caches, logs, sessions, indexes, abandoned imports, and temporary files | 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 | Joomla/Customer IDs, addresses, reviews, Order links, and external IDs | 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 | Joomla users, Customers, guests, addresses, reviews, company/tax data, and authentication dependencies are classified. |
| 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.
Read the final gate as two connected decisions: whether the actual Source evidence is recoverable and complete for the agreed scope, and whether the intended EasyStore implementation can use it. A complete catalog archive cannot settle a missing layout or account consumer. A prepared Target cannot replace missing Source relationships. Resolve, explicitly exclude by agreement or hold each required gap before execution.
Conclusion
EasyStore preparation requires coordinated evidence across Joomla, Products, variants, Categories, brands, inventory, Customers, Orders, coupons, refunds, reviews, SP Page Builder, URLs, extensions, and external systems. A Product export or visual storefront review cannot explain those relationships by itself.
A strong preparation package secures recoverable Source evidence under the available backup or export method, records recovery limits, identifies authoritative records, separates historical transactions from live configuration, selects representative samples, and assigns an owner and ready condition to every material dependency.
Carry the evidence package, intended Target decisions and any held scope into EasyStore 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 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.