osCommerce now spans two materially different data eras. Modern osCommerce v4 provides multiple front ends or sales channels, configurable Products, Customer groups, Product attributes, Product properties, brands, CMS control, themes, Apps, and advanced pricing. Many source Stores, however, still run older 2.x-derived databases or heavily modified installations whose extensions and table structures do not match v4.
That lineage is the first data-model decision. A source products_attributes record from an older Store is not automatically equivalent to a current v4 attribute, property, or configurable Product relationship. A legacy extension table may carry stock, supplier, voucher, SEO, or Order data that v4 represents elsewhere. A current v4 Product can also be assigned to sales channels and Customer groups, relationships that do not exist in the same way in older installations.
Migration planning must therefore identify which osCommerce generation owns each record, what the record means commercially, and which related entities must remain connected in the Target Store.
Version Lineage Is an osCommerce Data Boundary
Modern v4 and legacy osCommerce Stores should not be treated as one uniform schema. v4 is a current open-source platform with multiple front ends, CMS control, configurable Products, themes, Apps, and a newer administration model. Older 2.x Stores commonly use direct table extensions, manually installed modules, modified PHP files, and community contributions.
The source Store may also have passed through upgrades or forks. Its table names can look familiar while the actual field definitions and relationships have changed. Version lineage therefore determines whether a Product option, Customer group, sales channel, content page, or extension record has a native current equivalent.
| Source evidence | osCommerce interpretation | Migration consequence |
|---|---|---|
| Current v4 Product and assignment records | Modern osCommerce catalog model | Preserve Products, Categories, brands, attributes, properties, channels, and Customer-group links. |
| Legacy 2.x core tables | Earlier osCommerce record model | Interpret through legacy relationships rather than current v4 labels. |
| Community extension tables or columns | Extension-owned data | Identify the extension and the core record it modifies. |
| Modified PHP and SQL | Custom business logic or schema | Translate the business meaning instead of copying the old mechanism. |
| Fork-derived Store | Related but non-identical platform lineage | Confirm entity definitions and IDs from the actual installation. |
| External-system key | ERP, PIM, WMS, marketplace, accounting, or fulfillment identifier | Preserve durable cross-system identity. |
This distinction prevents a modern target model from being designed around assumptions that only applied to a legacy source installation.
Products, Categories, Brands, and Sales Channels Are Related but Separate
In current osCommerce v4, a Product can carry core identity, descriptions, identifiers, price and cost, tax, stock mode, images, video, packaging, virtual or downloadable settings, SEO data, suppliers, notes, and marketing relationships. Products can be assigned or restricted to sales channels and Customer groups. Categories can also be assigned to specific front ends and Customer groups.
This is more than a Product-to-Category hierarchy. A single Product may be shared across front ends while having different visibility, content, pricing, or commercial context. A source multi-store installation that duplicates Products may be better represented by one Product identity with channel assignments; another source may require separate Products because the commercial identity truly differs.
| Source structure | osCommerce v4 owner | Relationship to preserve |
|---|---|---|
| Canonical sellable item | Product | Identity, identifiers, price, stock, media, tax, and descriptions. |
| Browsing hierarchy | Category and Product assignment | Category tree and many-to-many Product placement. |
| Brand or manufacturer | Brand or supplier relationship | Brand identity remains distinct from Category classification. |
| Regional or brand storefront | Front end or sales channel | Product and Category availability by channel. |
| Buyer-specific catalog | Customer-group Product/Category assignment | Visibility and availability remain tied to the intended group. |
| Related merchandising | XSell, UPSell, Product groups, or marketing relationship | Merchandising links remain separate from Category membership. |
A migrated Product count says little about whether the right front end, Category, Customer group, or brand owns the Product relationship.
Attributes, Properties, Configurable Products, and Product Groups Serve Different Roles
Current osCommerce v4 distinguishes attributes from properties. Attributes can define selectable values, use templates, affect price or weight, support virtual/downloadable files, and participate in Product inventory. Properties describe Product characteristics and can support display, filtering, search, comparison, Product groups, icons, swatches, ranges, and structured values.
A source option should therefore be classified by behavior. If the buyer selects a value that changes the purchased item, it belongs in the attribute or configurable-Product layer. If the value describes the item for search or comparison, it fits the property layer. If it groups Products for merchandising or shared characteristics, a Product-group relationship may be more appropriate.
| Source meaning | osCommerce structure to consider | Relationship boundary |
|---|---|---|
| Size or color choice | Attribute and assigned value | Product, choice, price/weight effect, and selected Order-line value. |
| Combination with independent stock | Configurable Product or attribute-inventory relationship | Child/combo identity, quantity, SKU, and availability. |
| Technical specification | Property category, property, and value | Structured fact remains separate from a buying choice. |
| Filterable range | Property with filter/search display | Type, units, range, and Product values remain normalized. |
| Reusable option set | Attribute template | Definitions remain reusable across the intended Products. |
| Product family or comparison set | Product group or related Product relationship | Group meaning remains separate from Category hierarchy. |
| Digital file | Virtual/downloadable Product and attribute/file relation | File, expiry, download limit, Product, and Order context. |
Legacy osCommerce attributes may need to be reinterpreted into these modern roles. Keeping the old field name without classifying its behavior can turn a sellable combination into a filter value or a specification into an inventory-bearing option.
Stock, Pricing, Suppliers, Channels, and Customer Groups Form a Commercial Graph
Current v4 Product records can include real-stock or alternative stock modes, supplier cost, quantity discounts, recommended price, tax class, channel availability, Customer-group assignments, and group-specific restrictions. Other Apps can extend wholesale, marketplace, retail, or enterprise behavior.
These relationships should be modeled as a graph rather than flattened into Product columns. A source price may belong to a Customer group, quantity threshold, supplier cost rule, channel, currency, or promotion. A stock value may belong to one Product, an attribute combination, a location, or an external warehouse. A supplier code may be an internal Product field or the key to an external procurement record.
| Commercial value | Owner and relationship | Meaning to retain |
|---|---|---|
| Base retail price | Product and currency | Default commercial value. |
| Customer-group visibility | Product/Category-to-group assignment | Buyer access to the catalog object. |
| Group or wholesale price | Product, Customer group, and pricing rule | Intended buyer scope and amount. |
| Quantity discount | Product and threshold relationship | Break quantities and price effect. |
| Supplier cost | Product-to-supplier relationship | Procurement owner, cost, currency, and supplier key. |
| Channel availability | Product/Category-to-front-end relationship | Where the item is offered. |
| Inventory quantity | Product or configurable combination and stock owner | Sellable identity and authoritative quantity. |
Historical Order prices must remain historical snapshots. They should not be recalculated from the Customer’s current group, channel, or Product price after migration.
Customers, Customer Groups, Addresses, and Permissions Have Different Meanings
osCommerce v4 Customer groups can control Product and Category visibility, tax applicability, accumulative discounts, and default treatment for guest or newly registered buyers. Customer records also connect to addresses, Orders, communication data, and potentially Apps that provide wholesale, credit, loyalty, marketplace, or B2B structures.
A source segment should be interpreted by function. A tax-exempt flag, marketing segment, wholesale account, company relationship, and loyalty tier are not necessarily one Customer group. Some belong to core group settings, some to an App, and some to an external CRM or ERP.
| Source account concept | osCommerce owner to consider | Relationship to preserve |
|---|---|---|
| Individual shopper | Customer account and address book | Identity, login, addresses, and Orders. |
| Guest buyer | Order-level Customer snapshot | Historical identity without inventing a persistent account. |
| Wholesale or retail tier | Customer group and related catalog/pricing rules | Membership plus visibility, discount, and tax effects. |
| Tax-exempt status | Group setting or dedicated Customer/App field | Legal/commercial meaning remains explicit. |
| Company or trade account | Wholesale/B2B App or external account entity | Multiple users and commercial rules remain connected. |
| Administrator or staff user | Backend user and permissions | Staff access remains separate from Customer segmentation. |
| CRM/ERP ID | External identifier | Stable reconnection key. |
The group label alone is insufficient when different Prices, Products, Categories, taxes, or payment terms depend on it.
Orders Preserve Transaction Snapshots Across Several Related Records
osCommerce Orders can include Customer or guest identity, billing and delivery addresses, Product and attribute snapshots, quantities, prices, discounts, taxes, shipping, payment information, Order statuses, comments, transactions, shipments, refunds, returns, invoices, and extension-owned records. Current v4 administration can also manage manual Orders and related Customer history.
Order migration should preserve the historical transaction, not attempt to reproduce it from current Product or Customer configuration. A Product may have changed name or price. A Customer may have moved groups. A payment module may have been replaced. The Order remains valid when its own line items, totals, addresses, statuses, and references explain what occurred.
| Order element | Historical owner | Meaning to retain |
|---|---|---|
| Product line | Order Product snapshot | Product name/SKU, quantity, selected attributes, and price at purchase time. |
| Billing/delivery address | Order snapshot | Historical address independent of the current Customer address book. |
| Discount/tax/shipping amount | Order total or adjustment record | Label, amount, sequence, and contribution to final total. |
| Payment reference | Transaction or payment-module record | Historical reconciliation evidence. |
| Order status and comments | Order history | State sequence, date, visibility, and narrative. |
| Shipment/tracking | Shipment or fulfillment record | Carrier, method, tracking, and shipped items where represented. |
| Refund/return | Related after-sale record | Amount, affected lines, reason, and status. |
A Target Store can use new live payment and shipping configuration while still preserving the labels and references attached to old Orders.
CMS, Front Ends, Themes, URLs, and Catalog Content Have Separate Owners
Modern osCommerce v4 includes CMS control, multiple front ends, themes, a visual theme designer, Product and Category content, SEO settings, images, videos, and language-specific values. Legacy installations may use information-page extensions, static PHP pages, template boxes, language files, or SEO contributions instead.
These visible elements should be separated into content, route, channel, and presentation domains. A Product description belongs to the Product. A CMS Page has independent identity and route. A Category description belongs to the Category. A menu item or front-end placement controls navigation. A theme and template define presentation. A redirect links an old route to a new destination.
| Source asset | Target owner | Data-model implication |
|---|---|---|
| Product/Category description | Catalog entity | Keep content with the correct entity and language. |
| Information or policy page | CMS Page | Preserve page identity, route, hierarchy, and visibility. |
| Front-end-specific content | CMS/content record plus channel assignment | Keep content and channel scope connected. |
| Menu or navigation node | Navigation configuration | Content presence does not recreate placement automatically. |
| Theme block or template box | Presentation layer | Rebuild layout separately from the underlying content. |
| Product image/video | Product media relationship | Preserve media identity, order, language, and Product link. |
| Legacy URL | Entity route and redirect | Maintain source-to-target path relationships. |
This separation is particularly important when moving from an old 2.x Store whose content is embedded in templates or extensions into current v4 CMS and front-end structures.
Apps, Legacy Extensions, Custom Tables, and External Systems Extend osCommerce
Current osCommerce v4 uses an App Shop and supports Apps for payments, shipping, marketing, wholesale, marketplaces, accounting, and other functions. Legacy Stores often use manually installed extensions that alter core files and database tables. Both models can own records outside the native catalog and Order schema.
| Data owner | Example records | Translation decision |
|---|---|---|
| osCommerce core | Products, Categories, brands, attributes, properties, Customers, Orders, CMS | Map through native data relationships. |
| v4 App | App fields, entities, transactions, marketplace offers, wholesale rules | Preserve with the App or another explicit target owner. |
| Legacy extension | Added columns, tables, statuses, vouchers, SEO, stock, reports | Identify the extension and the core records it modifies. |
| Custom code | Bespoke tables, workflows, or altered calculations | Translate business meaning rather than old code structure. |
| External service | Tax, payment, shipping, search, marketplace, analytics | Retain historical references and active connection keys. |
| ERP/PIM/WMS/CRM | Product, Customer, stock, supplier, and Order master IDs | Preserve durable identifiers and authority. |
A legacy extension field is not automatically a v4 App field. A current App name also does not guarantee that old extension data has the same schema or business meaning. The migration boundary must be defined record by record.
osCommerce Translation Decisions by Business Meaning
| Source pattern | Correct translation question | Consequence of a wrong assumption |
|---|---|---|
| Legacy option matrix | Is it a core attribute, configurable Product relationship, or extension-owned stock combination? | Child SKU, stock, price, or selected values are lost. |
| Descriptive Product field | Does it belong to a v4 property, content, brand, supplier, or external PIM? | Search and comparison structure become inconsistent. |
| Product duplicated across Stores | Is there one Product with channel assignments or several distinct commercial identities? | Stock and SEO split unnecessarily or regional differences are overwritten. |
| Customer group | Which visibility, discount, tax, or pricing relationships depend on it? | The segment label survives without its commercial effect. |
| Order total from an old module | What historical amount and label must remain on the Order? | Past totals cannot be explained. |
| Static legacy page | Is it CMS content, template code, a route, or an extension record? | Content arrives without correct ownership or navigation. |
| External ID | Which system and entity does the key identify? | Reconciliation and synchronization fail. |
osCommerce migration is successful when the target model reflects the correct platform generation and preserves relationships across catalog, channel, Customer, Order, content, App, and external-system domains.
Conclusion
osCommerce data-model translation begins by separating modern v4 structures from legacy installations. Current v4 supports Products assigned to sales channels and Customer groups, attributes, properties, configurable catalog relationships, CMS control, multiple front ends, themes, Apps, and advanced pricing. Older Stores may depend on very different tables, extensions, and modified files.
The Target Store should preserve Product and Category identity, selectable attributes, descriptive properties, channel and Customer-group relationships, historical Order snapshots, CMS and route ownership, and durable external identifiers. It should not assume that a legacy extension record becomes native merely because current v4 offers a feature with a similar name.
Common Questions
Why does the osCommerce source version matter so much?
Modern v4 and legacy 2.x Stores use materially different architecture and extension models. The same label can refer to different tables, relationships, or behaviors, so source lineage determines how the record should be translated.
What is the difference between osCommerce attributes and properties?
Attributes can represent selectable Product values and affect price, weight, inventory, or downloadable files. Properties describe structured characteristics used for display, filtering, search, comparison, or Product grouping.
Can one osCommerce Product be assigned to several front ends or Customer groups?
Current v4 supports Product and Category assignment or restriction by front end, sales channel, and Customer group. The migration must preserve those relationships rather than duplicating Products without need.
Should every legacy Product option become a modern configurable Product relationship?
No. Some options only adjust price or capture buyer input, while others identify independent stock combinations. The correct destination depends on SKU, stock, price, media, and Order-line behavior.
How should historical Orders be handled when payment or shipping modules change?
Preserve Order-time Product lines, addresses, totals, method labels, transaction references, statuses, shipments, and after-sale records. Live target configuration can change without rewriting the historical transaction.
What should happen to data from old osCommerce extensions or current v4 Apps?
Identify the extension or App, the core entity it extends, and any external system it depends on. Active records need an explicit target owner; obsolete technical data can be archived or excluded rather than forced into native fields.