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.
Secure Joomla, EasyStore, Hosting, and Database Access
Confirm access to Joomla administration, EasyStore administration, hosting, database, filesystem, Product media, SP Page Builder, payment and shipping integrations, scheduled tasks, and connected systems. Record Joomla, EasyStore, PHP, database, template, SP Page Builder, plugin, module, and language versions.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administrative access | Joomla/EasyStore administrator | Working accounts and role summary | Products, variants, Customers, Orders, coupons, reviews, and configuration are inspectable. |
| Create recoverable backups | Infrastructure owner | Database export, filesystem/media archive, and restoration owner | The source can be restored independently of the live Store. |
| Record the extension environment | Technical owner | Joomla, EasyStore, SP Page Builder, template, plugin, module, payment, and shipping inventory | Every commerce dependency has an owner. |
| Capture customizations | Development owner | Custom addons, template overrides, snippets, API/webhook code, and direct database changes | Custom behavior that creates or interprets records is documented. |
| Map connected systems | Integration owners | ERP/PIM/WMS/CRM/accounting/fulfillment/marketplace endpoints and external IDs | Continuing systems and data authorities are known. |
Preserve Product, variant, Category, tag, brand, collection, Customer, Order, coupon, review, refund, media, Joomla user, menu, and external IDs needed to trace relationships.
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 each generated variant can have its own SKU, standardized identifiers, price, discount, tax state, shipping package, weight, quantity, availability, and visibility. Product Options can also hold upsell and cross-sell relationships, while Additional Data describes specifications.
| 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 very large option matrices, preserve the original combination count and environment limits in the technical evidence. Do not assume every theoretical combination represents a real sellable variant.
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, SSO/social login, reset flow, and communication owner | Security owner | Account access is planned without assuming password portability. |
Select Customers with multiple addresses, guest Orders, reviews, duplicates, important external IDs, and high-value Order histories.
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 evidence of past transactions rather than current operating rules.
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 only the Joomla and SP Page Builder relationships needed by commerce data and routes.
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.
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. Actual migrated proof and launch interpretation belong to the validation workstream.
Complete the Final EasyStore Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Joomla, EasyStore, hosting, database, files, backups, and restoration ownership are confirmed. |
| 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. |
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.
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 backups, identifies authoritative records, separates historical transactions from live configuration, selects representative samples, and assigns an owner and ready condition to every material dependency.
Common Questions
What should be prepared first for an EasyStore migration?
Confirm Joomla, EasyStore, hosting, database, filesystem, SP Page Builder, and integration access. Create recoverable backups and record the extension environment before catalog mapping begins.
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.