Sana 9.3 support, after Sana stopped.

Sana ended support for 9.3.0 through 9.3.4 at the close of 2024, and for 9.3.5 at the close of 2025. Both dates are behind us, and the extended-support arrangements that covered the gap have run out.

None of that switches anything off. No licence expires, no kill switch fires, and the store you had last week is the store you have today. Plenty of Sana 9 stores are still earning well and will keep earning for years.

What ended is the safety net behind the store: security patches, platform bug fixes, an escalation path, and the quiet compatibility work that kept a five-year-old ERP integration alive while browsers, payment providers and your ERP all moved underneath it.

Staying is a legitimate decision. It is only legitimate if somebody replaces that safety net. Running past end of life with nobody in the role is not really a decision, it is a bet that nothing will happen. You win that bet most months. The month you lose it, you lose it inside your order flow, with no vendor to call.

Most things reported as “a Sana problem” turn out not to be. They are the stack underneath, a customization, an ERP change, or something outside the building entirely. Separating those quickly is most of the job, and it is the part that is genuinely hard to do without having lived in the codebase.

When it really is the platform, the work runs in layers:

• Contain it where we control the traffic. Firewall rules, edge and reverse-proxy policy, headers, application configuration, and switching off surface you are not using. A surprising share of platform-level risk closes here without touching the application at all.
• Patch everything the platform sits on. On a typical 9.3 install that is the large majority of the exposed surface, and Microsoft still supports nearly all of it.
• Hear about it first. Monitoring advisories for the platform and its dependencies, so a problem reaches you from us rather than from a customer or an auditor.
• Tell you the real options. Including the cases where the honest answer is that deferring the move has become the expensive choice.

That last point is the one we would want to read if we were the ones buying. A maintenance provider whose commercial interest is in you never leaving has an obvious incentive not to raise it, and we would rather be the ones who say it early.

“We are on an unsupported platform” usually gets treated as one indivisible problem. It is not. A Sana 9.3 install is an ASP.NET MVC application on .NET Framework, served by IIS in classic pipeline mode, on Windows Server. Sana is one component in that stack. Microsoft still supports most of the rest.

In practice this is where we find the real, fixable risk on a neglected 9.3 store:

• .NET Framework version. Sana 9 installs commonly sit on .NET Framework 4.6.x, which Microsoft stopped supporting in April 2022. Moving to 4.8 is frequently straightforward, is still fully supported, and closes a genuine gap. It is also invisible until somebody audits you.
• The operating system. Windows Server 2012 R2 went out of support in October 2023. A meaningful number of long-running B2B stores are still on it.
• TLS and cipher configuration. Old protocol versions and cipher suites left enabled from a 2019 build, which fail modern scans and increasingly break payment integrations.
• Dependencies around the application. Libraries in your own customizations, which are yours to update and nobody has.

The useful reframing: an unmaintained Sana 9.3 store is not one unsupported thing. It is one unsupported component sitting on a stack that is often several years behind on patches nobody was blocked from applying. Closing that is most of the risk, and it is work that can start immediately.

The highest-leverage thing you can do for a store on a frozen platform is stop asking the application to defend itself. Put a modern edge in front of it and a large share of the threat model never reaches your code.

• Web application firewall. Managed rulesets that absorb the generic scanning and injection traffic every public store takes continuously, maintained by somebody else, sitting in front of an application that is no longer being updated.
• Bot and abuse control. Credential stuffing against B2B logins, scraping of customer-specific pricing, and checkout probing are the three that actually matter in B2B. All are cheap to mitigate at the edge and expensive to handle inside an older application.
• Rate limiting on the expensive paths. Search, price lookups, and anything that reaches through to the ERP. This protects the ERP at least as much as the storefront.
• Current TLS regardless of the origin. Terminating modern protocols and cipher suites at the edge means a security scan or a payment provider sees a current configuration even while the origin is being brought forward.
• Caching and availability. Serving static and semi-static content from the edge takes load off an origin you would rather not have to scale, and keeps something on screen during an origin incident.

None of this requires touching Sana. It is the cheapest meaningful security improvement available to a 9.3 store, and it is usually deliverable in days rather than months.

Buyers have no idea what version you are on. They know whether the site feels current, whether it works on their phone, and whether they can find the part they need. A store themed in 2019 usually loses on all three, and not one of those is a platform limitation.

