B2B E-commerce

Sana 9.3 is past end of life. What that means depends on who maintains it.

The dates have passed and the vendor safety net is gone. Whether that is an emergency, a manageable running cost, or very nearly a non-event comes down to a single question: is anybody still looking after your store?

Published: August 20, 2026 · 12 min read

If we already maintain your Sana 9.3 store, this article is not about you.

You have a support path, your store is patched and watched, and your ERP integration is being kept working as the systems around it change. The end-of-life dates below describe what Sana stopped doing, not what stopped happening to your store. Nothing here is urgent for you, and when you do decide to move, you will do it on a schedule you chose rather than under duress.

The rest of this is written for the 9.3 owners who do not have that.

If you run a Sana 9.3 web store with nobody maintaining it, you are running unsupported software today. Not soon. Today. That is worth understanding calmly rather than urgently, because the honest answer to it is not automatically “rebuild now.”

The dates, plainly

  • Sana 9.3.0 through 9.3.4: end of life at the close of 2024.
  • Sana 9.3.5: end of life at the close of 2025.

Both dates are behind us. If you are on any 9.3 release as you read this, you are past end of life, and the extended-support arrangements that covered the gap have run out. See Sana’s end-of-life announcement for their wording.

What end of life actually removes

Being past end of life does not mean your store stops working on a Tuesday. Nothing switches off. No license expires. The store you had last week is the store you have today.

What disappears is the safety net behind it:

  • Security patches. Newly discovered vulnerabilities in the platform stay unpatched by the vendor, permanently.
  • Platform bug fixes. Defects in Sana’s own code are now yours to work around.
  • An escalation path. When something breaks in the platform rather than in your customizations, there is no longer a ticket you can file that ends in a fix.
  • Compatibility work. This is the one that catches people out, so it gets its own paragraph.

Your store is not static, even though your code is. Browsers change. Payment providers deprecate integrations and rotate requirements. TLS and certificate practice moves. Your ERP gets upgraded by a different team on a different schedule, and the contract between it and the storefront quietly shifts underneath you. On a supported platform, somebody else absorbs most of that. Past end of life, nobody does unless you arrange it.

That is the real content of the end-of-life date. Not a cliff, but the removal of the thing that was quietly keeping a five-year-old integration working while the world moved around it.

If you are staying on 9.3, somebody has to maintain it

This is the part most 9.3 owners have not priced, because for years it was included in the platform fee and therefore invisible.

Staying on 9.3 is a legitimate decision. For a store that works, that earns, and whose business has not changed shape, it can be the right one for a good while yet. B2B buyers are not clamouring for a redesign, and a replatform is a large amount of risk to take on for its own sake. We will say that plainly even though the other two options on this page are worth more to us.

But it is only a legitimate decision if you replace what the vendor used to do. That means a third party who actually knows the codebase and is on the hook for it, covering:

  • Security. Watching for issues in the platform and the stack under it, and patching or mitigating them, since Sana no longer will.
  • The ERP contract. Keeping customer lookup, pricing, stock, order placement, shipments and invoices working as SAP, Dynamics 365, Business Central or NAV change on their own schedule.
  • The moving world outside. Browsers, payment gateways, certificates, and the periodic surprise from a third party that assumed everyone had upgraded.
  • Fixing what breaks. Not escalating it. Fixing it, because there is nobody above you any more.
  • Knowing the system before it is an emergency. The difference between a maintained store and an unmaintained one is mostly measured on the worst day, and by then it is too late to start learning the codebase.

Running past end of life with nobody in that role is not a decision so much as a bet that nothing will happen. It is a bet you win most months. The month you lose it, you lose it during your order flow, with no vendor to call.

For what it is worth, this is work we do and have done for a long time. We have run a deeply customized Sana 9 store with real ERP integration continuously since 2020, through the platform escalations, the integration surprises and the performance work. That is also why the rest of this article is fairly blunt about what a move actually costs.

