A legacy osCommerce attribute row may record a purchase choice, while a documented v4 property stores a descriptive fact. A contribution or enabled App may own the stock combination behind that choice. When osCommerce is the prospective Target Platform, generation and installed ownership determine how the source value relates to the Product, buyer and Order line.
osCommerce documentation distinguishes the v4 model from older 2.x-derived installations. The documented v4 environment uses Products, purchasing attributes, descriptive properties, Customer groups, front-end or sales-channel assignments and CMS structures, with additional behavior supplied by enabled Apps. Older sources can use modified databases and contribution tables that do not share those definitions. A feature described for v4 or an App does not establish that every selected installation includes it.
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
The documented v4 and legacy models are separate schema contexts. Front ends, CMS content, themes and Apps have their own owners in a v4 installation; older 2.x sources may instead use directly extended tables, manually installed modules, modified PHP and community contributions. Their similar storefront results do not make an option, content page or commercial rule the same record.
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 the documented v4 model, Product identity connects catalog content, identifiers, prices, tax, media and stock relationships. Product and Category assignments identify the front ends or sales channels where those records are offered; Customer-group restrictions separately determine the buyer’s catalog access. A manufacturer or brand identifies the catalog’s maker or brand, while a supplier identifies a procurement relationship. A shared label cannot merge those roles.
A Product can be shared through channel assignments without becoming a new commercial item in each front end. Customer-group restrictions are a separate dimension, not another name for a channel. Content, prices and availability follow their actual field, rule and enabled-module scope. Separate source Products may therefore represent either repeated copies of one identity or distinct offers whose commercial differences must survive; channel assignment alone does not decide which.
| 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/manufacturer record and Product assignment | Catalog brand identity remains distinct from Category classification and supplier procurement relationships. |
| 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. |
Native Product IDs, attribute/value IDs and channel or Customer-group IDs join different destination records. Model codes, SKUs and external identifiers can help match the business item across systems, while Order lines retain purchased identifiers and choices. Copying a source key does not reuse the original native IDs or restore every associated record.
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
The documented v4 model distinguishes purchasing attributes from descriptive properties. An attribute and its assigned values express a shopper choice; price, weight, download or stock effects depend on the implementation and enabled modules that supply them. Properties instead use definitions, categories and typed values for description, search, filtering or comparison. Their language, unit or range is part of the value’s meaning, rather than a new sellable identity.
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 | Supported configuration or attribute-inventory relationship with its enabled module owner | Child/combo identity, quantity, SKU and availability follow the actual stock implementation. |
| 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 where represented by the selected installation | Definition identity remains separate from values assigned to individual Products. |
| Product family or comparison set | Product group or related Product relationship | Group meaning remains separate from Category hierarchy. |
| Digital file | Supported downloadable Product or attribute/file relationship | File, expiry, limits, Product and historical Order context remain separate from current download permission. |
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
Commercial values can belong to a Product, Customer group, quantity tier, supplier or enabled pricing/inventory App. For example, the publisher’s Inventory App provides per-variation stock and commercial details; that App’s role must not be mistaken for a universal bundled core relationship. Supplier costs are procurement values, while retail prices and buyer-specific rules have different owners. Wholesale, marketplace or other extended behavior likewise depends on its actual enabled consumer.
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. |
Stock quantity also requires the actual Product or combination owner and any location or external inventory relationship. An option label does not identify that stock unit by itself. A current balance remains distinct from historical Order activity; retaining the history does not instruct the destination to repeat old deductions or shipments.
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. |
Customer identity, current address-book entries and historical buyer snapshots have separate lifecycles. A guest Order does not require inventing a registered account. Usable login verification depends on the exact Source-to-Target path, including explicitly supported credential-preservation cases or a required reset/access flow. Email, account existence and stored hash data alone do not establish the outcome. Company hierarchies, credit programs and staff permissions also need their own native, App or external owner.
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
An Order joins the Customer or guest snapshot, addresses, Product and selected-attribute lines, quantities, prices, discounts, taxes, shipping/payment labels and historical states. Transactions, shipments, refunds, returns, invoices or extension records have their own related owners where represented in the selected installation. Their references explain the historical transaction; they do not recreate the live module or authorize a new action.
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
In a selected v4 installation, CMS records, front-end assignments, themes, catalog descriptions, media and localized values have separate roles. Installed content or blog Apps can add their own entities and rendering relationships. Older sources may instead store pages in contributions, static PHP, template boxes or language files. Identifying that owner preserves the content’s lifecycle without treating every visible page as one native CMS object.
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 | Product, Category, brand, attribute, property, Customer, Order and CMS records present in the selected generation | Map through the actual native definitions and supported destination 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 with generation and enabled ownership. The documented v4 model separates Products, attributes, properties, channels, Customer groups and content; installed Apps can add inventory and commercial structures. Older sources can use materially different tables, contributions and modified files. A shared functional label does not make those schemas equivalent.
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?
The documented v4 and legacy 2.x models have different definitions and extension ownership. A familiar attribute, Customer group or content label can identify different records and consumers. Both the selected source generation and destination installation matter; generation compatibility alone does not establish an equivalent schema or supported migration representation.
What is the difference between osCommerce attributes and properties?
Purchasing attributes express choices assigned to a Product; any price, weight, inventory or download effect follows the actual enabled implementation. Properties describe typed facts used for display, search, filtering or comparison. A property definition, its language/unit and its assigned Product value remain separate from a stock-bearing combination.
Can one osCommerce Product be assigned to several front ends or Customer groups?
The documented v4 model uses Product and Category assignments for front ends or sales channels, with Customer-group restrictions as a separate buyer dimension. A shared Product identity can remain shared where its actual commercial meaning permits it. The selected field and module scope govern any differing content or prices; channel membership does not automatically create an independently priced duplicate.
Should every legacy Product option become a modern configurable Product relationship?
No. A choice can adjust one Product or capture input without identifying an independent stocked combination. A genuine combination needs its Product/attribute references, SKU, quantity and enabled inventory or configuration owner. The selected generation, installed App and supported destination representation determine that relationship.
How should historical Orders be handled when payment or shipping modules change?
Keep the Order-time lines, addresses, totals, method labels, states and retained transaction or shipment references with their historical owners. Refund, return or invoice records need their own related identity where represented. That evidence can survive a module change without authorizing new charges/refunds, restarting stock effects or recreating live checkout configuration.
What should happen to data from old osCommerce extensions or current v4 Apps?
Identify the actual extension or enabled App, its parent entity keys and continuing consumer. A similar current App name or feature description does not make a legacy schema compatible, nor prove that the destination includes that App. Active relationships need an explicit destination; obsolete technical residue can be archived or excluded.