How do you approach risk assessment for Kentico 8–12 projects that are stable but considered legacy?

👉 How do you approach risk evaluation in such cases?

When I worked with clients who had outdated, legacy, or unsupported technology (like really old versions of Kentico), it was often difficult to communicate the risk when there were few examples of problems.

For example, if a client was using Kentico v6.0.0 in 2020, they were years out of support, but when their Kentico project ran well enough and didn't have bugs that impacted them beyond annoyance, the cost of an upgrade to the new version outweighed the incentive of new features and official support.

Clients who were in regulated industries, had initiatives to adopt new technology, or had their workflows regularly disrupted by bugs that couldn't be fixed were all interested in upgrading because the cost investment had a clear value.

I could say, "Your version of Kentico is unsupported and could experience unfixable security vulnerabilities", it only had an impact if:

1. They believed security vulnerabilities could realistically happen.
2. They believed security vulnerabilities were a risk to their business.

Some didn't believe 1. because they hadn't experienced a security issue before - survivor bias, I guess. Some didn't believe 2. because they couldn't imagine what types of things could happen if security was exploited.

👉 Do you have a structured way to decide between hardening and replatforming?

Typically, this was based on digital maturity. A client that bought Kentico in 2015 who, in 2020, believed updating web pages was "digital marketing" or "content marketing" was clearly not digitally mature. The often could not see the value in doing anything (hardening also cost time and money).

When they did make a decision there was a common result. They left us as an agency and adopted a simple, free, open-source CMS because their marketing team (or maybe the organization leadership) could not see the value of investing in their digital presence or valued shrinking costs and budget.

👉 What criteria make migration non-negotiable for you?

It was always a decision of the client. As their technology partner, we worked to give them the best information so they could make informed decisions. We didn't have non-negotiables because it wasn't our decision. We did use incentives, like cost to fix bugs or security issues, turnaround time, SLAs, etc... and often these incentives would drive decisions (but not always).

I'm concerned with this statement Milan:

...Kentico 8-12 projects that are stable but considered legacy.

Define "stable".

• Does stable mean that it's been running on a server for the last 3 years with no issues?

• Does stable mean that the content editor is making updates and they work without issue?

• Does stable mean you can make feature enhancements and push them to the server and everything works?

• Or does stable mean that your site is running the latest hotfixes, all 3rd party plugins/systems/modules are running their latest versions and you have no security holes that have been identified through rigirous testing?

• Stable could mean something totally different too.

Kentico versions 8-12 are not stable IMPHO. They may be running without issue on a server, but they aren't stable. There are security issues in those versions that have not been resolved and in 3rd party systems/plugins/modules used to run the CMS portion of the website. Not to mention the websites themselves are probably running some old versions of plugins/addons (i.e.: jQuery 2.2.4), running on old Windows Server versions, using old SQL Server versions, etc.

I know you asked very specific questions about how to provide this info to clients and what you proivide, but your main conversation points should be about the security and safety of your clients digital properties. These conversations typically have "ah-ha" moments for clients and they realize that they need to do something because being complacent isn't healthy for their business long term. Maybe something means they invest in replatforming. Maybe it means they migrate and invest in a license. Maybe it means something else...

Sean,

Your comment has a lot of "coulds" in it. Those should read "when". It is always a matter of when this will happen, not if or could it happen, especially when dealing with security, especially with the advancements in technology.

Sean,

Your comment has a lot of "coulds" in it. Those should read "when". It is always a matter of when this will happen, not if or could it happen, especially when dealing with security, especially with the advancements in technology.

After looking at my response again, I completely agree!

I think I would have phrased it differently if I were still working directly with clients today. My mind is very focused on the Xperience by Kentico world where continuous updates are standard and legacy technology is not an issue.

I also forgot about the Content Staging vulnerabilities in those old, unsupported versions of Kentico and how the agency I worked for had to put very robust firewalls in place and disable/block many Kentico features for those client that chose not to update. The clients we hosted didn't get hacked, but ones we did business with where they managed their own hosting did experience downtime and exploits from vulnerabilities.

I say chose not to update because they all had budgets, they just made decisions to spend that budget on other things.

Although not as thorough as the rest, I would assume outdated projects eventually could or will be 'hacked,' and the question is what would happen if it did? That, to me, is the security risk.

