osCommerce preparation must establish which generation and component gives each record its meaning. A legacy attribute, a current property, and a module-owned stock combination can share familiar labels while requiring different handling. Preserve the original relationships and confirm the prospective destination’s actual build and owners before choosing mappings.
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
Identify the actual Source Platform and intended osCommerce environment separately. For an osCommerce Source, record version, fork, database prefix, hosting, front ends, languages, currencies, modules, modified files, custom tables, and synchronizations. For another Source, collect equivalent business relationships without inventing osCommerce IDs. Confirm destination generation, compatible enabled Apps, access roles, maintenance/deployment owners, and representation decisions separately. Preserve upgrade or schema evidence that explains surviving legacy tables.
Prepare the source access required for the selected migration path. For an accessible osCommerce Source, the technical owner should confirm that the connection reaches the correct database and file tree, and that backups belong to the same Store state. For another or restricted Source, confirm its permitted connection or export package, available files, coverage and access limits. Do not require osCommerce database/file access from a different Source; destination access is a separate prerequisite.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Identify source generation and code lineage | Technical owner | Version evidence, repository or package note, fork history | The actual Source Platform and any osCommerce generation/fork are recorded separately from the intended destination. |
| Confirm actual Source database/files where accessible, or the permitted connection/export package | Actual Source hosting/database, platform-access or export owner | For an accessible osCommerce Source: database name/prefix, connection status and document root; otherwise actual Source connection/exports, file availability and restrictions | The required connection reaches the correct Source Store, or the agreed input package is available; required access restrictions have an accepted treatment. |
| Inventory actual Source extensions and core modifications where present | Developer or agency | Actual Source extension list, modified-file record and custom-table list where accessible; otherwise available component/field ownership and restrictions | Actual Source native, extension-owned and custom records can be separated; required inaccessible ownership evidence is resolved, excluded by agreement, or held. |
| Record actual Source front ends or channels, 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 the actual Source Store have a named authority; osCommerce is the Source only where selected. |
Freeze original schema, identifiers, field definitions, assignments, code, media, and historical evidence before cleanup. Record late extension, model, or route changes. Keep an approved source-to-intended ledger when normalization changes identities or relationships. Assign maintenance and compatibility ownership for the actual source and destination; a familiar platform name does not establish their readiness.
Prepare Products, Categories, Brands, Suppliers, and Front-End Scope
For an actual current-v4 environment, inventory the catalog relationships it uses: Categories, brands, suppliers, front ends, Customer groups, language values, stock modes, media, prices, SEO, and merchandising. Record the compatible enabled component and settings behind each relationship. A legacy Store may use simpler tables plus extensions; matching feature names do not make those records native to the intended build.
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
The documented v4 model separates attributes from properties. Record the actual attribute type, template, choices, price/weight effect, file relationship, and any stock-owning component; independent combinations need their real keys and compatible owner. Record property definitions, values, language, and active display/filter/search consumers separately. A legacy attribute may hold several of these meanings, so its name alone cannot settle destination ownership.
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
In a v4 environment, Customer-group behavior can involve visibility, tax, accumulative discounts, and defaults for visitors or new accounts. Record the actual compatible enabled module and settings for each effect; group assignment alone is insufficient. Wholesale, B2B, credit, loyalty, and approval records may have separate extension owners, and legacy Stores can represent them 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. |
Customer identity and account access need separate readiness decisions. Record the source verification method and the exact Source-to-Target password-continuity decision. Where needed, prepare reset, activation, or first-login handling with identity-provider and customer-communication owners. An email address or a source password field cannot establish usable destination authentication.
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. |
Preserve the original transaction-time values and relationships independently of current Product, Customer-group, tax, shipping, or module settings. Record the events that must be contained so imported history does not send notifications, capture payment, grant access, deduct stock, change credit, or create fulfillment work. Treat remaining obligations separately from historical snapshots.
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 recoverable source package tied to one state, with original database/export coverage and relevant files kept dated and protected. Record remote media and restoration responsibility separately. When the Source is restricted or another platform, use its actual archive/access contract rather than assume osCommerce database access. Confirm destination deployment and compatible application prerequisites independently from the backup. For an accessible osCommerce Source, retain the complete database and relevant file tree, including custom schema and code needed for recovery. Record what can and cannot be recovered under the actual Source contract, with its recovery owner. Exports alone do not establish a full installation restore; required omissions need resolution, an agreed exclusion, or a hold.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup where accessible, or available Source archive | Actual Source database administrator or export owner | For an accessible osCommerce Source: timestamped complete dump, prefix and generation note; otherwise dated exports/archives with coverage, limitations and recovery owner | An accessible osCommerce backup includes the complete intended Source schema and recovery evidence. Other or restricted Source coverage and accepted limits are documented without claiming a full restore from exports. |
| Files and media | Hosting or technical owner | Actual Source file archive or accessible source tree, remote-media inventory, and availability/recovery limitations | Required original media and downloads are available. osCommerce extensions and custom code are included when that is the actual accessible Source; required missing files are resolved, excluded by agreement, or held. |
| Lineage record | Technical owner | Actual Source version/fork history and upgrade notes where applicable, or available platform/export model evidence and restrictions | Actual Source structures can be interpreted correctly; osCommerce legacy/current distinctions apply where present, and destination generation is qualified separately. |
| Access register | Project owner | Actual Source access/export owner, connection status and restrictions | Required Source access or agreed inputs are available without publishing credentials; unresolved required restrictions hold the affected scope. |
| Change log | Store administrator | Structural changes after the evidence cut-off | Late changes can be incorporated deliberately. |
Confirm the Intended osCommerce Generation and Component Owners
Prepare the intended osCommerce generation and actual build separately from Source recovery. Record destination front-end and language scope, access roles, runtime/deployment responsibilities, and compatible enabled Apps or other components needed for the agreed requirements. A legacy Source backup or a familiar feature label does not establish that a current destination component can consume those records.
Confirm the intended owner and representation for buyer choices, properties, independent stock combinations, Customer-group effects, historical records, CMS routes and external-system keys. Use the actual Source semantics and preserve its identity ledger when representations differ. Required component, scope or compatibility gaps need resolution, an explicit agreed exclusion, or a hold before representative samples are selected.
Select Representative Migration Test Samples
Prepare a manifest with source IDs, owner, reason, original values, linked files, source relationships, intended representation, agreed exclusions, and a reviewer. Include generation-dependent cases where they actually exist; do not require both v4 and legacy structures from one Store. Document account/group effects and the real owner of combination stock. These expectations support later validation rather than establish migrated proof.
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? | Actual Source platform, version/model and scope are recorded. Database, front ends, osCommerce branch/fork, extensions and customizations are documented where present; intended destination generation is separate. |
| Is catalog scope complete? | Actual Source Products, Categories, brands/manufacturers, suppliers, channels, stock, pricing and media have owners where present; destination equivalents are separately defined. |
| 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? | Actual Source CMS or legacy content, media and important URLs are tied to owning objects where present; intended osCommerce content consumers are separately defined. |
| Is the intended osCommerce implementation prepared? | Actual generation/build, front-end/language scope, access roles, runtime/deployment owner and compatible component consumers are confirmed for the agreed requirements. Required incompatibilities are resolved, excluded by agreement, or held. |
| Are backup, access, and samples ready? | Actual Source access or agreed inputs are available and representative IDs are listed. Accessible native database/files have recovery evidence; other or restricted Source archives have documented coverage, limits and owner. Required gaps are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
Resolve required unknown tables, channel assignments, group rules, historical totals, files, or external identifiers, exclude them explicitly by agreement, or hold the affected scope. An owner and future decision date do not make a required relationship ready. Accepted noncritical exceptions need a boundary, scope effect, and owner.
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. Carry the actual Source recovery coverage and accepted limits, independent destination-generation prerequisites, and any held scope into that decision; record exports do not establish full installation recovery.
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?
In the documented v4 model, attributes represent buyer choices or configurable requirements; their price, weight, file, and stock effects depend on actual definitions and owning components. Properties describe structured characteristics with configured display, filter, or search consumers. Legacy or customized records need their actual meaning classified rather than inferred from the label.
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. This native database-and-file package concerns an actual osCommerce Source with the relevant access. Another or restricted Source needs its own available exports, archives, original media, recovery coverage, limits and owner. Exports alone do not establish a full installation restore; required gaps need resolution, an agreed exclusion, or a hold.
Does an email address prove that account access is ready?
No. It helps identify an account but does not establish that the destination can verify its password or use the same identity provider. Prepare the exact supported path or required reset, activation, or first-login treatment separately from profile completeness, with clear identity and communication owners.
Do Customer group names prove that visibility and discounts are prepared?
No. Preserve assignments, actual visibility restrictions, tax treatment, discount criteria, defaults, and the compatible enabled component that owns each rule. Record historical Order context separately from current commercial settings. Matching labels between generations do not establish equivalent behavior.