When you do move, know what you are buying

Whenever you decide the time is right, there is one expectation worth correcting first, because it is the single most expensive misunderstanding in this transition.

Sana Commerce Cloud’s initial release is documented as version 10. You are on 9.3. Every instinct a technology buyer has been trained with says 9.3 to 10 is an increment: a bigger upgrade than 9.2 to 9.3, but the same kind of thing.

It is not that kind of thing, and this is Sana’s own position, published in their support documentation under a page titled Why a New Sana Product, and Not a New Version?.

Sana Commerce Cloud is a decoupled architecture with a React front end, a new admin, and an entirely new content system built around a visual page builder. Sana 9.3 is ASP.NET MVC on .NET Framework, server-rendered Razor, running IIS in classic pipeline mode. Those two things share a product family and an ERP philosophy. They do not share code.

The practical consequence: a project scoped as an upgrade gets re-scoped as a replatform, usually about six weeks in, usually after the budget is set. Scoping it correctly on day one is most of the difference between a good version of this project and a bad one.

What actually transfers

Worth being blunt about, because the answer is close to nothing.

Does not transfer

  • Your theme and templates. Razor views and the 9.3 theming overlay have no path into a React front end. Every page template is rebuilt.
  • Your CMS content. Flexi pages were built in the old content model. Sana Commerce Cloud uses a new visual designer with a different page and block structure. Content is re-authored, not imported.
  • Your customizations. Custom add-ons, HTTP modules, view overrides, anything compiled against the 9.3 SDK: none of it loads. This is usually the biggest line item and the one most likely to be missing from the estimate, because customizations tend to be undocumented and their reasons live in people’s heads.
  • Front-end JavaScript and CSS coupled to the old DOM. Selectors that targeted the server-rendered markup have nothing to attach to.
  • Admin configuration. Settings are re-entered against a different admin with a different shape.

Does carry over

  • Your ERP. The system of record does not move. SAP, Business Central, NAV, F&O, whatever you run, stays where it is.
  • Your data. Customers, pricing, stock, orders and invoices live in the ERP, not the storefront. That is the single best structural property of a Sana implementation and it is why this is survivable at all.
  • Your integration contracts. Customer lookup, price lookup, stock lookup, order placement returning a real order number, shipment polling, invoice fetch. The connector changes underneath; the six things the storefront needs from the ERP do not.
  • Your requirements. Every business rule your back office actually depends on. This is the real asset, and it is the one nobody has written down.

The requirements are the asset, not the code

The uncomfortable finding from running a Sana 9 store for years is that the code was never the valuable part. The valuable part is the accumulated set of decisions: that the PO number is mandatory and capped at 25 characters because the ERP says so, that a whitespace-only PO must be rejected rather than silently accepted, that sub-accounts over an authorization ceiling route to a parent admin, that sample orders are a separate ERP document type rather than a discount, that add-to-cart must be disabled when the ERP holds no price for that customer rather than allowing an order that will fail downstream.

None of that is written down anywhere except in the behaviour of a codebase you would be throwing away. It is scattered across years of tickets, email threads, and fixes whose reasons were obvious at the time and are not obvious now.

If you rebuild from a fresh requirements-gathering exercise, you will rediscover a subset of these rules the hard way, in production, from the people whose orders break. Every replatform that goes badly goes badly here.

This is also the strongest argument for maintaining a 9.3 store properly even if you intend to leave it eventually. A maintained store keeps someone fluent in those rules. An abandoned one turns them back into archaeology.

Where AI genuinely helps, and where it does not

The rebuild is largely a translation problem, and translation across a known boundary is the thing current AI tooling is actually good at. Used with discipline it changes the economics of this project meaningfully. Used as a magic wand it produces confident nonsense.