Do you have customer data that could be leaked? Possible hijacking of content or injection of malicious content? Those are things to consider.

Likewise, hosting capabilities, eventually certain hosting patterns will become harder and harder to do with older technologies.

I myself have some 'legacy' sites that are on a perpetual KX13 license, and I've already weighed out the pros and cons and for a lot of them they will just exist as is, not upgraded. One is my comic site (www.sonicandpals.com) which while it's built on Kentico 13, it actually is just a Single Page Application in react using a custom Entity SQL connection to the database and azure functions with only a couple api endpoints that are read-only, so no risk in my opinion on that.

The other is a personal tool i built but has no customer data and eventually will be rebuilt, but it just exists for now.

Brenden,

I think we are circling around the same word "stable" but meaning different things by it. Let me clarify, because I see two separate concepts here:

1. Stable website: I meant stable from the business owner and editor perspective. No outages, editors manage content without issues, the site serves the business needs. The client is satisfied.

1. Stable CMS: This is what you are talking about, and I fully agree with you. Kentico 8-12 is not stable from a security and platform perspective. Unpatched CVEs, outdated dependencies, end-of-support. All valid concerns. And yes, "could" should read "when." I agree with that too.

My post and my question are about what we can practically do for sites that are stable in sense #1 but running on a CMS that is not stable in sense #2. That gap between "the client sees no problem" and "we as professionals see real risk" is exactly the situation I am trying to address.

As Sean mentioned, it is common for low digital maturity clients to not see the business case for migration. And while we would all love to move them to Xperience by Kentico, the reality is that for a small brochure site with a few contact forms, there is often no reasonable license tier that fits their budget and needs. The technology is there, but the commercial path is not.

So what do we do in the meantime? Just tell them to migrate and walk away if they say no?

I have done some research on this. Based on the Wappalyzer database, I identified over 6,000 sites flagged as running on Kentico across all versions. After filtering I found out approximately 2,500 are still running Kentico 8-12. That includes around 50 government sites. These are not edge cases. This is a significant portion of the Kentico ecosystem that needs practical guidance.

What I found when I dug into the dependency chain is that the infrastructure underneath these sites is or potentially could be actually more durable than most people assume:

• .NET Framework 4.8 ships as a Windows component. Its lifecycle is tied to the OS, not to a standalone end-of-life date. It will be supported as long as Windows Server exists through Server 2025 that means at least until 2034.

• SQL Server 2025 is supported until 2036.

• TLS 1.2/1.3, browser rendering, and the web standards these sites output are not going away.

So the runtime is not the thing that kills these sites. What kills them is exposed attack surface on the application layer -- exactly what you are pointing out. The known CVEs, the staging service (CVE-2019-10068, CVE-2025-2746), publicly accessible admin endpoints, unused features left enabled.

But here is the thing: most of that attack surface can be systematically reduced without migrating. Based on my analysis, a typical brochure site on Kentico 8-12 that only uses content pages, media libraries, and basic contact forms (BizForms) has a very small attack surface if you:

1. Lock down /CMSPages/, /CMSModules/, /Admin/, and the staging service to VPN or known IPs only. This single step neutralizes the majority of known Kentico CVEs.
2. Apply the final hotfix for the version.
3. If the client does not use content staging, disable it in Kentico Settings and block /CMSPages/SyncServer.asmx at the IIS or firewall level. If the client does use staging, IP-restrict the SyncServer.asmx endpoint so only the known staging server can reach it. This neutralizes the public-facing CVE risk while preserving the workflow.
4. Disable unused features in Kentico Settings to reduce attack surface.
5. Put a WAF and CDN in front of the site (even Cloudflare free tier). A WAF with the OWASP Core Rule Set catches deserialization and injection patterns.
6. Upgrade the underlying infrastructure -- Windows Server 2022/2025, SQL Server 2022, .NET Framework 4.8.1.
7. Force HTTPS, set security headers, add CAPTCHA to forms.

The features that are genuinely dangerous on unsupported Kentico - e-commerce, public user accounts, marketing automation -- those are features you should migrate away from, no question. But a content-driven brochure site with forms and an IP-restricted admin? The attack surface after hardening is minimal.

