OsCommerce → to Shopify

osCommerce to Shopify: one family, one schema, one plan

osCommerce was one of the first open-source carts, and a whole family of platforms grew out of it: osCMax, CRE Loaded and Loaded Commerce, TomatoCart, Zen Cart and several German systems. Many of these stores have run for fifteen years or more, with contributions layered on top of a core that stopped changing long ago. This guide covers how we handle an osCommerce to Shopify migration for every member of the family, what the shared database gives us, and the parts that need care: attribute price prefixes, the old URL formats, MD5-era passwords and servers still on PHP 5.

Why stores leave osCommerce

• The 2.x line has stopped moving. The last stable 2.x release on the official repository is 2.3.4.1, from 2017. Community work continued in Phoenix, and osCommerce 4 is a different codebase, so a 2.x store has no in-place upgrade path.
• Old PHP. osCommerce 2.2 and the platforms built on it call PHP’s original mysql_ functions, which were removed in PHP 7.0. Many of these stores can only run on PHP 5, which lost security support at the end of 2018.
• Contribution sprawl. Features such as SEO URLs, stock by attribute and header tags came from community contributions merged by hand into core files. Each one makes the next change harder.
• Security and PCI scope. A self-hosted checkout puts patching, hardening and your share of PCI compliance on you and your host. Shopify is a PCI DSS Level 1 service provider and runs the checkout itself.
• Checkout and payments. Shop Pay, accelerated wallets and current payment gateways replace payment modules that often no longer match their providers’ APIs.

To be fair, a Phoenix or osCommerce 4 store on a current server is a maintained platform, and owning the code has real value. If you are happy there, staying is reasonable. The rest of this guide assumes you have decided to move.

What migrates from osCommerce to Shopify

osCommerce 2.x has no general export screen and no REST API for products, customers and orders, so we work from the MySQL database, which on a self-hosted store is the complete record.

Data	Source on osCommerce	Moves to Shopify?
Products with model numbers, names, descriptions, prices, weights, stock, images, status	products, products_description, plus products_images from 2.3	Yes. Model numbers become SKUs, and each language’s description is kept for Shopify’s translations.
Attributes (options and values) with price prefixes	products_attributes, products_options, products_options_values	Yes, redesigned as variants, add-ons or line item properties. See below.
Categories and manufacturers	categories, products_to_categories, manufacturers	Yes. Categories become collections and menus; manufacturers become the vendor.
Specials	specials	Yes, as compare-at prices, or scheduled discounts where they had expiry dates.
Customers and address books	customers, address_book	Yes, with every saved address and the newsletter flag as marketing consent.
Passwords	customers.customers_password	No. Shopify cannot use these hashes. Customers reset on first login or use passwordless sign-in.
Orders with line items, attributes, totals and status history	orders, orders_products, orders_products_attributes, orders_total, orders_status_history	Yes. Real orders with original numbers and dates, attribute text on each line, and the full status history as notes.
Tracking numbers	Usually status comments or a contribution’s table	Yes, where they can be found. Stock 2.x has no tracking field, so we parse them out.
Reviews	reviews, reviews_description	Yes, into Judge.me or your chosen review app.
Downloadable products	products_attributes_download and the download folder	Yes, through a digital downloads app.
Stored card fields	orders.cc_number and related columns	No. We never carry them. See the security section.
Template, boxes and contributions	Theme and PHP files	No. The design is rebuilt and each contribution is mapped to a Shopify app, a native feature, or dropped.

osCommerce URLs and redirects

A stock store serves products at /product_info.php?products_id=12 and categories at /index.php?cPath=1_4, where the path lists category IDs from parent to child, so 1_4 is category 4 inside category 1. Manufacturer pages use /index.php?manufacturers_id=3, and information pages sit at files such as /shipping.php and /conditions.php. Cart links can add an attribute string to the ID, as in products_id=12{2}3, and some of those end up indexed.

