osCommerce preparation begins with lineage because current osCommerce v4 and long-running legacy installations can use materially different catalog, extension, content, and database structures. A Store described as osCommerce may be current v4, an older 2.x release, a fork, or a heavily modified codebase with community extensions and direct schema changes.
The preparation objective is to identify the actual source model before choosing field mappings. Each area should state the action, owner, evidence, and ready condition. Current v4 relationships such as sales channels, Customer groups, attributes, properties, and CMS records should not be assumed to exist in the same form in a legacy source. Conversely, a legacy extension table should not be treated as native v4 data merely because a modern feature has a similar name.
Establish Source Lineage, Access, and Technical Ownership
Record the source platform name, version, branch or fork, database prefix, hosting environment, active front ends or storefronts, languages, currencies, extensions, modified files, custom tables, and external synchronizations. When an older Store has passed through several upgrades, preserve developer notes or schema evidence that explains which tables still drive current behavior.
Prepare the source access required for the selected migration path. The technical owner should confirm that the connection reaches the correct database and file tree, and that available backups belong to the same Store state.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Identify source generation and code lineage | Technical owner | Version evidence, repository or package note, fork history | The source is classified as current v4, legacy osCommerce, fork, or custom derivative. |
| Confirm database and file access | Hosting or database owner | Database name/prefix, connection status, document-root note | The required source connection reaches the intended installation. |
| Inventory extensions and core modifications | Developer or agency | Extension list, modified-file record, custom-table list | Native, extension-owned, and custom records can be separated. |
| Record front ends, languages, currencies, and tax context | Commerce owner | Settings evidence and scope matrix | Storewide context that changes Product or Order meaning is documented. |
| Identify external systems and imports | Integration owner | ERP/PIM/WMS/CRM list, feed schedule, key fields | Values maintained outside osCommerce have a named authority. |
Freeze undocumented structural changes once the evidence set is assembled. Routine trading may continue, but new extensions, schema edits, Product-model changes, or route rewrites should enter the project change log.
Prepare Products, Categories, Brands, Suppliers, and Front-End Scope
Current osCommerce v4 can associate Products with Categories, brands, suppliers, sales channels or front ends, Customer groups, multilingual descriptions, stock modes, images, identifiers, pricing, SEO fields, and merchandising relationships. Legacy Stores may use simpler core tables plus extensions for many of those functions.
Create a Product inventory that records the source Product ID, SKU or model, other identifiers, status, base price, tax class, stock behavior, weight, virtual/downloadable state, Category assignments, brand or manufacturer, supplier, images, language values, sales-channel scope, Customer-group scope, and active promotion or quantity-price relationships.
| Source pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Product assigned to several Categories | Record all Category relationships and the primary merchandising context | Product-to-Category export | Shared placement is visible without duplicating Products. |
| Product available on selected front ends | Record channel/front-end assignments and restrictions | Scope matrix by Product and Category | Channel availability is explicit. |
| Brand or supplier relationship | Separate public brand identity from procurement ownership | Brand, supplier, and Product links | Similar labels are not merged into one unrelated field. |
| Real, unlimited, hidden, or preorder stock state | Record quantity, stock mode, and out-of-stock behavior | Representative Product settings | Availability meaning is not reduced to a numeric quantity. |
| Virtual or downloadable Product | Record file, expiry, download limits, shipping meaning, and source path | Product/file manifest | Digital-delivery relationships and original files are available. |
| Group or quantity price | Record Product, Customer group, threshold, currency, and amount | Pricing relationship inventory | Conditional pricing is not replaced by the base price. |
For legacy Stores, note which values come from core Product tables and which come from extension columns or separate tables. The business owner should approve any cleanup that changes Product identity or channel scope.
Separate Attributes, Properties, and Configurable Product Relationships
Current v4 distinguishes attributes from properties. Attributes can represent selectable values, reusable templates, price or weight effects, virtual files, and inventory relationships. Properties describe structured characteristics used for display, filtering, search, comparison, ranges, icons, or Product groups. Legacy osCommerce attributes may combine several of those meanings.
Prepare evidence that classifies each source value by function rather than name.
| Business meaning | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Selectable buyer choice | Record attribute, values, template, Product assignment, and price/weight effects | Attribute and assignment export | The purchase choice and its commercial effect are explicit. |
| Combination with independent SKU or stock | Identify configurable or extension-owned combination records | Combination table and Product keys | Independent sellable identity is preserved in the source model. |
| Technical specification | Record property category, property, type, units, values, and Product links | Property inventory | Descriptive data is separate from buyer choices. |
| Filter or comparison value | Record display/filter/search behavior and taxonomy | Active discovery-field map | Values required by Product discovery are identified. |
| Text input or personalization | Identify the field owner and representative Order lines | Product and Order examples | Purchase-specific input is not treated as reusable metadata. |
| Downloadable attribute | Record file, limits, Product, and attribute relationship | File and attribute manifest | The file and digital entitlement evidence are complete. |
Do not automatically translate every legacy attribute into a current v4 attribute. Some belong to properties, configurable Product relationships, custom fields, or extension-owned structures.
Document Customer Groups, Accounts, Addresses, and Commercial Context
Current v4 Customer groups can control Product and Category visibility, tax applicability, accumulative discounts, and defaults for guest or newly registered users. Extensions may add wholesale, B2B, credit, loyalty, or approval records. Legacy Stores can represent these relationships differently.
Prepare Customer evidence that separates identity, address-book records, guest status, Customer-group membership, tax or trade status, reviews, external identifiers, and extension-owned balances or permissions.
| Record area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Customer identity | Customer-service or CRM owner | Duplicate and exception list | Each retained account has a clear identity decision. |
| Customer groups | Commerce owner | Group-to-visibility, tax, and discount matrix | Group meaning is documented beyond the label. |
| Addresses | Customer-data owner | Reusable addresses and Order-time examples | Account records and historical snapshots are distinct. |
| Wholesale or B2B extensions | Business owner and developer | Company, role, approval, price, or credit records | Extension-owned commercial relationships have a destination decision. |
| Reviews and activity | Content or commerce owner | Representative Customer-to-Product relationships | Customer-generated records retain the correct owner. |
| External Customer keys | Integration owner | CRM/ERP identifier map | Continuing systems can locate the same account. |
Password portability should be documented as a source characteristic, not assumed from the presence of an email address. Record the source authentication scheme and account-access dependency without turning the checklist into customer communication planning.
Prepare Orders and Historical Commercial Evidence
Order preparation should make historical transactions interpretable. Current v4 Orders can include sale-channel context, Product and attribute snapshots, addresses, totals, statuses, comments, payment and shipping labels, tracking, refunds, returns, invoices, and external references. Legacy modules may add separate Order-total rows or transaction tables.
Select Orders that represent the Store’s actual complexity and identify which records or extensions own each historical value.
| Order evidence | Preparation action | Ready condition |
|---|---|---|
| Product and attribute lines | Record snapshot names, SKUs, selected values, quantities, and prices | The purchased item remains understandable independently of the current catalog. |
| Billing and delivery addresses | Preserve Order-time snapshots separately from Customer addresses | Historical transaction addresses are complete. |
| Taxes, shipping, discounts, fees, and credits | Inventory every material Order-total line and module owner | Final totals can be explained without recreating retired code. |
| Payment and shipping references | Record labels, transaction IDs, tracking, and module ownership | Historical references are available without treating them as current configuration. |
| Status and comments | Record status meaning, sequence, dates, and visibility | Staff can interpret the historical process. |
| Refunds, returns, and external IDs | Record related entities and reconciliation keys | After-sale and external-system relationships remain traceable. |
Do not recalculate old Orders from current Product, Customer-group, tax, or shipping settings. The evidence package should preserve the original transaction as recorded.
Inventory Apps, Legacy Extensions, Custom Tables, and Integrations
Current v4 Apps and legacy extensions can own catalog fields, Customer groups, Order totals, SEO data, payment references, marketplace offers, reports, or external-system mappings. An extension list alone is insufficient; preparation must identify the records each component creates or modifies.
| Dependency pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Current v4 App | App name, version, affected entities, fields/tables, representative IDs | Active App data has an explicit owner. |
| Legacy extension | Package name, modified core files, SQL changes, and related records | The extension’s data can be separated from core osCommerce records. |
| Custom table or field | Schema, business meaning, parent keys, and consumer | Every active custom value has a disposition. |
| Marketplace or sales-channel connector | Listing, offer, channel, and external IDs | Canonical Product identity is distinct from channel representation. |
| ERP/PIM/WMS/CRM integration | Authority, synchronization direction, and stable keys | Continuing systems can reconnect to target entities. |
| Abandoned component | Last-use evidence and owner confirmation | Obsolete technical residue is marked for archive or exclusion. |
Prepare CMS Content, Media, SEO, and Route Evidence
Current v4 can manage CMS content, themes, front ends, Product and Category descriptions, media, and SEO settings. Legacy Stores may use information-page extensions, static files, template boxes, language files, or SEO modules. Prepare content by owner rather than treating every visible page as one CMS entity.
Build a route inventory for priority Products, Categories, brands, CMS Pages, information pages, front-end-specific content, and extension endpoints. Record source path, owning object, language, front end, metadata, canonical setting where present, business importance, and intended disposition.
Back up original images, downloads, documents, theme assets, and content files. Record attachment relationships and external URLs. A database dump can preserve filenames while omitting the original files.
Build the Backup and Input-Readiness Package
Create a restorable package tied to one source state.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup | Database administrator | Timestamped dump, prefix, and source-generation note | The complete intended schema is included. |
| Files and media | Hosting or technical owner | File archive or accessible source tree | Original media, downloads, extensions, and custom code are available. |
| Lineage record | Technical owner | Version/fork history and upgrade notes | Legacy and current structures can be interpreted correctly. |
| Access register | Project owner | Access owner and connection status | Required access is available without publishing credentials. |
| Change log | Store administrator | Structural changes after the evidence cut-off | Late changes can be incorporated deliberately. |
Select Representative Migration Test Samples
Prepare a sample manifest with source IDs, owner, business reason, related files, and expected source relationships. The set should expose both current-v4 and legacy-specific structures where they exist. The osCommerce sample manifest is ready when every source expectation, version-lineage dependency, linked file, and identifier is complete and assigned to a reviewer.
Include at least:
- a simple Product and a Product with several Category or front-end assignments;
- Products with attributes, properties, configurable combinations, downloads, suppliers, and group pricing;
- Customers from meaningful groups, guest transactions, and wholesale or extension-owned accounts;
- Orders with attributes, several totals, refunds, tracking, comments, and external references;
- priority CMS, Product, Category, brand, and extension-owned routes;
- one current App or legacy-extension record that carries business data;
- one record whose meaning differs between the source generation and current v4.
Apply the Final osCommerce Readiness Gate
| Readiness question | Required outcome |
|---|---|
| Is source lineage confirmed? | Version, branch or fork, database, front ends, extensions, and customizations are recorded. |
| Is catalog scope complete? | Products, Categories, brands, suppliers, channels, stock, pricing, and media have owners. |
| Are attributes and properties classified? | Selectable, descriptive, configurable, and custom relationships are separated. |
| Are Customers and Orders interpretable? | Groups, addresses, totals, statuses, and external references are documented. |
| Are Apps and custom data classified? | Active extension-owned records have explicit destination decisions. |
| Are content and routes inventoried? | CMS, legacy content, media, and important URLs are tied to owning objects. |
| Are backup, access, and samples ready? | The source package is restorable and representative IDs are listed. |
Preparation remains open when a critical legacy table, channel assignment, Customer-group rule, Order-total module, or external identifier still lacks an owner and disposition.
Conclusion
osCommerce preparation is a lineage exercise as much as a data inventory. Current v4 Products, front ends, Customer groups, attributes, properties, CMS content, and Apps must be distinguished from legacy tables, community extensions, and modified code.
A controlled source package makes those boundaries explicit and provides representative records for migration configuration.
Common Questions
Why must the osCommerce source version or fork be confirmed first?
Current v4 and legacy osCommerce installations can store and interpret catalog, Customer, Order, content, and extension data differently. Version lineage determines which relationships and tables actually own the source records.
What is the preparation difference between attributes and properties?
Attributes usually represent selectable or configurable Product values and can affect price, weight, inventory, or downloads. Properties describe structured characteristics used for display, filters, search, or comparison.
How should sales-channel or front-end assignments be documented?
Record which Products, Categories, content, languages, and URLs belong to each front end. Shared records and channel-specific records should be visible in a scope matrix.
Should legacy extension tables be copied into current osCommerce v4 fields?
Not automatically. Identify the extension, business meaning, parent record, and continuing consumer first. A modern feature with a similar label may not use the same schema or behavior.
Which Orders belong in an osCommerce sample set?
Include guest and registered Orders, several statuses, attribute selections, discounts, taxes, shipping, payment references, refunds, comments, tracking, and extension-created totals or external IDs.
Does the database backup contain osCommerce images, downloads, and extension files?
No. Prepare the relevant file tree alongside the database so media, downloadable files, themes, Apps, legacy extensions, and custom code remain available.