I have built a decision framework around this that categorizes every Kentico feature by actual attack surface: what is safe to keep, what needs hardening, and what is a non-negotiable reason to migrate. Migration becomes non-negotiable when:

• The site handles PII under regulatory scrutiny (GDPR data processing, not just cookies)

• There is e-commerce or payment processing (PCI-DSS on unsupported software is not viable)

• Public user accounts exist (the authentication stack is too critical)

• A new critical CVE is discovered with no available patch and no compensating control

For the rest -- and that is the majority of those ~2,500 sites -- there is a responsible, structured way to extend their useful life while we wait for the client to see the business case for migration. Harden now, refresh the front-end to solve the problems the client actually cares about (design, performance, SEO), and plan to evaluate the platform when the next redesign cycle comes around in 4-5 years.

I am not arguing that these sites should stay on Kentico 8-12 forever. I am arguing that "migrate or accept the risk" is a false binary when there is a concrete third option: reduce the risk systematically and be ready when the client is ready.

Great response and detailed information Milan!

I agree, we never leave our clients in a position of "migrate or else", that's just not good business. Your 7 points of reducing your attack surface are 100% valid and pieces we plan for and implement initially. That third option of "reduce the risk systematically and be ready when the client is ready" isn't really something that we think about as an option because we do that up front.

I'm sure there are many Kentico clients that don't have this 3rd option done for whatever reason. I'd guess a very large percentage of those 2,500 that you identified are in that boat. For those people, I'd still stand by my comments about being and defining "stable". If we inherit a client where the "normal security fixes" have been applied (your 7 items above), it's typically one of the first things we provide as an initial review of the site. "Before we continue to these bugs/enhancements, we need to perform these 7 steps, and it will take XX time.". In most cases, when you sell them as a "major security fix" for a minor cost, it's a non-issue. Then it's not just

You are correct that there are two concepts; however, the second concept trumps the first concept simply on principle. We deal with the web day in and day out, right? The standard client (probably a marketing department person) does not. You can lower the surface area, but that's only good for X time. How we get the user to find value in that is up to how we present it to them. So this is where the rubber hits the road, correct? This is the question you're asking...

The answer is not 100% aparent mainly because of how it's sold to the client. Salespeople could call that tactic or strategy personal and may not want to disclose that in a public setting, as it may take their edge away from the competition. From my experience, as general as I can explain, you need to provide value, plain and simple. If there is no value, there is no need. Not just a rough idea, but actual values for actual concerns (yours and theirs), no matter what steps you've taken to reduce the risk already. It's only a matter of time before the steps you took to reduce risk are exploited and your site is under attack.

Providing some valid examples with factual data:

• Describe the different types of risks and attacks on web properties in general. Provide examples of sites, what happened, how they overcame, and what they identified as the underlying issue.
• Describe the different risks specific to Kentico and how they relate to the items above.
• Point out the steps, items, and activities they've already taken to reduce the risk. Celebrate the wins!
• A data breach can cost on average of $N,NNN,NNN.
• A ransomware attack can cause your site to be down for XX minutes/hours/days/weeks. How long can you afford to have your website down? Not from an e-commerce perspective, but from a brand perspective, before it starts negatively impacting your business.
• What is a DoS or DDoS attack and what can it do to their site/brand?

Now that they are aware of the facts, provide them with options. Options may be:

• stay the course and "deal with it" when it comes,
• migrate to the latest,
• move to another solution (have possible solutions with high-level information ready),
• find another vendor who will accept the risk if you're not willing to (be prepared to find one)
• and others people have that aren't obvious

Having been in the industry for over 22 years, with not nearly as much experience in sales as others, I'd say this really falls to the agency. How much are they willing to risk or deal with? Sometimes it's necessary to fire a client, sometimes not. Sometimes this is really what the client needs to move forward and grow, sometimes not. There's a lot to weigh, and it's not all based on technology.

We don't have a definite "migrate or don't migrate" practice/policy. We don't have a definite "harden or replatform" practice/policy. For us, we provide the facts, provide our recommendations, allow the client to review, and move from there. Relationships and trust are very important for both the agency and the client. No matter the outcome, we always ask ourselves how much we, as the agency, are willing to risk for our client.