Where it helps

  • Extracting requirements from the old codebase. Reading every customization, every view override, every ticket in the project history, and producing a structured as-built record of what the store actually does and why. This is the highest-value application by a distance, because it converts the asset you would otherwise destroy into one you keep. It is also tedious enough at human speed that it usually does not happen.
  • Translating templates. Razor view to React component is a mechanical transformation with a consistent shape. AI is good at consistent shapes at volume.
  • Re-authoring content. Mapping old Flexi page structures onto new page-builder blocks, at the scale of a few hundred pages, is exactly the kind of work that is too big to hand-do and too structured to justify a bespoke tool.
  • Generating the regression tests you never had. The old store is a working specification of its own behaviour right up until you turn it off. Characterizing that behaviour as tests, while it is still running, gives you something to check the new build against.

Where it does not

  • Deciding which rules to keep. Some of what your 9.3 store does is a deliberate business rule. Some is a workaround for a platform limitation that no longer exists, and some is a bug everyone has quietly adapted to. Telling those apart requires talking to the people who run the business. No model knows which is which.
  • ERP semantics. The connector is different. Field lengths, document types, and error behaviour need re-verifying against the new integration rather than assumed to carry.
  • Anything you do not verify. A generated component that renders is not a component that is correct. The review burden is real and it does not go away.

The honest framing: AI does not remove the rebuild. It removes most of the archaeology, most of the mechanical translation, and the excuse for not having the requirements written down. That is a large fraction of the cost and nearly all of the risk.

A sequence that works

When you do decide to move:

  1. Capture the as-built first, while 9.3 is still running. Before any new-platform work. If you do only one thing on this list, do this one, because the window closes when the old store goes dark.
  2. Inventory the customizations and classify each one. Keep, drop, or replace with a platform-native feature. A meaningful share of 9.3 customizations exist to work around gaps that Sana Commerce Cloud closes natively, and rebuilding those is pure waste.
  3. Confirm the six ERP contracts against the new connector before committing to a front-end plan. Integration surprises are schedule-killers.
  4. Rebuild the front end, highest-traffic template first. Category and product pages earn the most and expose the most rendering problems.
  5. Run both in parallel with a real dealer group on the new store before cutover. B2B buyers are unusually intolerant of surprise, and a pilot group catches the rules nobody documented.

What to do before you call anyone

Two things, both free, both useful even if you never hire a soul:

  1. Find out exactly which 9.3 release you are on, and who is maintaining it. 9.3.0 through 9.3.4 hit end of life a year before 9.3.5 did. Both questions change how urgent this is, and the second one changes it more than the first.
  2. Write down every business rule your back office would notice if it disappeared. Sit with the person who handles order exceptions and ask what the site does that they rely on. You will get a list nobody expected. That list is the actual specification for whatever comes next, and it is worth more than any proposal you will receive.

The takeaway

There are three honest paths off the end-of-life date, and they are not ranked by what they are worth to a supplier.

  1. Stay on 9.3, properly maintained. Viable for years. It requires a third party who knows the codebase and carries the security, the ERP contract and the fixes that Sana no longer will. This is the cheapest option and, for a lot of stores, the correct one right now.
  2. Move to Sana Commerce Cloud. A better platform than 9.3 on nearly every axis that matters, and where the product line is going. Just budget it as a rebuild wearing a version number, because that is what it is.
  3. Look further afield. If the business has changed shape since you bought Sana, the ERP-integrated model may no longer be the right frame at all. That is a conversation worth having rather than avoiding, and we would rather have it with you honestly than watch you rebuild the wrong thing carefully.

The path that goes wrong is the fourth one, the one nobody chooses on purpose: staying on 9.3 with nobody maintaining it, and calling that a decision.

Have a real project this article touches?

We have run a Sana 9 store with deep ERP integration continuously since 2020, including the customizations, the platform escalations and the performance work. Whether you want your current 9.3 store looked after properly, a straight read on what a move to Sana Commerce Cloud would actually cost, or a wider conversation about whether Sana is still the right fit, tell us what you are running. No obligation, and we will tell you if the answer is that you should stay where you are for now.