This is our actual trade. Working inside Sana’s supported theming model rather than around it, a 9.3 store can still get:

• A visual refresh. Typography, spacing, colour and imagery brought up to date without changing a single business rule.
• Mobile that is genuinely usable. Many Sana 9 stores are technically responsive and practically painful on a phone, which matters more every year as buyers reorder from the warehouse floor rather than a desk.
• Faster pages. Image formats, payload discipline and caching usually produce a bigger measured gain than people expect from an older stack.
• Accessibility work. Semantic markup, contrast, keyboard navigation and labelling. This has become a procurement requirement in parts of B2B and is a common reason to be quietly disqualified without ever hearing why.
• Conversion fixes on the paths that earn. Search, product detail, reorder and checkout.

There is a strategic argument for doing this now rather than saving it for the rebuild: design and content work is precisely the part that carries over. Structure, requirements and a design system move to a new platform far more readily than code ever does.

Something shifted in the last couple of years that most B2B stores have not responded to. A real share of buyer research now happens inside an assistant rather than on a results page, and what makes a catalogue legible to an assistant is not what made it rank in 2019.

The useful part is that this is mostly a content and markup problem, which means a 9.3 store can be brought fully current without replatforming:

• Structured data across the catalogue. Product, offer, price, availability and identifiers rendered server-side. This feeds rich results and comparison engines, and increasingly it is what an assistant reads when deciding whether it can answer a question about your product at all.
• Product content that can actually be read. Specifications as real markup rather than an image of a table, so a crawler and a model can both parse them.
• Explicit machine-readable summaries. A plain statement of who you are, what you sell and who you sell to, in a form assistants consume directly.
• The technical basics that decay quietly. Canonicals, sitemaps and redirects that were right at launch and have drifted through years of catalogue changes, plus the crawl budget being spent on facet URLs nobody wants indexed.
• An AI crawler policy you actually chose. Deciding deliberately which assistants may read your catalogue, rather than leaving it to a default nobody set.

Being cited by an assistant depends far more on being clear and well structured than on domain authority, which makes it one of the few channels where a mid-sized distributor can beat a much larger competitor. It is also work that survives a replatform intact.

Not audited one. Not implemented one and moved on. We have operated a deeply customized Sana 9 store with real ERP integration, continuously, for years: through the platform escalations, the integration surprises, the performance work, and the ordinary Tuesday failures that never make it into a case study.

That matters here more than it does on a new build. Maintenance is a business of recognising things. Knowing that a particular symptom means the ERP changed a field length, or that a checkout failure is a payment provider rotating a requirement rather than your code breaking, is not something that can be read out of documentation.

ProjectThunder is a Sana-certified web agency rather than an ERP VAR. We have been building commerce since 2004. If you also have an ERP partner, we work alongside them rather than in place of them.

Nobody can quote maintenance on a store they have not looked at, and any provider who does is guessing at your customizations. We start by establishing four things:

1. Exactly which release you are on. 9.3.0 through 9.3.4 hit end of life a full year before 9.3.5, which changes how urgent this is.
2. What has been customized, and why. An inventory of add-ons, modules, view overrides and front-end work, including the business rules buried in them that nobody has written down.
3. The state of the stack. Operating system, .NET Framework version, IIS and TLS configuration, certificate handling, and how far behind each one is.
4. The health of the ERP integration. The six contracts the storefront depends on, and whether anything is already quietly failing and being worked around by a human.

That produces a written picture of what you actually have. Scope and terms follow from it. If the assessment says you need less than you expected, we will tell you that too.

Maintenance is not meant to keep you on 9.3 forever. It is meant to put the timing back in your hands, so a move to Sana Commerce Cloud happens on a schedule you chose and budgeted, rather than in a panic after an incident.

When that time comes, it is worth knowing what you are buying. Sana Commerce Cloud is a different product rather than version 10 of the one you have, and almost nothing transfers automatically. We have written that up in full, including what does carry over and where AI genuinely reduces the cost: Sana 9.3 is past end of life: what that means depends on who maintains it.

Maintaining the store properly in the meantime also protects the thing that matters most in an eventual rebuild. A maintained store keeps somebody fluent in your business rules. An abandoned one turns them back into archaeology.