Most long-running stores installed an SEO URL contribution. Ultimate SEO URLs and its relatives produce /blue-widget-p-12.html for products and /widgets-c-1_4.html for categories, with -m- for manufacturers, and TomatoCart builds the same shape natively. Stores often switched formats over the years, so both forms can still be in Google’s index.

Shopify uses /products/handle and /collections/handle. Because every legacy form carries the numeric ID, we key the redirect map on IDs rather than guessing from names: -p-12 and products_id=12 both land on product 12’s new URL, and a cPath goes to the collection for its last ID. Shopify’s help center warns that redirects from URLs with query strings may not behave as expected, so we request every one against the store before launch, and any that do not resolve get a fallback on the 404 template that reads the ID and forwards the visitor. Search Console fills in URLs the database no longer knows.

Tools

Cart2Cart, a partner of ours, lists osCommerce as a source, and LitExtension supports osCommerce, osCMax, CRE Loaded, Loaded Commerce and TomatoCart. Both are fine for a first pass on products and customers. Their limits are the same on every platform: tracking numbers do not come across, refunded orders tend to land as plain paid orders, and generated redirects are built from guessed slugs rather than the IDs the old URLs actually contain. We finish those parts ourselves. With database access nothing is limited to what an export screen offers: we read the tables directly, including every contribution’s additions, and reconcile each count against them.

How we run it

1. Audit. Which family member and version, PHP and MySQL versions, installed contributions, attribute structure, URL formats, integrations and database access. The result is a fixed-price scope.
2. Build in a free Shopify development store. As a Shopify Plus Partner we build in development stores, so you pay Shopify nothing until launch.
3. Catalog. Products, attributes redesigned for Shopify, collections, vendors, images, specials and SEO fields.
4. Customers. Every address book entry, newsletter consent and customer group.
5. Orders. Line items with attribute text, totals rebuilt from orders_total, status history, tracking and refunds, under original numbers and dates.
6. Redirects. Query-string URLs, SEO contribution URLs and information pages, keyed on IDs and tested one by one.
7. Sample, then full import. A sample of each entity for your sign-off, then the full run, reconciled against the source tables.
8. Cutover. DNS moves to Shopify, and a delta sync brings across orders and customers created since the full run.
9. Post-launch SEO evaluation. Once Google has re-crawled the store and the first real analytics exist, we review coverage, 404s, rankings and conversion, and fix what we find.

Cost and timeline

An osCommerce to Shopify migration starts from $2,500 for stores under 500 products and 5,000 orders ($3,500 for larger stores), and typically takes six to eight weeks for smaller stores. B2B setups, multi-store installs and integrations are quoted as a fixed price after the audit. Terms are 50% to begin and 50% once the store is live and you are fully satisfied with the figures.

The osCommerce family, member by member

osCommerce 2.2, 2.3, Phoenix and osCommerce 4

osCommerce 2.2 ran from its Milestone releases in 2003 to RC2a in 2008. Version 2.3 arrived in 2010 and closed security holes in 2.2. Phoenix began as a community Bootstrap edition of 2.3, split from osCommerce in 2021, and is still maintained at phoenixcart.org, with its installer accepting PHP 7.3 to 8.5; its schema remains recognizably 2.x, price prefixes included. osCommerce 4, launched in 2022 after Holbi acquired the project, is a rewrite on the Yii framework with many more tables, though it keeps the classic names such as products_attributes. We treat each as its own mapping, from the same starting point.

osCMax

osCMax 2.5 is osCommerce 2.2 RC2a with a large set of contributions pre-installed. The last package, 2.5.4, dates from around 2014 and was an unofficial release. Its core tables match 2.2, and the audit lists which extra tables the bundled contributions added, since those hold data a plain osCommerce mapping would miss.

Loaded Commerce, CRE Loaded and Loaded 7

