OpenCart preparation should reveal which layer gives a record its meaning: the Product, a master/Variant relationship, an option assignment, a Store scope, or an extension. A catalog export can hide those layers even when its rows look complete. Preserve the original relationships and confirm the intended OpenCart build before deciding what each source requirement becomes.
OpenCart preparation should make the source Store understandable before any migration configuration is finalized. The visible storefront may appear simple, while important record relationships remain distributed across Products, native Variant Products, reusable options, attributes, filters, Categories, manufacturers, Customer Groups, discounts, specials, multiple Stores, SEO routes, CMS content, extensions, themes, and custom database fields.
The preparation objective is to turn that distributed structure into controlled source evidence. Each major area should identify the action to complete, the owner who can confirm its business meaning, the evidence to provide, and the condition that makes the area ready. This prevents a Product export from being treated as a complete description of the Store when purchase choices, discovery rules, historical Order context, or extension-owned values sit elsewhere.
Establish Source Access and Record the OpenCart Environment
Identify the actual Source Platform separately from the intended OpenCart environment. When OpenCart is the Source, record its exact version, Store IDs, database/filesystem locations, languages, currencies, theme, and modification layers. For another Source, collect equivalent relationships without inventing OpenCart identifiers. Confirm the destination build, compatible enabled extensions, Store scope, access roles, and implementation owners separately. Long-lived OpenCart installations can contain Marketplace extensions, OCMOD/VQMod changes, theme edits, custom tables, or direct core modifications.
Access preparation should be specific enough for the appropriate connection method shown for the selected migration path. The merchant should not assume that database access, admin credentials, hosting access, API credentials, or a file package are interchangeable. Instead, prepare the source access and supporting evidence available for the actual Store, then keep the access owner available to resolve restrictions or missing permissions. Database and installation-file evidence applies when the actual Source provides it; a different or restricted Source needs its own export, API, file-access and recovery contract. Destination OpenCart access is a separate prerequisite.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| For an OpenCart Source, record the exact version and active Store IDs; for another Source, record its actual platform and scope | Store administrator | For an OpenCart Source: version screenshot, Store list and environment note; otherwise equivalent actual Source identity and scope evidence | Every active Source scope and its platform/version are identified; OpenCart Store IDs are required only for an OpenCart Source. |
| Confirm source access | Hosting or technical owner | Actual Source credential owner, allowlist details where needed, access status, connection or export inspection note, and restrictions | The required Source connection reaches the correct Store, or the agreed export/file package is available; restrictions have an accepted treatment. |
| Identify the actual Source theme and modification layers where accessible | Developer or agency | For an OpenCart Source: theme name, OCMOD/VQMod lists and modified-file inventory; for another Source, its actual theme/customization owners and available evidence | Native records and code-dependent behavior can be distinguished for the actual Source; inaccessible required behavior is resolved, excluded by agreement, or held. |
| Record languages, currencies, tax settings, and units | Commerce owner | Settings export or screenshots | Storewide values that affect Product and Order meaning are documented. |
| Identify scheduled imports or synchronizations | Integration owner | Feed schedule, external-system list, last-run evidence | The team knows which values may change during preparation. |
Set a preparation cut-off for uncontrolled structural changes. Routine trading can continue, but new extensions, schema edits, bulk catalog restructuring, or URL rewrites should be recorded after the source evidence is assembled.
Prepare Products, Variant Products, Options, Attributes, and Filters as Separate Evidence Sets
The documented OpenCart 4 model distinguishes master/Variant Products from reusable options, attributes, and filters. Older or modified installations need their actual model recorded; do not assume these structures exist merely because the platform name matches. A native Variant Product has independent child identity. Options can collect choices or buyer input and apply configured commercial adjustments, while attributes describe Products and filters support discovery.
Create a Product inventory that includes master/Variant relationships where used, model, SKU or other identifiers, status, quantity, stock status, price, tax class, weight, dimensions, manufacturer, Categories, images, downloads, related Products, specials, discounts, rewards, options, attributes, and filters. The inventory does not need to reproduce every database column, but it must reveal the relationships that distinguish simple Products, native Variant Products, and option-driven Products.
| Source pattern | Preparation action | Required evidence | Ready condition |
|---|---|---|---|
| Independent sellable child | Record the master/Variant relationship plus child SKU, price, stock, media, barcode, status, and material overrides | Master and child Product IDs with representative Variant Product records | Independent child Product identity is explicit and not hidden inside an option. |
| Required or price-changing option | Record option type, values, required status, and adjustments | Product IDs and representative option assignments | The option’s commercial effect is explicit. |
| Text, textarea, file, date, or time input | Separate customer-entered values from reusable option values | Product list and sample Order lines using the input | Purchase-specific input is not mistaken for a variant. |
| Technical specification | Record attribute group, attribute, language value, and Product assignment | Attribute export or structured sample | Descriptive data is separated from selectable choices. |
| Storefront filter | Record filter group, value, Product assignment, and Category assignment | Active filter map | Only filters used by current discovery paths are retained. |
| Product with several images or downloads | Record media sequence and file availability | Media list, paths, and representative Product IDs | Files and their Product relationships are available. |
| Specials or Customer Group discounts | Record Product, Customer Group, amount or percentage, quantity threshold, and dates | Pricing-rule inventory | Conditional price evidence is complete and not reduced to the base price. |
Preserve original Product/master/child IDs, option/value assignments, quantities, settings, and historical references before normalization. Record inherited values and explicit child overrides. An option-value quantity does not by itself establish an independent combination SKU or inventory pool; identify the native or extension owner of such requirements. Flag duplicate labels, casing, unused filters, and blank identifiers, then keep an approved source-to-intended ledger for changes affecting identity or meaning.
Document Categories, Manufacturers, Stores, and Discovery Relationships
Categories in OpenCart can form hierarchies, carry multilingual content, connect to filters, and be assigned to specific Stores. Products can belong to multiple Categories and Stores. Manufacturers may act as simple Product fields or as public brand landing pages. These relationships should be recorded separately from menu presentation.
Prepare the active Category tree with parent IDs, Store assignments, status, sort order, images, descriptions, metadata, filters, and current URLs. Mark Categories that are obsolete, hidden, duplicated for navigation, or retained only for historical links. For manufacturers, record which ones have public routes, useful descriptions, images, or search value.
For multistore installations, create a Store-scope matrix. A Product or Category available in the default Store may not belong to every additional Store. Languages, themes, domains, content pages, and settings can also vary. The final evidence should show whether records are shared, duplicated, or Store-specific.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Category hierarchy | Catalog owner | Parent-child export and active Category list | Every retained Category has a known parent and business purpose. |
| Product-to-Category assignments | Merchandising owner | Representative multi-Category Products and assignment export | Shared Product placement is visible without creating duplicate Products. |
| Manufacturer pages | Brand or SEO owner | Manufacturer list, route inventory, visibility notes | Public brands are separated from internal-only manufacturer values. |
| Store assignments | Multistore owner | Product, Category, information-page, and domain scope matrix | Each record has an intended Store scope. |
| Filters and navigation | Merchandising owner | Filter-to-Category map and menu screenshots | Catalog classification is separated from menu presentation. |
Prepare Customers, Customer Groups, Addresses, and Order History
Customer preparation should distinguish identity, addresses, Customer Groups, approval state, marketing preferences, rewards, custom fields, and external IDs. Record each group’s actual pricing, tax, payment, or approval effect and its core/extension owner. Separately prepare the exact Source-to-Target password-verification decision or reset, activation, or first-login handling, with identity-provider and communication owners.
Order preparation should preserve historical evidence. Build a status inventory and select Orders that represent guest and registered checkout, several Customer Groups, option selections, discounts, coupons, reward points, taxes, shipping, payment labels, refunds or returns where recorded, and extension-created totals. Record which historical fields are required for staff lookup, Customer account history, accounting reconciliation, or external integrations.
| Record area | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Customer accounts | Identify duplicate emails, approval states, custom fields, and external keys | Customer summary and exception list | Identity exceptions have an owner and disposition. |
| Customer Groups | Record every active commercial or access effect | Group-to-rule matrix | Group meaning is documented beyond the label. |
| Addresses | Separate reusable Customer addresses from Order-time snapshots | Customer and Order address samples | Current account data and historical evidence are not conflated. |
| Order statuses | Map statuses to their operational meaning | Status list with example Orders | Historical states can be interpreted without relying on color or label alone. |
| Order totals | Inventory subtotal, tax, shipping, coupon, reward, fee, credit, and extension lines | Representative Order totals | Every material adjustment has a known source owner. |
| External references | Record ERP, marketplace, payment, shipment, or accounting IDs | Identifier map | Continuing systems can locate the same Customer or Order. |
Preserve historical line selections, addresses, labels, amounts, status sequence, and external references independently of current catalog or checkout settings. Record known anomalies separately. Also identify the notification, payment, stock, reward, download, or fulfillment events that must be contained so imported history does not replay a live operation.
Inventory Extensions, Modifications, Themes, and Custom Data
OpenCart extensions can add fields, tables, option behavior, Order totals, feeds, marketplace listings, checkout steps, payment records, shipping references, reports, SEO logic, or administrative workflows. Themes may also read custom fields or modify how options, filters, and content appear. A list of extension names is not enough; preparation must record the business records each extension owns.
Create an extension ledger with status, vendor, version, purpose, storage location where known, affected entities, custom fields or tables, external dependencies, and the owner who can confirm whether the behavior is still required. Separate live business data from configuration and obsolete technical residue.
| Extension effect | Evidence to prepare | Readiness decision |
|---|---|---|
| Product or option fields | Field names, sample Products, table or export location | Each active value has a destination owner or deliberate exclusion. |
| Order-total or checkout logic | Example Orders, total labels, module configuration summary | Historical values are separable from future checkout configuration. |
| Marketplace or feed integration | Listing IDs, channel Categories, synchronization keys | Canonical Product identity and channel records are distinguished. |
| SEO or URL modification | Current route examples, redirect tables, rewrite configuration | Important source paths can be reconstructed. |
| Theme-dependent content | Screenshots, template paths, block or module assignments | Content is separated from presentation code. |
| Abandoned extension | Last-use evidence and data-owner confirmation | Obsolete records are marked for archive or exclusion. |
Prepare Content, CMS Articles and Topics, SEO Routes, Media, and Route Evidence
In the documented current OpenCart model, routes can belong to Products, Categories, manufacturers, Information pages, CMS Articles, and CMS Topics. Confirm which objects the actual build supports and which are extension-owned. Record object identity, Store/language scope, current path, importance, and intended destination; flag collisions, blank required routes, and rewrite or extension dependencies without assuming a legacy Store has modern CMS records.
Content preparation should include Information pages, CMS Articles and Topics, Product and Category descriptions, manufacturer content, banners, layouts, modules, and media files that remain important. Record whether each item is a migratable content record, a Target Store configuration task, a theme asset, an external resource, or obsolete material.
Back up original image and download files with their paths. A database export can contain filenames without containing the files themselves. Identify missing files, external URLs, case-sensitive path differences, and generated thumbnails that do not need to become source originals.
Build the Backup and Input-Readiness Package
Create a recoverable source package before cleanup. For a self-hosted OpenCart Source, include the database, relevant files/media, environment details, and configuration references from the same state. For another or restricted Source, record actual export/archive coverage and recovery responsibility. Keep originals dated and protected, including remote assets; separately confirm that the intended OpenCart deployment and compatible extensions have implementation owners. A record export is not a full installation backup. Document what can be recovered, what cannot, who owns recovery, and how required omissions will be resolved, excluded by agreement, or held. Full native recovery requires the complete database and relevant file tree, not only catalog rows.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup where accessible, or available Source archive | Actual Source hosting/database administrator or export owner | For an accessible OpenCart Source: timestamped complete dump and restore-readiness note; otherwise dated exports/archives with coverage, limitations and recovery owner | An accessible OpenCart dump is complete and tied to the correct database/state; another or restricted Source has documented recovery coverage and accepted limitations, without claiming a full restore from exports. |
| Files and media | Hosting or technical owner | Actual Source archive or accessible file tree, remote-media inventory, and availability/recovery limits | Required original images and downloads are available; OpenCart extension and theme files are included when that is the actual accessible Source. Required missing files are resolved, excluded by agreement, or held. |
| Environment record | Technical owner | Actual Source environment evidence; PHP, database, web-server and extension notes for an accessible OpenCart Source, or available provider/export constraints for another Source | Actual Source version-sensitive behavior and archive limits can be interpreted; the intended OpenCart runtime is assessed independently. |
| Access register | Project owner | Actual Source credential or export owner, access status and restrictions | Required Source access or agreed inputs are available without sharing credentials in planning documents; unresolved required restrictions hold the affected scope. |
| Change log | Store administrator | Changes after the evidence cut-off | Late structural changes can be incorporated deliberately. |
Confirm the Intended OpenCart Build and Implementation Owners
Prepare the intended OpenCart deployment independently from the Source archive. Record its actual build, Store and language scope, access roles, and compatible enabled extensions. Name the technical owner responsible for runtime and deployment requirements and the business owner who approves how required Source relationships will be represented. A complete Source backup does not establish that the destination supports those relationships.
Resolve the owner and compatible representation for required master/Variant or option behavior, pricing rules, public routes, theme-dependent content, and extension consumers before selecting samples. Use the actual Source model to define the requirement; do not require modern OpenCart objects from an older or different Source. Retain the Source identity ledger when the destination representation changes.
Select Representative Migration Test Samples
The sample set should expose the relationships that define the actual Source and intended OpenCart representation. Record source IDs, reasons, original values, related files, expected relationships, inherited/overridden child settings where relevant, agreed exclusions, and a reviewer. Only include native Variant or CMS patterns where they exist; an equivalent requirement on another Source needs its actual owner. Later migrated proof belongs to validation.
Include at least:
- a simple Product and an inactive or archived Product;
- Product families that use native Variant Products, plus Products with required, price-changing, text, file, date, or stock-sensitive options where used;
- Products with attributes, filters, multiple Categories, manufacturers, several images, downloads, specials, and Customer Group discounts;
- Customers from meaningful Customer Groups, a guest Order, and a registered-Customer Order;
- Orders with option values, coupons, rewards, taxes, shipping, payment references, unusual totals, and external IDs;
- one important route from each public object type;
- one active extension-owned record and one theme-dependent content example.
Apply the Final OpenCart Readiness Gate
OpenCart is ready for the next migration step when the source can be described without relying on undocumented assumptions.
| Readiness question | Required outcome |
|---|---|
| Are the actual Source and intended OpenCart scope known? | Actual Source identity and scope are recorded. For an OpenCart Source, record version, Stores, languages, currencies, theme and modification layers; destination scope is separate. |
| Are Product relationships complete? | Actual Source Product relationships, identifiers, options, attributes, filters, Categories, media and pricing rules are represented where present; master/Variant evidence is required only where that model exists. |
| Are Customers and Orders interpretable? | Group logic, addresses, statuses, totals, and external references have owners. |
| Are extensions and custom data classified? | Every active dependency has a business purpose and destination decision. |
| Are content and URLs inventoried? | Important actual Source routes, content, media and rewrite dependencies are documented; Information pages and CMS Articles/Topics are identified where the Source supports them. |
| Are backups and access ready? | Actual Source access or agreed inputs are available. Accessible native database/files have recovery evidence; restricted or other Sources have documented archive coverage, limits and owner. Required gaps are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
| Is the intended OpenCart implementation prepared? | Build, Store/language scope, access roles, runtime/deployment owner and compatible extension consumers are confirmed for the agreed requirements. Required incompatibilities are resolved, excluded by agreement, or held. |
| Is the sample set representative? | Complex and ordinary records are listed with source IDs and expected relationships. |
Resolve required missing fields, extension records, Store assignments, files, or external identities, exclude them explicitly by agreement, or hold the affected scope. Track accepted noncritical exceptions with an owner, due date, boundary, and scope effect. An “unknown” business-critical relationship does not become ready simply because it has a future deadline.
Conclusion
OpenCart preparation is strongest when it treats the Store as a connected catalog and operating record rather than a flat Product export. Variant Products, options, attributes, filters, Categories, Stores, Customer Groups, Order totals, CMS content, extensions, themes, media, and SEO routes each need a clear owner and evidence set.
A controlled source package, representative sample manifest, and explicit readiness gate provide a reliable foundation for migration configuration. Carry the actual Source recovery coverage and accepted limits, independent OpenCart prerequisites, and unresolved scope holds into that decision; exports alone do not establish full installation recovery.
Common Questions
Why should OpenCart Variant Products, options, attributes, and filters be prepared separately?
They serve different purposes in the actual model. Documented OpenCart 4 native Variant Products preserve separate child identity; options collect choices or buyer input within a Product, attributes describe it, and filters support discovery. Older builds or extensions need their own structure recorded. Combining these owners can erase child identity or misrepresent specifications and choices.
What should be recorded for an OpenCart multistore installation?
Record each Store ID, domain, language, currency, theme, settings, Product and Category assignments, information pages, and important URLs. Shared records and Store-specific records should be distinguishable.
Does a database backup include OpenCart images and downloads?
No. The database commonly stores file references, while original images, downloads, theme assets, and extension files remain in the file system. Prepare both database and file evidence. That database-and-file requirement concerns an actual OpenCart Source with the relevant access. For another or restricted Source, document available exports, original media, recovery coverage, limitations and owner; missing required evidence needs resolution, an agreed exclusion, or a hold. Exports do not establish a full installation restore.
How should extension-owned OpenCart data be prepared?
Record the extension, affected entities, custom fields or tables, representative source records, external dependencies, and continuing business purpose. Active values need an explicit owner; obsolete records can be marked for archive or exclusion.
Which OpenCart records belong in the representative sample set?
Use ordinary and complex Products, native Variant Product families where present, several option types, attributes and filters, multi-Category relationships, Customer Groups, meaningful Orders, important routes, and active extension-owned records. The manifest should include source IDs and expected relationships.
Should duplicate SEO keywords be changed during preparation?
Flag them first and assign an owner. Change them only through an approved URL decision that records the intended destination and redirect relationship, because an apparently duplicate keyword may still have traffic or integration significance.
Should every older OpenCart installation have native Variant Products and CMS content?
No. Current documentation describes the 4.x model, while older or modified Stores can use different structures or extensions. Record the actual version, schema, and owning components for independent sellable children and content. Confirm the intended destination build and representation instead of creating unsupported source records.
Does option-value stock prove independent combination inventory?
No. Record what the quantity belongs to, how stock is subtracted, and whether it represents an option value, a child Product, or an extension-owned combination. Two option values with quantities do not establish a separate SKU and stock pool for every possible pairing. Preserve the actual identities and selling rules before normalization.