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, reusable options, attributes, filters, Categories, manufacturers, Customer Groups, discounts, specials, multiple Stores, SEO keywords, 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
Begin with evidence that identifies the actual OpenCart installation. Record the OpenCart version, active Store or multistore structure, database location, document root, admin path, active languages and currencies, current theme, and the extension or modification system in use. Long-lived Stores may contain OpenCart Marketplace extensions, OCMOD or VQMod changes, edited theme files, 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.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Record the exact OpenCart version and active Store IDs | Store administrator | Version screenshot, Store list, environment note | Every active Store and source version is identified. |
| Confirm source access | Hosting or technical owner | Available credentials, allowlist details, access test note | The required source connection can reach the intended installation. |
| Identify theme and modification layers | Developer or agency | Theme name, OCMOD/VQMod lists, modified-file inventory | Native records and code-dependent behavior can be distinguished. |
| 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, Options, Attributes, and Filters as Separate Evidence Sets
OpenCart distinguishes Product records from options, attributes, and filters. Options collect selectable or customer-entered values and may affect price, weight, reward points, quantity, or required status. Attributes describe Product characteristics. Filters support discovery through Product and Category relationships. Combining these structures into one spreadsheet can hide whether a value is a purchase choice, a specification, or a browsing aid.
Create a Product inventory that includes 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 where used. The inventory does not need to reproduce every database column, but it must reveal the relationships that distinguish simple and complex Products.
| Source pattern | Preparation action | Required evidence | Ready condition |
|---|---|---|---|
| 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. |
Normalize only clear source defects. Duplicate option labels, inconsistent casing, unused filters, or blank identifiers can be flagged, but do not merge values merely because they look similar. The commerce owner should approve any normalization that changes customer-facing 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 account identity, address-book records, Customer Group membership, approval state, marketing preferences, reward points, custom fields, and external identifiers. A Customer Group may control discounts, Product prices, tax behavior, payment access, or approval workflows; its business effect should be documented rather than preserving only the group name.
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. |
Do not edit historical Orders merely to make them look consistent. An unusual label or amount can be important evidence of the original transaction. Record known anomalies separately.
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, SEO Keywords, Media, and Route Evidence
OpenCart can assign SEO keywords to Products, Categories, manufacturers, and information pages. Prepare a route inventory that records the source object, Store and language scope, current path, SEO keyword, traffic or business importance, and intended disposition. Flag duplicate keywords, blank keywords on important records, routes created by extensions, and paths that depend on server rewrite configuration.
Content preparation should include information pages, 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 restorable source package before structural cleanup or migration execution. For a self-hosted OpenCart Store, this normally includes a database backup, the relevant file tree, environment details, configuration references, and evidence that the backup corresponds to the same Store state.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup | Hosting or database administrator | Timestamped dump and restore-readiness note | The dump is complete and tied to the correct database. |
| Files and media | Hosting or technical owner | Archive or accessible file tree | Original images, downloads, extensions, and theme files are available. |
| Environment record | Technical owner | PHP, database, web-server, and extension notes | Version-sensitive behavior can be interpreted. |
| Access register | Project owner | Credential owner and access status | Required access is available without sharing credentials in planning documents. |
| Change log | Store administrator | Changes after the evidence cut-off | Late structural changes can be incorporated deliberately. |
Select Representative Migration Test Samples
The sample set should expose the relationships that define the OpenCart Store. Prepare a compact manifest with source IDs, business reason, related files, and the expected source structure for each sample. The manifest is ready when each selected record has complete source evidence and a named reviewer.
Include at least:
- a simple Product and an inactive or archived Product;
- 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 |
|---|---|
| Is the exact installation and Store scope known? | Version, Stores, languages, currencies, theme, and modification layers are recorded. |
| Are Product relationships complete? | Options, attributes, filters, Categories, media, pricing rules, and identifiers are represented. |
| 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 routes, information pages, media, and rewrite dependencies are documented. |
| Are backups and access ready? | The source package is restorable and the required connection is available. |
| Is the sample set representative? | Complex and ordinary records are listed with source IDs and expected relationships. |
Unresolved items should be entered in a decision log with an owner and due date. Preparation is not complete when a critical field, extension table, Store assignment, or external identifier is still described only as “unknown.”
Conclusion
OpenCart preparation is strongest when it treats the Store as a connected catalog and operating record rather than a flat Product export. Options, attributes, filters, Categories, Stores, Customer Groups, Order totals, extensions, themes, media, and SEO keywords 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.
Common Questions
Why should OpenCart options, attributes, and filters be prepared separately?
They serve different purposes. Options collect purchase choices or customer input, attributes describe Products, and filters support catalog discovery. Combining them can create incorrect variant structures or remove useful specifications and browsing relationships.
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.
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, 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.