CRE Loaded began as an osCommerce 2.2 derivative with B2B features and became Loaded Commerce. The 6.x line keeps the osCommerce table layout, and its Pro and B2B editions add tables of their own for customer groups and group pricing. Loaded 7 is a different generation: its tables use an lc_ prefix, with real variant tables and simple options, and its public repository says development has stopped. The company now sells a hosted cloud platform. We confirm which line you run before mapping anything, and group pricing becomes Shopify B2B catalogs.

TomatoCart

TomatoCart branched from the unreleased osCommerce 3 and uses toc_ tables with true variants, plus refund, return and store credit tables that stock osCommerce lacks. The last release, 1.1.8.6.1, came out in 2014. Its variants map to Shopify variants more directly than 2.x attributes do, and its refund records let us create real Shopify refunds.

Zen Cart

Zen Cart forked from osCommerce 2.2 in 2003 and remains a separate, maintained project. It has its own guide: see our Zen Cart to Shopify migration guide.

xt:Commerce, modified eCommerce and Gambio

These German platforms trace back to osCommerce 2.2 through xt:Commerce, and much of the schema logic here still applies to them. A dedicated guide is planned.

The shared schema and attribute price prefixes

Once we know a store is an osCommerce descendant, extraction is predictable. Products sit in products with names and descriptions per language, customers in customers with every saved address in address_book, and orders in orders with lines in orders_products, chosen attributes in orders_products_attributes, totals rows in orders_total and every status change in orders_status_history. Orders also store customer, billing and delivery addresses as text at the time of sale, so history survives even when a customer or product was later deleted.

Attributes are where the work is. Each row in products_attributes joins a product to an option and a value, with options_values_price and a price_prefix of plus or minus, so Large might add 5.00 and Economy might subtract 2.00 from the base price. Attributes are not variants: stock core has one stock figure per product, and stock by attribute came from contributions. Shopify allows three options and up to 2,048 variants per product. We sort each option: real product choices become variants with the prefix applied to each variant price; paid extras such as gift wrap become add-on products through an options app; text inputs become line item properties. A product with more than three real options is split, or an option moves to a metafield. Every calculated price is checked against the old store’s arithmetic before launch.

MD5-era passwords, card columns and PHP 5

osCommerce 2.2 stored passwords as an MD5 of a two-character salt plus the password, written as hash:salt. Version 2.3 moved to phpass and converted each old hash when that customer next logged in, so a 2.3 store usually holds both kinds; Phoenix adds PHP’s modern hashing. None of these can be loaded into Shopify, so customers set a new password or use passwordless sign-in. We tell you in advance how many accounts are affected so the launch email can explain it.

The 2.2 schema also includes cc_type, cc_owner, cc_number and cc_expires on orders, filled by the old manual card module where it was used. We check them, exclude them from the migration, and recommend purging them from the old database and its backups.

A store on PHP 5 is running a language version that has had no security fixes since 2018, often with an old MySQL and operating system beside it. That is not a reason to panic, but it is a reason not to wait: the fix is to move, not to patch. We plan the database copy early, work from that copy rather than the live server, and keep the old store read-only after cutover until you are ready to shut it down.

What you get at handover

A reconciliation ledger from the source tables to the live Shopify counts for products, variants, customers, orders and fulfillments, with every exclusion named; the redirect verification list with the status each URL returned; the attribute map showing how every option and price prefix was handled; the contribution inventory with the Shopify replacement for each; the password and card-column notes; and a recorded walkthrough of the Shopify admin for your team.

Questions we settle in the survey

• Which family member and version do you run, and on which PHP version?
• Can we get a database copy?
• Which SEO URL contribution is installed, and did the format ever change?
• Which attributes are real product choices and which are paid extras?
• Where are tracking numbers recorded today?
• Do you need live carrier rates at checkout? That needs Advanced or Plus, or Grow on annual billing.

Frequently asked questions

Start with the migration survey. For related platforms, see the Zen Cart guide and the OpenCart guide.