Approaching frontend code in migration projects from older Kentico versions to Xperience by Kentico

What a great question!

Responding to your 1-3 above:

1. As you mention, this is the default approach when budgets are tight. I think it's also the default approach when you can't be confident that larger changes will be free of regressions! Undertaking a large refactoring without some kind of test protocol to define a correctly working solution seems very risky to me.

   Focus on the highest value - compliance, security, support, deployability. Only address old tech when you are required to work with it and you experience it causing regular regressions. Don't trade likely regressions (refactoring) for potential regressions (old tech).

   If the client is happy with the design/UX of a website, prioritize some (AI generated) E2E tests over underlying technology change. This will support you when you do make a tech upgrade later and it also leads to #2...

2. I used AI to refactor BEM + SCSS to a more modern approach of utility classes, CSS custom properties, and CSS that libraries like Alpine.js and HTMX can more easily work with. It went pretty well and agents/models have only improved since then.
   
   AI models have a lot of data to work with when it comes to jQuery and vanilla JS, so replacing those with something should be doable with AI agents. Start small and try inexpensive experiments. These experiments should only cost a few minutes of prompt and context engineering from a developer.

3. I love HTMX for web experiences that are primarily content with small additions of interactivity, but I also compliment it with Alpine.js. Both are used by the Kentico Community Portal and I wrote a post about why I think they are the right tools for Xperience by Kentico website channel experiences. The Q&A discussion about it also had good alternative perspectives.

In the past year I went through two such migrations where the frontend was built 7–8 years ago and hadn’t really been maintained since. For me, it definitely makes sense to update the frontend when you’re already modernizing the backend. It would seem odd to focus on getting to the latest Xperience by Kentico while leaving the frontend stuck on outdated and deprecated Node packages.

1. The goal is to move to current package versions, handle breaking changes, and replace deprecated tooling with modern alternatives. If rebuild is needed, then rebuild.
2. I’ve had good success renovating fairly complex frontends using AI agents: upgrading React class components to JSX, migrating legacy Sass setups to Dart Sass, removing jQuery in favor of vanilla JS and CSS, replacing deprecated libraries for things like carousels or lightboxes, or moving from Webpack to Vite.
3. If the site is relatively simple, I usually look for a lightweight and reliable library tailored to the specific use case. Other than that, especially when migrating away from jQuery, vanilla JS and CSS are often the best and most pragmatic choice.

I'll add my two cents because we are doing a rebuild of Physics Classroom as we continue migration.

One of the bigger time sinks (at least for me) is front end processes (React + Typescript + Css). Retooling these seems to be always a huge nightmare of npm package compatibility, changes in functionality, etc. So if budget is tight, and they aren't rebuilding everything, I would keep all those processes as is. Save re-tooling for when they do a rebuild of the site and design, when you can start fresh.

I would probably have less issues if I threw it at AI first in some cases, but in my case I really want to know and understand how each thing works which takes time, time I have, you don't.

Focus on the migration and migrating the systems. If any area of focus should be placed, it's looking at where you can better leverage the Content Hub as you move data over (sometimes manually) and updating the structure of data so the site source generates quickly and efficiently, and the Xperience users have a better time using the platform.

During my migration, I've written many custom migration scripts to take the old data and make sure it uses the Content Items field types, proper data structures, etc.

Great question and some fantastic answers already.

We’re seeing the same pattern on our side: clients are often happy with the current UX, but the tech stack (old jQuery, legacy bundling, outdated Node toolchains) becomes the real risk during migration.

What has worked well for us is a tiered approach:

• When budget and time are very tight, we keep the existing frontend and only fix what breaks with the move to Xperience by Kentico, plus harden things with some basic (AI‑assisted) E2E tests so we’re not afraid to touch it later.
• When there is at least some contingency, we treat the migration as a chance to modernize “from the inside out”: keep the visual design, but clean up the JS/CSS stack, remove jQuery where it’s clearly a bottleneck, and move to more current tooling.
  
  On the AI side, I’ve had good results using it in small, well‑scoped steps rather than as a “rewrite everything” button – for example: converting specific jQuery interactions to vanilla JS or HTMX, or refactoring older Sass setups. That keeps the risk manageable and still gives you real gains in maintainability.
  
  For sites that are mostly content with some filtering/pagination, I also agree React is often overkill. HTMX (sometimes with a light sprinkle of Alpine.js) has been a nice middle ground for us: you get modern, snappy interactions without introducing a full SPA layer on top of Xperience.