osCMax preparation should treat the Store as a layered legacy installation rather than a fixed product schema. The database often contains an osCommerce-derived core, osCMax package additions, contribution-owned tables and columns, merchant-specific modifications, template assets, language files, and external-system identifiers. Two Stores with similar storefronts can therefore require different source evidence.
The readiness objective is to identify which layer owns each important Product, Customer, Order, content, and operational record. Every preparation area should define an action, owner, evidence artifact, and ready condition. Current lifecycle, compatibility, or exact bundled-feature assumptions should not be used when authoritative source documentation is unavailable; the actual installation is the evidence.
Establish Version Lineage, Store History, and Source Access
Record every available indicator of the osCMax installation’s lineage: displayed version, release package or repository history, upgrade notes, database schema changes, modified files, installed contributions, template package, hosting environment, and external integrations. Where records conflict, note the uncertainty rather than selecting the newest-looking label.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Record version and package evidence | Technical owner | Admin footer, package files, changelog, database version values | Known and conflicting version indicators are documented. |
| Record upgrade and maintenance history | Developer, agency, or merchant | Deployment notes, backup dates, patch history | Major schema or code transitions are identifiable. |
| Confirm database and file access | Hosting owner | Access status, database name, document root, archive availability | The intended live installation can be examined and backed up. |
| Identify template and language layers | Storefront owner | Template name, language directories, overrides, screenshots | Content and presentation files can be separated from database records. |
| Identify scheduled jobs and external systems | Integration owner | Cron list, exports, imports, ERP/accounting/shipping references | Data that changes outside the admin interface is known. |
Freeze undocumented code and schema changes while evidence is assembled. Trading can continue, but late Product imports, contribution installation, field changes, or template replacement should enter a change log.
Separate Core Commerce Records From Package and Contribution Data
Start with the osCommerce-derived core: Products, Product descriptions, Categories, manufacturers, attributes, Customers, address books, Orders, Order products, Order totals, statuses, reviews, specials, and other standard relationships present in the installation. Then identify additional fields and tables introduced by osCMax packaging, contributions, or custom development.
A familiar table name does not prove that every column is core. Build a schema and ownership inventory that records table, field or entity, related core ID, creating contribution or modification where known, business purpose, current use, and destination decision.
| Source layer | Preparation evidence | Ready condition |
|---|---|---|
| Core Product and Category records | Product, Category, manufacturer, attribute, price, stock, and image extracts | Basic catalog relationships are complete. |
| Package-added fields | Schema diff, admin screenshots, representative records | Package-level values are distinguished from core fields. |
| Contribution table | Table definition, key relationships, module name, sample IDs | The table’s business entity and parent records are known. |
| Direct core modification | Modified-file list and affected database fields | Business meaning is documented independently of the old code. |
| External-system field | Identifier map and current system owner | Stable cross-system keys remain traceable. |
| Obsolete table or column | Last-use evidence and merchant decision | Technical residue is marked for archive or exclusion. |
Do not prepare a migration solely from a generic osCommerce table list. The live schema and code determine the actual Store.
Prepare Products, Attributes, Combination Stock, Images, and Pricing
Legacy Product options and attributes can be extended through contributions that add combination stock, independent SKUs, extra images, custom fields, quantity discounts, Customer Group pricing, downloads, bundles, or Product builders. Record the business behavior of each structure instead of assuming that every option is a simple Product attribute.
| Source pattern | Action | Evidence | Ready condition |
|---|---|---|---|
| Standard attribute | Record option, value, Product assignment, and price or weight effect | Attribute export and representative Product IDs | Purchase-choice meaning is explicit. |
| Combination-level SKU or stock | Identify the contribution table and combination key | Combination matrix with quantity and SKU | Sellable combinations can be distinguished from the parent Product. |
| Multiple or attribute-specific images | Record image files, sequence, and Product/option relationship | Media manifest and file paths | Original assets and attachment meaning are available. |
| Extra Product field | Record field owner, type, display use, and external consumer | Schema row and sample Products | Active values have a destination owner. |
| Quantity or Customer-specific price | Record Product, group or threshold, currency, dates, and amount | Pricing inventory | Conditional pricing is not reduced to the base price. |
| Downloadable Product | Record file, access relationship, expiry or limit where used | Product and historical Order samples | Digital-delivery evidence is complete. |
The catalog owner should approve any cleanup of duplicate attributes, image names, SKUs, or prices. Apparent duplication can reflect contribution behavior or an external-system key.
Prepare Customers, Address Books, Groups, and Account Extensions
Customer preparation should include account identity, address-book entries, default-address relationships, group or wholesale classification, tax identifiers, approval states, loyalty or credit records, referral values, custom fields, and external CRM or accounting IDs where present.
Create a Customer-extension ledger. For each added field or table, record the related Customer key, business purpose, whether the value is current or historical, privacy owner, and whether another system remains authoritative.
| Customer area | Evidence | Ready condition |
|---|---|---|
| Customer account | Identity, status, email exceptions, dates, and external IDs | Duplicate or conflicting identities have a disposition. |
| Address book | Address rows and default-address links | Reusable addresses remain separate from Order snapshots. |
| Wholesale or dealer group | Group assignment plus price, tax, access, or payment effects | Commercial meaning is documented beyond the label. |
| Loyalty, credit, or reward contribution | Balance, transaction history, and parent Customer ID | Current balance and historical evidence can be separated. |
| Custom profile fields | Schema, field type, privacy purpose, sample values | Each active field has an owner. |
Prepare Orders, Order Totals, Status History, and Extension Records
Orders often carry the most important historical evidence in an osCMax Store. Prepare Order headers, Customers or guest details, billing and shipping snapshots, Product lines, model or SKU values, selected attributes, quantities, prices, taxes, discounts, shipping, payment labels, statuses, comments, and external references.
Order-total modules require special attention. Separate subtotal, tax, shipping, coupon, gift voucher, surcharge, low-order fee, credit, discount, and other contribution-created lines. Preserve labels, amounts, sort order, and relation to the final total.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Product and attribute lines | Commerce owner | The purchased item and selected values are readable without the live catalog. |
| Address snapshots | Customer-service owner | Historical addresses are not overwritten by current Customer data. |
| Order totals | Finance or commerce owner | Every material amount has a known module or business meaning. |
| Status and comments | Operations owner | Historical state sequence and notes are interpretable. |
| Payment and shipping references | Finance or fulfillment owner | Transaction, carrier, tracking, and method labels are recorded. |
| Returns, vouchers, credits, or after-sale extensions | Customer-service owner | Related records and remaining balances are linked to the Order. |
| Export or reconciliation IDs | Integration owner | Accounting, ERP, marketplace, or warehouse systems can locate the transaction. |
Do not use current payment or shipping configuration as a substitute for historical labels and references.
Build the Contribution and Customization Inventory
The contribution ledger is the central osCMax preparation artifact. Group contributions by business effect rather than installation name alone.
| Contribution area | Evidence to prepare | Ready condition |
|---|---|---|
| Catalog and pricing | Added tables/fields, representative Products, admin screens | Active Product and pricing records have owners. |
| Customer and access | Groups, approvals, tax fields, loyalty, credit, restricted content | Account behavior can be separated into distinct relationships. |
| Checkout and Order totals | Configuration summary and representative Orders | Historical amounts are distinguishable from future behavior. |
| Payment and shipping | Transaction or shipment references, status fields | Historical evidence is retained without old credentials or code. |
| Reporting and exports | Export flags, batch IDs, external system keys | Continuing operational references are known. |
| SEO and content | Route tables, metadata, pages, redirects | Public paths and content owners are explicit. |
| Template and interface | Template files, boxes, language entries, screenshots | Business content is separated from presentation. |
| Custom code | Modified-file list, schema changes, workflow owner | The business rule is documented independently of implementation. |
Classify each item as active-required, active-replaceable, historical-only, inactive-with-retained-data, obsolete, or unknown. Unknown business-critical items remain blockers to readiness.
Prepare Content, Templates, Language Files, Media, and URLs
osCMax storefront content may live in Product or Category descriptions, information-page contributions, static files, template boxes, language files, banners, buttons, images, or custom modules. Inventory the content by owner and route.
Prepare:
- active policy, information, contact, and service pages;
- Product and Category descriptions and images;
- template boxes containing business content;
- language-file text that must remain customer-facing;
- menus and navigation destinations;
- important Product, Category, manufacturer, and content URLs;
- redirects or rewrite rules created by contributions or server configuration;
- original images, downloadable files, and non-generated media assets.
A screenshot proves presentation but not the underlying record. Pair screenshots with file paths, database keys, or content sources where possible.
Prepare Hosting, Runtime, Security, and Backup Evidence
Legacy hosting conditions can determine whether source data and files are accessible. Record PHP and database versions, character set or collation, web-server configuration, scheduled jobs, storage paths, permissions, and known security or maintenance constraints. These details are source interpretation evidence, not a requirement to reproduce the old environment on the Target Platform.
Create a restorable backup set containing the database and relevant file tree from the same Store state. Include templates, language files, images, downloads, contribution code, configuration references, and custom scripts. Record encryption, compression, size, timestamp, and access owner.
| Backup area | Evidence | Ready condition |
|---|---|---|
| Database | Complete dump and restore-readiness note | Core and contribution tables are present. |
| Files | Source archive or accessible file tree | Templates, contributions, images, downloads, and custom code are available. |
| Environment | Runtime and server notes | Version-dependent parsing issues can be anticipated. |
| Security | Credential owner, access limits, sensitive-data handling | Access can be provided safely through the intended process. |
| Change log | Late changes after backup | New Orders or structural changes are visible. |
Select Representative Migration Test Samples
Prepare a sample manifest with source IDs, related tables, files, contribution owner, and expected source meaning. Include ordinary records and the cases most likely to expose schema variance.
Include:
- a simple Product and a Product with standard attributes;
- a Product with combination-level stock or SKU where used;
- a Product with multiple or contribution-owned images, downloads, special prices, or custom fields;
- Customers with several addresses, wholesale or dealer classification, custom fields, loyalty, credit, or external IDs;
- guest and registered Orders with attributes, several Order-total lines, unusual statuses, payment/shipping references, refunds, vouchers, or export IDs;
- important content and route examples;
- one active contribution-owned entity, one custom-table record, and one external-system relationship;
- one record proposed for retirement to document why it is not part of the active target scope.
Apply the Final osCMax Readiness Gate
| Readiness question | Required outcome |
|---|---|
| Is the installation lineage documented? | Version indicators, history, package evidence, and conflicts are recorded. |
| Are core and extended schemas separated? | Core tables, package additions, contributions, and custom fields have owners. |
| Is catalog complexity represented? | Attributes, combination stock, images, pricing, downloads, and identifiers are documented. |
| Are Customers and Orders interpretable? | Groups, addresses, totals, statuses, after-sale records, and external IDs are complete. |
| Are contributions classified? | Active, historical, obsolete, and unknown items have explicit dispositions. |
| Are content and storefront assets inventoried? | Pages, language text, templates, media, URLs, and redirects are traceable. |
| Is the backup restorable? | Database, files, and environment notes correspond to the same Store state. |
| Is the sample set representative? | Core, contribution, custom-table, historical, and retirement cases are included. |
Preparation remains open when a business-critical contribution, custom table, Order-total line, or external identifier has no owner.
Conclusion
osCMax preparation depends on evidence from the actual installation. Core commerce records, package additions, contributions, custom tables, templates, language files, Order totals, and external-system keys must be separated before migration configuration can reflect the Store accurately.
A restorable source package, contribution ownership ledger, and representative sample manifest provide a controlled readiness foundation for migration configuration.
Common Questions
Why is a generic osCommerce schema insufficient for osCMax preparation?
osCMax installations commonly include package additions, contributions, custom fields, modified core files, and custom tables. The live schema and code determine which records exist and what they mean.
What should be recorded for each osCMax contribution?
Record its business purpose, status, affected core data types, tables or fields, representative source IDs, external dependencies, and whether its records are active, historical, replaceable, obsolete, or unknown.
Why do osCMax Order totals need a separate inventory?
Order-total modules can create shipping, tax, coupon, voucher, surcharge, discount, fee, credit, and other lines. The label, amount, sequence, and module owner explain the historical total.
Should obsolete osCMax modules and tables be included?
They should be documented, then marked for archive or exclusion when no active or historical workflow depends on them. Do not force obsolete technical residue into a generic target field.
What belongs in the osCMax source backup?
Prepare the database and relevant files from the same Store state, including templates, contributions, language files, images, downloads, configuration references, and custom scripts, together with environment notes.
How should osCMax representative samples be selected?
Use core and contribution-shaped Products, Customers with account extensions, Orders with several total lines, content and route examples, custom-table records, external identifiers, and at least one deliberate retirement case.