A VirtueMart catalog can depend on Joomla records, sparse child Products, custom-field assignments, and plugins that are invisible in a simple Product count. Preparation must preserve those relationships and their effective commercial meaning before a destination representation is chosen.
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.
Source access, evidence and recovery
Identify the actual Source Store separately from the intended Joomla/VirtueMart installation. Confirm the available Source administration, records, Product media, downloadable-file evidence, scheduled processes, connected services and recovery method. When VirtueMart is the Source, include its Joomla/VirtueMart administration and hosting/database/filesystem access where available; another Source uses its own records and keys without invented VirtueMart IDs. Separately record the intended Joomla and VirtueMart versions, PHP and database environment, template, languages, enabled plugins, payment and shipment methods, and custom code or overrides. Confirm compatibility and permissions for that installation and selected data path instead of applying one build's field labels or plugin behavior to every Store.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; Joomla/VirtueMart administrator when VirtueMart is the Source | Working accounts and role summary | For a VirtueMart Source, Products, custom fields, Customers, Orders, plugins, menus, and configuration can be inspected. Another Source provides access to its own selected records. | Actual Source administration. Native Joomla/VirtueMart 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; database export and filesystem/media/download archive where that Source provides them | Required Source records and files are recoverable under the declared method; full-Store restoration limits are explicit. Resolve a required recovery gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery capability. Another hosted Source need not provide a Joomla database or filesystem; an export may recover evidence without restoring the whole Store or file-access behavior. |
| Record platform and extension versions | Source technical owner; intended Target build owner separately | Actual Source software/components; for a VirtueMart Source, Joomla, VirtueMart, PHP, database, template, plugin, module, and package inventory where applicable | Version-dependent records and compatibility assumptions are documented. | Actual Source versions and components. Native Joomla/VirtueMart details are conditional on that environment; intended Target build and plugin compatibility are independent. |
| Capture custom code and overrides | Source development owner; intended Target customization owner separately | Actual Source custom behavior and consuming code; where present and accessible, template overrides, modified layouts, custom plugins, scripts, and direct database changes | Every customization that reads or writes commerce data has an owner. | Actual Source record writers and consumers. Intended VirtueMart fields, overrides, plugins or replacement consumers need their own Target owners. |
| Map connected systems | Source and continuing integration owners | ERP/PIM/WMS/CRM/payment/shipment/feed endpoints and external IDs | Continuing systems and authoritative data sources are identified. | Actual Source and continuing external identifiers and authorities. Future Target endpoints, stock writers and synchronization responsibilities require separate decisions. |
Record the actual Source recovery method, evidence date, covered records/files, protected or remote assets, missing areas and owner. Preserve native Joomla/VirtueMart database and filesystem/media/download archives where available; another hosted Source may instead provide exports/files or managed recovery. Recovering evidence does not establish full Store restoration or current plugin/file-entitlement behavior. Resolve, agree exclusion or hold a required coverage gap before execution.
Preserve internal IDs for Products, Categories, manufacturers, custom fields, shopper groups, Joomla users, VirtueMart shoppers, Orders, Order lines, statuses, media, and external systems where present in the actual Source. Native Joomla/VirtueMart IDs apply when that installation is the Source. Retain original values, language-specific records, parent links, and file relationships before approved cleanup; record normalization separately. Date and protect database/filesystem/media backups where available, or the Source’s exports/files and recovery evidence, with coverage, limits and recovery owner so the required relationships remain recoverable.
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. Distinguish a parent used only as a shared pattern or non-orderable selection page from a buyable parent. For downloads, preserve the actual file, entitlement, Order relationship, and plugin or external owner; a Product record alone does not recreate access behavior.
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. Preserve the prototype definition separately from its per-Product assignment, actual selected values, parameters, display position, and plugin owner. Record whether it controls identity, selection, price, stock, download access, display, search, or another workflow. Similar labels should not be merged unless their commercial behavior is equivalent. A shopper input or price choice does not by itself prove an independently stocked child Product.
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. Confirm account access for the exact Source-to-VirtueMart path, including local credentials or SSO/MFA dependencies, verification, supported reset or activation handling, first-login expectations, and Customer communications. Linking Joomla and shopper IDs does not establish password portability.
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. |
Preserve both the child's original overrides and the effective values resolved through its parent chain. An empty child field can mean inheritance rather than missing information; record the parent source of shared descriptions, Categories, prices, or media instead of filling blanks indiscriminately. Capture stock and booked/reserved quantities with their time, actual stock owner, and Order-status stock-handling meaning. Prepare opening values and pending obligations separately from historical Orders.
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 | Original status codes, translated labels, sequence, timestamps, shopper/guest context, and actual stock/plugin effects 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. Retain original line descriptions, selected custom fields, amounts, addresses, dates, status codes, invoices, and payment/shipment references used by staff. Prepare how historical imports will avoid initiating new payments, stock reservations or removals, shipments, emails, invoice creation, download grants, or plugin/integration events. The sample packet explains history; it does not authorize live workflow replay.
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. Preserve actual language tags, translation associations and overrides, menu context, aliases, and metadata ownership; Product metadata can be overridden by a Joomla menu, so the visible page alone may not identify its source.
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. Record the installed-version field contract, original keys, schemas, related files, and continuing consumer for each such dependency. A disabled plugin can leave required history even when its live behavior will be retired.
Confirm VirtueMart Target implementation prerequisites
The intended Joomla/VirtueMart installation must be able to use the agreed child-Product, custom-field and shopper-group relationships. A Source child field can reflect inheritance rather than missing data, and a stored field value can depend on a plugin to create its buyer-facing meaning. Confirm the intended representation and required compatible consumers before execution, keeping preserved history separate from live payment, stock, access and shipment behavior.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended installation and access | Target technical owner | Joomla/VirtueMart build, administration, compatible required plugins/modules, template consumers, available hosting/storage access and recovery responsibilities | The intended installation and required components are available to their owners. |
| Prepare catalog, fields and commercial models | Target catalog, pricing and inventory owners | Real parent/child representation, stored overrides and effective values, field prototypes/assignments and plugin consumers, shopper-group prices/calculation rules, quantity authority and status-dependent stock decisions | Required sellable and commercial relationships have usable consumers and effective settings; blank child fields or buyer choices do not establish missing data or independently stocked children by themselves. |
| Prepare account, route and file consumers | Target identity, site and digital-fulfillment owners | Joomla/shopper/guest links, groups, authentication decisions, menus/access/languages, media, Product/Order download relationships, metadata owners and field/layout consumers | Required account, commerce routes and files have compatible consumers and explicit access treatment, with general Joomla CMS work separately owned. |
| Assign plugins and continuing live operations | Target development, operations and integration owners | Custom/plugin schemas and external keys, future payment/shipment/tax/email/checkout behavior, stock/status effects and historical/test containment decisions | Continuing processes have usable owners; historical Orders/statuses cannot initiate new charges, reservations, shipments, messages, invoices, download grants or integration events. |
Select Representative Migration Test Samples
Choose samples that expose the Store's actual structure. Record source IDs, SKUs, URLs, original stored values and effective inherited values, group assignments, language context, external keys, related records and files, and the reason each sample was selected. State the intended representation, approved exclusions, and reviewer before the representative migration test begins.
| 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 recoverable source evidence, parent-chain and Joomla context, shopper-group and language relationships, related files, an intended representation, and a named reviewer. Include a sparse child and a status-dependent stock case where used so their meaning is explicit.
Complete the Final VirtueMart Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Actual Source access, available database/files/media/download backups or exports, recovery method, date, coverage, limits and owner are confirmed. Required evidence is recoverable under that method; intended Joomla/VirtueMart access and implementation prerequisites are assessed separately. |
| 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. |
| Target prerequisites | The intended Joomla/VirtueMart build, child/field/plugin and commercial representation, account/route/file consumers, access and continuing-operation owners are confirmed. |
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. Resolve required evidence and compatibility gaps, exclude them with approval, or hold readiness; naming an owner for an unanswered dependency is not enough.
Assess actual Source evidence and intended Target consumers together. Missing parent-chain meaning, an unavailable required field/plugin consumer, an unowned stock/status effect or a material recovery gap remains a readiness gap even if the records exist. Resolve it, agree an explicit exclusion or hold the affected scope before execution. Later validation tests the declared shopper, route and operating outcomes.
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.
Carry the evidence package, intended Target decisions and any held scope into VirtueMart 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 a VirtueMart migration?
Confirm access and recoverable evidence for the actual Source Store first. Separately confirm the intended Joomla, VirtueMart, hosting, database, files, media, and extension prerequisites and their versions. Detailed catalog preparation needs reliable source inspection and recovery as well as an identified destination model.
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, original overridden values, and effective inherited values for SKUs, prices, stock, images, Categories, shopper groups, aliases, and custom fields. Record whether the parent itself is buyable or is a shared pattern. Each real sellable child should be traceable independently while retaining the source of its inherited data.
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.
Does an empty child-Product field mean the information is missing?
Not necessarily. VirtueMart can resolve empty child fields from the parent chain. Preserve the stored child override, the effective value, and its parent source before approved cleanup. Do not fill every blank or remove a sparse child without understanding the installed inheritance behavior.
Are Order status labels enough to prepare stock behavior?
No. Preserve the original status code, translated label, and actual stock-handling setting, including available, reserved, or removed treatment where used. Record related payment, shipment, notification, and plugin effects separately so historical status evidence is not replayed as a new operational action.