What happens to your storefront when SmartStore 1.0 retires?

CAI Software has set 31 December 2026 as the end of support for SmartStore 1.0 in MarketDirect StoreFront. After that date your SmartStore 1.0 storefronts are expected to keep running, but they will be unsupported. There is no announced mechanism that switches them off. The practical deadline is not the storefronts breaking, it is that you stop being able to get help when something goes wrong with them.

If you run MDSF and you are not certain whether you still have SmartStore 1.0 storefronts active, that is the first thing to check. Many print shops have legacy stores sitting in their admin panel that nobody has looked at in years.

What SmartStore 1.0 and 2.0 actually are

They are not separate products and you do not buy them separately. They are the two generations of the storefront framework inside MarketDirect StoreFront. SmartStore 1.0 arrived in MDSF version 7.0. SmartStore 2.0 is the current builder, with a different editing model, responsive layouts and a different approach to customisation.

A note on the name, because it causes confusion. SmartStore here refers to the storefront framework inside MarketDirect StoreFront. It is not related to Smartstore.NET, the open-source ASP.NET ecommerce platform, which is a completely separate product from a different company. If you are searching for help with SmartStore 1.0 and getting results about ASP.NET Core upgrades and Cart2Cart migrations, that is why.

The product is currently owned by CAI Software, formerly Graphic Communications. You will still see eProductivity Software and ePS in older documentation, in reseller material, and in the copyright line at the bottom of live MDSF instances. Same product, different owners over time.

Do SmartStore 1.0 storefronts stop working on 1 January 2027?

Based on what has been announced, no. They lose support, not function.

CAI's release notes say SmartStore 1.0 is planned to be deprecated by 31 December 2026 and strongly recommend migrating, because 1.0 storefronts will no longer be supported. Deprecated and switched off are different things, and nothing published so far indicates a forced cutover.

In practice there are a lot of MDSF customers still running SmartStore 1.0, and a hard switch-off would break a large number of live storefronts at once. That makes a sudden cutover unlikely. It does not make it impossible, and running an unsupported storefront framework through 2027 and beyond carries its own risk: no fixes, no help when a browser update changes how your pages render, and no support path when something does go wrong.

What migrates cleanly and what does not

CAI states that most items migrate directly. That is accurate, and the list is the part of your storefront that holds the data:

  • Products

  • Categories

  • Users

  • Permissions

What does not come across is the part that makes your storefront look and behave like yours:

  • Any custom CSS or JavaScript. All of it needs reworking for the new framework. If a developer built your storefront's look with custom code, that work does not transfer.

  • Analytics implemented inside storefront pages. GA4 and Google Tag Manager containers that were injected into SmartStore 1.0 pages need to be reimplemented.

  • Banner and image assets, if you care about them being right. SmartStore 2.0 uses different dimensions. The images will carry across, but they will be the wrong size for the new layouts. Anything you want sitting at the correct size needs to be resized or regenerated.

The short version: your data moves, your customisations do not.

How long does it actually take?

CAI says basic design elements can be created in about three minutes with the SmartStore 2.0 builder. That is not marketing exaggeration, the builder genuinely is quick.

For a storefront with no customisation, budget around 30 minutes. For a straightforward storefront that needs a bit of care, around an hour.

The number that matters is not per storefront, it is per storefront multiplied by how many you have. A shop with three storefronts is looking at an afternoon. A shop with forty corporate portals is looking at a week of solid work, before any customisation rework.

What drives the time up

Customisation, almost entirely. It is the only variable that matters.

A storefront with no custom code is a rebuild in the builder and you are done. A storefront where a developer wrote custom CSS and JavaScript to control layout, branding and behaviour is a different job, because that work has to be redone against a different framework rather than copied across.

If you do not know how much custom code is sitting in your storefronts, that is worth finding out before you plan the work, not during it.

What it costs

A simple storefront is roughly an hour of work. Multiply that by how many storefronts you have, and add time for the ones carrying custom code.

Our ad-hoc rate is $200 AUD per hour plus GST (GST free offshore). Most migration clients pay less than that, because a batch of storefronts is better bought as discounted prepaid blocks or under a retainer arrangement.

We scope the full set and quote it up front, so you get a total rather than an open meter.

The real risk is the calendar, not the software

This is the part worth planning around.

The migration itself is not difficult. The risk is leaving it until late 2026, when you are in peak production and cannot afford storefront downtime or a distracted operations team. A migration that takes an afternoon in August is the same migration in November, except in November it is competing with your busiest weeks of the year.

There is also a second-order effect. If a large share of MDSF customers leave this to the last quarter, vendor support and independent help both get scarce at exactly the moment everyone needs them.

What to do now

  1. Log into your MDSF admin panel and audit your storefronts. Identify which ones are still on SmartStore 1.0. Include the ones nobody has touched in years.

  2. Work out which of them are actually still in use. Some legacy stores can simply be retired rather than migrated, which is the cheapest possible outcome.

  3. Check each remaining storefront for custom code. This is what determines your real effort.

  4. Note where your analytics are implemented. If GA4 or GTM sit inside storefront pages, they need to be part of the plan.

  5. Schedule the work outside your peak season. This is the single highest-value decision on the list.

If you are not sure where to look in your admin panel, get in touch and we will show you.