A shop on unmaintained cart software gets no security fixes and keeps the server on old PHP. List every customisation, plan a move to current software, and carry orders, accounts and product addresses across intact.

A shop nobody dares to update

The shop software went in around 2009. Over the following years a developer added to it: a size chart, a shipping rule, a gift option, a tweak to the checkout.

Each change was made by editing the cart's own files. When the cart's makers released a new version, installing it would have overwritten every one of them.

So nobody installed it, or the next one, or the one after that.

Six years later the shop still takes orders. That is the problem: nothing has failed yet, so nothing has been planned.

How customisation blocks updates

Well-made shop software keeps changes apart from its own code, in add-ons and theme files that updates leave alone.

Older carts made that harder, and plenty of developers edited the core files directly because it was quicker. An update replaces those files, so the changes vanish, or the update fails partway through and takes the checkout with it.

Each skipped update makes the next one bigger. After a few years, updating in place stops being realistic, and the only way forward is a move.

What an old cart costs

The second reaches beyond the shop. Software that cannot move to a newer PHP keeps everything else in the account on the old one too, including the blog and any other site sharing it.

Holding the server back

PHP is the language most shop software of that era was written in. Each new version drops old functions, and carts from around 2009 often rely on several that later versions removed.

PHP 5.3 has had no security fixes since last August. PHP 5.4 is down to security fixes only, until September, and the newest version is 5.6.

A host can keep an old version running for an account that needs it, but usually on an older server, and seldom indefinitely. When the host finally retires it, the shop finds out with very little notice.

List what was customised

Before choosing anything new, write down everything the old shop does that a plain copy of the software would not.

Ask the developer who made the changes, if they can be reached. Otherwise a developer can compare the shop's files with a clean copy of the same version, which shows every edit.

Then walk through an order as a customer and as staff: product options, shipping rules, taxes for each province, discount codes, gift certificates, order emails, reports, and any export to the accounting software.

Mark each item still used, replaced by a standard feature in current carts, or no longer needed. The third pile is usually bigger than expected.

Choosing what to move to

Current shop software, whether a newer generation of the same cart or a different platform, covers much of what used to need custom code: product options, shipping tables, tax by province and gift cards.

Match the list against what each option does out of the box and through add-ons that are actively maintained.

Whatever remains should be built as an add-on or in the theme, never by editing the core again. That one rule is what keeps the new shop updatable.

A worked example

A western boot store in a ranching town in the Interior sells work and riding boots over the counter and online, shipping across Canada.

Its cart was installed in 2009. A developer then edited the cart's own files to add a grid for size and width, a shipping rule for heavy parcels, an exchange request page and gift wrapping.

The developer moved away, and the shop never updated. Last fall the host warned that the account needed an old PHP version, on a server due to be retired.

A new developer listed every change. The size grid and shipping rule were essential, the exchange page duplicated a standard feature, and nobody had chosen gift wrapping in years.

The shop moved to current software, with the size grid rebuilt as product options. Orders and accounts came across, customers set new passwords, and every old product address was redirected.

Orders and customer accounts

Order history matters more than it looks. Staff need it for exchanges, warranty questions and repeat customers asking what size they bought last time.

Customer accounts carry names, addresses and order history. Passwords are another matter: old carts store them scrambled in formats newer software often cannot read, so plan an email asking customers to set a new one.

Bring across each customer's newsletter consent and the date it was given, not only the address. Under CASL, that record is what shows you may keep emailing them.

Gift certificate balances and store credit need checking line by line. A customer who loses a balance in a migration remembers it.

Product addresses

Old carts often gave products addresses built from a script name and a number, such as a product ID after a question mark.

Those addresses are in search results, in links from other sites and in customers' bookmarks. When the new shop goes live they lead nowhere unless each one is redirected.

Map every old product number to the new page for the same item, with a permanent redirect. Products no longer sold should point to the closest category, not the home page.

The counter-case

If the cart's makers still issue fixes for its current version and the changes were made as add-ons, updating in place may be all that is needed.

And a shop that sells little online may be better served by a smaller, simpler store than a copy of the old one. The list of customisations shows what still earns its keep.

For a shop that is years behind and customised in its core files, though, plan the move to current software before a host or a gateway sets the date.

The order to do it in

  1. Find out which version the shop runs.
  2. Ask the host which PHP version it needs.
  3. List every customisation and whether it is used.
  4. Choose current software that covers the list.
  5. Export orders and customers with consent dates.
  6. Redirect every old product address to its new page.
  7. Place real test orders before switching over.

Step three sets the cost of everything after it. A shop that knows which customisations still matter rebuilds only those; one that copies everything out of caution pays for features nobody uses.

The same trap on a content system is described in a site still running Joomla 1.5.

Frequently asked questions

Why can't my old shop just be updated?

Because changes were made by editing the cart's own files. An update replaces those files, so the changes disappear or the update fails partway through, sometimes taking the checkout with it.

What does an old cart do to the server?

It often needs an old PHP version, so the host cannot upgrade the account, and everything else in it stays on old PHP too. PHP 5.3 has had no security fixes since last August.

What should the list of customisations include?

Every change and what it does: shipping and tax rules, product options, discounts, gift certificates, reports and accounting exports, each marked as still used, replaceable or no longer needed.

Will customers keep their passwords?

Often not. Old carts store passwords scrambled in formats newer software may not read, so plan an email asking customers to set a new one when the shop moves.

What happens to old product addresses?

Each needs a permanent redirect to the new page for the same item, so links, bookmarks and search results still reach the right product. Discontinued items should point to their category.

Is moving to new software always necessary?

No. If the makers still issue fixes and changes were made as add-ons, updating in place may be enough. If not, plan the move before a host or gateway forces it.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Shop software untouched since 2009?

Tell us the shop's address. We will find what was customised and plan a move that keeps orders and accounts intact.

Start a Conversation