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

For Kentico 8–12 projects that are stable but considered legacy, I usually focus on risk-based prioritization rather than change avoidance. The first step is understanding what actually matters to the business—traffic, revenue impact, compliance, and security—so effort is spent where risk is real, not theoretical.

I start with a technical baseline review (Kentico version, hotfix level, custom modules, integrations, hosting, and database health), followed by a security and supportability check (end of support timelines, third-party dependencies, .NET compatibility). From there, I classify risks into operational, security, and future-change risks, and document clear mitigation options—patch, isolate, refactor, or accept.

For stable systems, the goal isn’t aggressive upgrades, but reducing surprise risk: keeping hotfixes current where possible, hardening security, documenting tribal knowledge, and defining clear triggers for when migration or modernization becomes necessary.

👉 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.