An osCMax preparation package must explain the installation that actually exists. A version label or familiar osCommerce table can conceal package additions, contribution records, and years of local changes. Preserve that evidence and its business owners before cleanup, then confirm how each required relationship will be represented in the prospective destination. This installation evidence applies to an actual osCMax Source. For another Source, preserve its real model and access limits, while qualifying the intended osCMax package independently.
Start from the Source Store requirements that must survive: Products and sellable combinations, Customers and account relationships, Orders and historical meaning, content, identifiers, pricing, shipping, payment context, and external-system dependencies. Then decide where each requirement will be represented in osCMax, what target-side setup is required, what evidence must be collected, and what should be redesigned or retired.
Establish Version Lineage, Store History, and Source Access
Identify the actual Source Platform and intended osCMax package separately. When osCMax is the Source, record its displayed version, package/repository history, upgrades, schema changes, modified files, contributions, templates, runtime, and integrations. For another Source, collect equivalent requirements without inventing osCMax tables. Preserve conflicting indicators rather than choosing the newest-looking label. Confirm the destination deployment and compatible contributions from its actual code and schema.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| For an osCMax Source, record version and package evidence; otherwise identify the actual Source model | Technical owner | For an osCMax Source: admin footer, package files, changelog and database version values where accessible; otherwise actual Source identity/model evidence and restrictions | Known and conflicting actual Source version indicators are documented; destination package evidence is recorded separately. |
| Record the actual Source upgrade and maintenance history where available | Developer, agency, or merchant | Deployment notes, backup dates, patch history | Major schema or code transitions are identifiable. |
| Confirm actual Source database/files where accessible, or the available connection/export package | Actual Source hosting, platform-access or export owner | For an accessible osCMax Source: access status, database name, document root and archive availability; otherwise permitted connection/exports, file availability and restrictions | The correct Source installation can be examined and backed up where access permits; otherwise available evidence and recovery limits are documented, with required gaps resolved, excluded by agreement, or held. |
| Identify actual Source template and language layers where present | Storefront owner | Actual Source template name, language directories, overrides and screenshots where available; otherwise content sources and presentation evidence with access limits | Content and presentation ownership are separated from database records where applicable; required inaccessible sources have an accepted treatment. |
| 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. |
Keep dated original identifiers, media and available Source evidence protected before cleanup. For an accessible osCMax Source, include original code, schema and files; otherwise record the actual export/archive contract and its limits. Record late imports, contribution changes, field edits, and template replacement in a change log. Assign the party responsible for ongoing source maintenance, security, compatibility, and recovery, plus the intended destination’s runtime and deployment owner. Historical package documentation does not establish current support for that environment.
Separate Core Commerce Records From Package and Contribution Data
For an osCMax installation, distinguish the osCommerce-derived core relationships actually present from package additions, contributions, and local modifications. Inspect Products, descriptions, Categories, manufacturers, attributes, Customers, addresses, Orders, lines, totals, statuses, reviews, and specials where used. A similar record on another Source needs its own owner and key; shared ancestry does not prove that the schema or behavior matches.
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.
Record Category, Manufacturer, and Navigation Relationships
A catalog extract can retain Category names while losing the relationships that make Products discoverable. Preserve the actual Source Category IDs, parent-child relationships, Product memberships, language values, ordering and public routes where present. Identify obsolete, internal-only or navigation-only entries separately. For an osCMax Source, bind the evidence to its installed schema and contribution owners; for another Source, use its own keys and classification model. Similar labels do not establish equivalent relationships.
Record each required Product-to-Category membership without duplicating Product identity to imitate placement. Preserve manufacturer identifiers and Product links, then distinguish internal manufacturer values from public manufacturer listings or landing routes that readers still need. Pair important routes with their owning records, descriptions and media where present. The catalog and SEO owners should agree what remains public, what is retired, and which old paths need an intended destination. A manufacturer label alone does not establish a public page or a procurement relationship.
Prepare navigation separately from catalog classification. Record each important menu or template-box destination, the Category, manufacturer or content record it exposes, and any contribution, language or access rule that controls its visibility. Assign an intended osCMax consumer and implementation owner for each required discovery path. For example, a Product linked to two source Categories needs its identity and both memberships preserved; two menu links do not prove that two Products are required. The evidence should explain the intended browse path before a representative sample is selected, while the actual migrated behavior remains a later validation task.
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. |
Freeze original Product, attribute, combination, SKU, image, file, and pricing relationships before cleanup. Keep a source-to-intended identity ledger for approved changes, including records still referenced by historical Orders. The catalog owner must explain apparent duplication: it can reflect contribution behavior or an external key. Confirm the compatible destination owner for each required combination, price, or file-access pattern rather than assuming that any osCMax package provides it.
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 with parent keys, business purpose, current versus historical meaning, privacy ownership, and external authority. Prepare the exact Source-to-Target password-verification decision separately from Customer completeness. Where continuity is unavailable, record reset, activation, or first-login handling and the identity-provider and customer-communication owners.
| 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. |
Preserve historical payment/shipping labels, status sequences, total-line labels, amounts, and order independently of current configuration. Do not rewrite old transactions to match today’s catalog or contribution settings. Record the events that must be contained so imported history cannot send email, charge a buyer, change stock or credit, grant access, or create fulfillment work.
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 contribution as active-required, active-replaceable, historical-only, inactive-with-retained-data, obsolete, or unknown. Confirm the compatible destination consumer or agreed retained-system treatment for required records. Resolve unknown business-critical ownership, exclude the affected requirement explicitly by agreement, or hold that scope; an assigned future owner alone is not 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
For an actual self-hosted Source, legacy hosting conditions can determine whether data and files are accessible. Record available PHP and database versions, character set or collation, web-server configuration, scheduled jobs, storage paths, permissions, and known security or maintenance constraints. For another or restricted Source, record its available platform/export evidence and access limits instead. These details are source interpretation evidence, not a requirement to reproduce the old environment on the Target Platform.
For an accessible osCMax Source, create a recoverable package with the complete database and relevant files from the same state, including templates, language files, media, downloads, contribution code, configuration references, and custom scripts. For another or restricted Source, preserve the available dated exports, archives and original media; document recovery coverage, limitations and owner without treating record exports as a full installation backup. Keep originals protected and resolve required omissions, exclude them explicitly by agreement, or hold the affected scope. Capture the character set/collation where available and representative text with its intended meaning before conversion; a readable export is not proof that identifiers or characters survived normalization.
| Backup area | Evidence | Ready condition |
|---|---|---|
| Actual Source database where accessible, or available archives | For an accessible osCMax Source: complete dump and restore-readiness note; otherwise dated exports/archives with recovery coverage, limitations and owner | Core and contribution tables are present for an accessible osCMax Source. Other or restricted Source coverage is documented; required omissions are resolved, excluded by agreement, or held, and exports are not treated as a full restore. |
| Files | Actual Source archive or accessible file tree, original/remote-media inventory, and unavailable-file record | Required Source images and downloads are available. Templates, contributions and custom code are included for an accessible osCMax Source; required missing files or behavior are resolved, excluded by agreement, or held. |
| Environment | Actual Source runtime/server notes where accessible, or available provider/export constraints | Version-dependent parsing issues and recovery limits can be anticipated; intended osCMax runtime/deployment requirements are assessed independently. |
| Security | Actual Source credential/export owner, access limits and sensitive-data handling | Required Source access or agreed inputs can be provided through the intended process; required unresolved restrictions hold the affected scope. |
| Change log | Late changes after backup | New Orders or structural changes are visible. |
Confirm the Intended osCMax Package and Discovery Consumers
Record the intended osCMax package, actual code/schema, runtime and deployment requirements, access roles, and compatible contributions needed for the agreed business requirements. Name technical and business owners for those decisions. Source package ancestry and historical manuals do not establish destination compatibility, and the old Source runtime is not automatically the intended runtime.
Prepare destination ownership for required combination stock, pricing, account extensions, historical-total interpretation, content and public discovery paths. Tie Category memberships, manufacturer routes and menu or template-box destinations to the compatible component that will consume them. Resolve required incompatibilities, agree explicit exclusions, or hold the affected scope before samples are selected; assigning a developer and a future date is not sufficient.
Select Representative Migration Test Samples
Prepare a sample manifest with source IDs, tables, linked files, contribution owner, business reason, original values and meaning, intended representation, agreed exclusions, and a reviewer. Include ordinary records and cases that expose schema variance, changed identities, text encoding, and historical contributions. These expectations prepare later migrated-outcome proof rather than replace it. Where discovery matters, include a Category hierarchy, a Product with meaningful memberships, and a public manufacturer or menu destination with its intended consumer; use actual Source keys, not assumed osCMax IDs.
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 |
|---|---|
| Are actual Source lineage and intended osCMax package evidence documented? | Actual Source version/model indicators and conflicts are recorded; package history and code/schema evidence apply where present. Intended osCMax package evidence is separately owned. |
| Are core and extended schemas separated? | Actual Source core records and any package additions, contributions or custom fields have owners; an osCMax schema is required only for an osCMax Source. |
| Is catalog complexity represented? | Actual Source attributes, combination stock, images, pricing, downloads and identifiers are documented where used, with their real owners. |
| Are classification and discovery relationships prepared? | Actual Source Category hierarchy, Product memberships, manufacturer purpose and public routes are documented where present; menu/template-box consumers and intended osCMax implementation owners are assigned for required paths. |
| 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 actual Source recovery coverage established? | An accessible osCMax Source has complete database/files and environment evidence from the same state. Another or restricted Source has documented archives, recovery limits and owner. Required gaps are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
| Is the intended osCMax implementation prepared? | Actual package/code/schema, runtime/deployment owner, access roles and compatible contribution/discovery consumers are confirmed for agreed requirements. Required incompatibilities are resolved, excluded by agreement, or held. |
| Is the sample set representative? | Actual Source core, contribution, custom-table, historical and retirement cases are included where present, with Category/membership/public-route cases for required discovery paths. |
Preparation remains open when a required contribution, custom table, historical total, file, or external identifier lacks evidence and an accepted treatment. Resolve the gap, agree an explicit exclusion, or hold the affected scope. Noncritical exceptions need an accepted boundary, scope effect, owner, and decision date; they cannot stand in for missing required relationships. Apply the same decision to required discovery relationships, recovery omissions and incompatible destination consumers.
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 Source package with documented recovery coverage and limits, contribution ownership ledger, discovery relationship evidence, and representative sample manifest provides a controlled readiness foundation for migration configuration. Complete database-and-file recovery remains required for an accessible native osCMax Source; another or restricted Source needs its actual archive contract and accepted limitations. Carry independent destination prerequisites and any held scope into the next decision.
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. This full database-and-file package applies to an actual osCMax Source with the relevant access. For another or restricted Source, preserve its available exports, archives and original media, and record recovery coverage, limits and owner. Exports alone do not establish a full installation restore; required gaps need resolution, an agreed exclusion, or a hold.
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.
What if version labels and schema evidence disagree?
Preserve both and record the conflict. Use package files, deployment history, modified code, actual tables, and representative records to establish the model that owns the data. Assign a technical owner to resolve requirements affected by the uncertainty. A historical manual or newer-looking footer is not proof of current compatibility or maintenance.
Should historical Order statuses be rewritten to match current labels?
No. Preserve the recorded sequence and its operational meaning, together with original totals and module ownership. Prepare an explicit destination interpretation while containing notification, payment, inventory, credit, and fulfillment effects. A renamed state must not erase historical evidence or replay an old operation.