VirtueMart preparation must document both the commerce records and the Joomla structures that make those records usable. Products can depend on Categories, child products, custom fields, shopper groups, calculation rules, media, downloadable files, payment and shipment plugins, Joomla menus, language assignments, template overrides, and external integrations. A Product count cannot explain those dependencies.
VirtueMart preparation should assign an accountable owner, supporting evidence, and a clear ready condition to every required action before execution. It should also separate source evidence from target implementation: historical Orders, Product relationships, shopper-group assignments, and URLs belong to migration preparation, while live payment, shipment, tax, checkout, email, and template behavior remains target-side configuration.
Secure Joomla, VirtueMart, Hosting, and Database Access
Confirm access to Joomla administration, VirtueMart administration, hosting, database, filesystem, Product media, downloadable files, scheduled tasks, and connected services. Record the Joomla version, VirtueMart version, PHP and database environment, active template, languages, enabled plugins, payment and shipment methods, and any custom code or overrides.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administrative access | Joomla/VirtueMart administrator | Working accounts and role summary | Products, custom fields, Customers, Orders, plugins, menus, and configuration can be inspected. |
| Create recoverable backups | Infrastructure owner | Database export, filesystem archive, media/download archive, and restoration owner | The source Store can be recovered without relying on the live environment. |
| Record platform and extension versions | Technical owner | Joomla, VirtueMart, PHP, database, template, plugin, module, and package inventory | Version-dependent records and compatibility assumptions are documented. |
| Capture custom code and overrides | Development owner | Template overrides, modified layouts, custom plugins, scripts, and direct database changes | Every customization that reads or writes commerce data has an owner. |
| Map connected systems | Integration owners | ERP/PIM/WMS/CRM/payment/shipment/feed endpoints and external IDs | Continuing systems and authoritative data sources are identified. |
Preserve internal IDs for Products, Categories, manufacturers, custom fields, shopper groups, Joomla users, VirtueMart shoppers, Orders, Order lines, statuses, media, and external systems. These identifiers are essential when records must be reconciled across Joomla and VirtueMart tables.
Prepare Products, Categories, Manufacturers, and Media
VirtueMart Products can carry SKU, GTIN or manufacturer identifiers, descriptions, prices, stock, dimensions, images, manufacturers, Categories, child-product links, custom fields, related Products, downloadable files, and shopper-group restrictions. Prepare the catalog by selling behavior rather than by row count.
| Product pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple physical Product | Product ID, SKU, price, tax rule, stock, weight, Category, manufacturer, images, and sample Order | One record clearly identifies the item sold and fulfilled. |
| Parent and child Products | Parent ID, child IDs, inheritance behavior, child SKUs, prices, stock, images, Categories, and aliases | Every sellable child can be traced to the parent and its overridden values. |
| Downloadable Product | File path, access relationship, limit or expiry, Product link, and completed Order sample | Files and Order-based access evidence are recoverable. |
| Multi-Category Product | Product-to-Category assignments and priority route | Duplicate Products are not created merely to reproduce discovery paths. |
| Manufacturer-linked Product | Manufacturer ID, name, Product link, external key, and route | Brand/manufacturer identity remains separate from Category structure. |
| Media-heavy Product | Primary/additional images, documents, remote files, ordering, and child-specific media | Every media asset has a known Product or child-product owner. |
Record unpublished, archived, catalog-only, out-of-stock, back-order, minimum/maximum quantity, and availability-date cases. These states need intentional destination treatment rather than being normalized into one active Product state.
Prepare Custom Fields, Child Products, and Buyer Choices
VirtueMart custom fields can describe Products, create shopper-selectable inputs, affect price, appear in cart and Order views, connect related Products or Categories, attach downloadable goods, or depend on plugins. Child products can inherit parent values while overriding price, stock, image, Category, or shopper-group assignments.
| Structure | Required evidence | Ready condition |
|---|---|---|
| Descriptive custom field | Field prototype, type, title, values, Product assignments, display position, and search use | Descriptive data is distinguished from a buyable choice. |
| Cart attribute or cart input | Field definition, required state, price effect, selected values, and Order-line sample | Buyer choices remain attached to the purchased line. |
| Plugin custom field | Plugin owner, parameters, tables, Product links, and output example | Extension-owned behavior is not mistaken for ordinary field data. |
| Parent/child Product | Inheritance rules, overridden values, child SKU, stock, price, image, alias, and Category | Every sellable child has complete traceability. |
| Related Product or Category | Relationship type, source IDs, display purpose, and priority | Merchandising relationships are documented separately from taxonomy. |
Build a field ledger with one row per important custom field. Record whether the field controls identity, Product selection, price, stock, download access, display, search, or another plugin workflow. Similar labels should not be merged unless their commercial behavior is also equivalent.
Prepare Shopper Groups, Customers, Joomla Users, and Addresses
VirtueMart shopper groups can control Product visibility, Product prices, calculation rules, payment methods, shipment methods, and price display. Customers can also involve Joomla users, VirtueMart shopper records, address data, custom shopper fields, company or tax identifiers, and external CRM or ERP keys.
| Account area | Evidence | Owner | Ready condition |
|---|---|---|---|
| Joomla user and VirtueMart shopper link | Joomla user ID, VirtueMart user ID, email, status, groups, and external ID | Customer-data owner | The account relationship is traceable across Joomla and VirtueMart. |
| Shopper-group membership | Group definitions, assigned shoppers, Product prices, calculation rules, payment/shipment restrictions | Commerce owner | Group meaning is documented beyond its label. |
| Address and checkout fields | Field definitions, required/display rules, billing/shipping values, and country/state references | Customer-service owner | Saved addresses and Order-time address snapshots are distinguishable. |
| Guest buyer | Order-level identity, addresses, email, and access evidence | Order-data owner | Guest history does not require an invented Joomla account. |
| Company or tax identity | Company fields, tax number, validation state, and external account key | Finance/B2B owner | Business-account data has a named destination or retained owner. |
| Authentication | Local password, SSO, social login, MFA, reset communication, and account owner | Security owner | Account access is planned without assuming password portability. |
Include representative shoppers who belong to multiple groups, receive a special price, use restricted payment or shipment methods, or have several addresses. These cases expose relationships that ordinary retail accounts do not.
Prepare Prices, Calculation Rules, Taxes, Coupons, and Inventory
VirtueMart pricing can involve multiple Product prices, currencies, quantity ranges, shopper groups, cost and base prices, tax rules, discounts, overrides, and calculation order. Inventory can belong to a parent Product, child Product, or external system.
| Commercial area | Evidence to prepare | Ready condition |
|---|---|---|
| Product prices | Product/child ID, currency, shopper group, quantity range, dates, cost/base/final values, and override state | Every price is attached to the correct Product and commercial context. |
| Calculation rules | Rule type, tax/discount effect, Categories, shopper groups, countries, states, dates, and calculation sequence | Rules are documented as configuration relationships rather than Product fields. |
| Coupons | Code, type, value, dates, usage state, and relevant historical Orders | Historical coupon evidence is separated from active coupon configuration. |
| Stock | Product/child ID, quantity, reserved state where available, low-stock threshold, and external stock owner | The authoritative quantity and sellable-unit key are known. |
| Quantity restrictions | Minimum, maximum, packaging, and purchase-step rules | Quantity constraints are not lost inside generic Product notes. |
Historical Order totals must remain snapshots. Do not plan to reconstruct old prices, taxes, discounts, or shipping charges from current calculation rules.
Prepare Orders, Statuses, Payment, Shipment, and Invoices
Prepare Orders as historical commercial records. Include Order headers, shoppers, guest identities, billing and shipping snapshots, Product and child-product lines, selected custom fields, quantities, prices, taxes, discounts, coupons, payment labels, shipment labels, statuses, comments, invoices, refunds or adjustments, and external references.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and status history | Commerce operations | Status sequence, timestamps, shopper/guest context, and current meaning are documented. |
| Product lines and choices | Catalog and order owners | Product/child IDs, SKU, selected custom fields, quantity, and snapshot text are complete. |
| Totals and adjustments | Finance owner | Subtotal, tax, discount, coupon, shipment, payment cost, and final total reconcile. |
| Payment and shipment references | Finance and fulfillment owners | Historical method labels, transaction/tracking IDs, and provider ownership are known. |
| Invoices and documents | Finance owner | Invoice numbers, files, language, and Order relationships are recoverable. |
| External Order IDs | Integration owner | ERP, accounting, marketplace, or fulfillment references remain traceable. |
Select ordinary, guest, shopper-group, discounted, multi-tax, refunded, downloadable, and child-product Orders. The sample set should represent the Order states that staff actually use for support and reconciliation.
Prepare Joomla Menus, Routes, Languages, Media, and Storefront Dependencies
VirtueMart records depend on Joomla menus, aliases, access levels, language associations, modules, template layouts, overrides, search/filter extensions, and content links. Migrating Products and Categories does not recreate those presentation relationships automatically.
| Storefront area | Evidence | Ready condition |
|---|---|---|
| Product and Category routes | Source URL, Product/Category ID, alias, language, menu context, 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, and page assignment | Commerce entry points and discovery dependencies are documented. |
| Multilingual records | Language tags, associations, translated Products/Categories, menus, media, and fallback rules | Related translations are not treated as unrelated duplicates. |
| Template and overrides | Template name, VirtueMart layouts, override files, custom field positions, and affected routes | Presentation dependencies are separated from commerce data. |
| Media and downloads | Paths, remote storage, thumbnails, downloadable files, and access rules | Priority files are available and linked to the correct records. |
| SEO and redirects | Metadata owner, routing extension, redirect rules, sitemaps, and high-value URLs | URL continuity has an explicit owner. |
The Joomla CMS inventory belongs to the broader Joomla preparation scope. This checklist captures only the Joomla structures that materially affect VirtueMart commerce records and routes.
Inventory Plugins, Custom Tables, and External Systems
Create an extension ledger for payment, shipment, custom fields, search/filter, subscriptions, downloads, marketplaces, feeds, accounting, ERP, CRM, inventory, analytics, and custom code. Record what each component owns and which core records it references.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| VirtueMart plugin | Name, version, purpose, configuration, tables/fields, and affected Products/Customers/Orders | Plugin-owned records have a destination or retained system owner. |
| Joomla extension | Component/module/plugin name, menu/module dependency, and data owner | Shared Joomla behavior is not misclassified as VirtueMart core data. |
| Custom table or column | Schema, key relationships, business purpose, and consuming code | Custom records 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, temporary files, and abandoned records | Non-authoritative data is excluded deliberately. |
Inactive extensions should remain in the ledger when their data is still commercially or historically important.
Select Representative Migration Test Samples
Choose samples that expose the Store’s actual structure. Record source IDs, SKUs, URLs, group assignments, external keys, related records, and the reason each sample was selected.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, stock, tax, Category, manufacturer, media, and Order | Defines the baseline for ordinary VirtueMart Product representation before more complex samples are reviewed. |
| Parent/child family | Parent and children, custom fields, SKUs, prices, stock, images, and aliases | Represents inherited and overridden Product values. |
| Custom-field Product | Field prototypes, plugin dependencies, price/cart effects, and Order line | Exposes buyer-choice and extension relationships. |
| Shopper-group case | Customer, groups, restricted Product/price/payment/shipment evidence | Represents B2B or segmented commerce. |
| Complex Order | Guest/registered identity, child Product, custom choices, coupon, tax, payment, shipment, and invoice | Represents historical commercial context. |
| Multilingual route | Product/Category translations, aliases, menu paths, metadata, and redirect intent | Represents Joomla language and routing dependencies. |
| Extension-owned record | Core entity, custom table/field, plugin owner, and external key | Exposes non-core scope before execution. |
The VirtueMart sample package is ready when each selected record has source evidence, Joomla and shopper-group context, related files, and a named reviewer.
Complete the Final VirtueMart Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Joomla, VirtueMart, hosting, database, files, backups, and restoration ownership are confirmed. |
| Catalog | Products, children, Categories, manufacturers, media, custom fields, stock, prices, and identifiers are documented. |
| Customers | Joomla users, shoppers, groups, addresses, fields, guest identities, and authentication dependencies are classified. |
| Orders | Lines, choices, totals, statuses, payment, shipment, invoices, and external references have source evidence. |
| Storefront | Menus, routes, languages, modules, overrides, media, SEO, and redirects are documented. |
| Dependencies | Plugins, custom code, tables, external systems, and data authorities have named owners. |
| Samples | Representative records cover every material Product, Customer, Order, route, and extension pattern. |
VirtueMart preparation is complete when every material commerce record can be traced through its Joomla owner, related plugin or custom-field records, evidence artifact, and intended target destination or retained system.
Conclusion
VirtueMart preparation requires coordinated evidence across Joomla, Products, child products, custom fields, shopper groups, prices, calculation rules, Customers, Orders, media, routes, plugins, and external systems. The checklist should make those relationships explicit before execution rather than relying on Product counts or screenshots.
A complete VirtueMart readiness package preserves recoverable evidence, names authoritative records, separates historical transactions from live configuration, and resolves the ownership of every material dependency.
Common Questions
What should be prepared first for a VirtueMart migration?
Confirm Joomla, VirtueMart, hosting, database, filesystem, media, and extension access, then create recoverable backups and record the platform versions. Detailed catalog work should not begin until the team can inspect and restore the source reliably.
Why do VirtueMart custom fields require a separate ledger?
Custom fields can describe Products, collect buyer input, affect price, appear on Order lines, connect related records, attach downloads, or depend on plugins. Their label alone does not reveal the business function or destination owner.
How should parent and child Products be prepared?
Record parent and child IDs, inherited values, overridden SKUs, prices, stock, images, Categories, shopper groups, aliases, and custom fields. Each real sellable child should be traceable independently while retaining its parent relationship.
Why are shopper groups part of preparation?
Shopper groups can affect visibility, prices, calculation rules, payment methods, shipment methods, and displayed price elements. Preserving only the group name would omit the commercial relationships that make it useful.
Which VirtueMart Orders should be selected as representative samples?
Include ordinary and guest Orders, shopper-group cases, child Products, custom-field selections, coupons, multiple taxes, refunds or adjustments, downloads, invoices, and external references used by support or finance teams.
How should Joomla and VirtueMart preparation be divided?
The Joomla scope owns general CMS content, users, menus, modules, templates, and extensions. The VirtueMart scope owns commerce Products, shopper groups, Customers, Orders, calculation records, and commerce plugins while documenting only the Joomla dependencies required by those records.