There's a peculiar moment that happens when you're knee-deep in Azure KeyVault certificate configurations at 3 PM on a Tuesday, managing authentication schemes for four separate websites running through a single ASP.NET Core application, when you realize: this is exactly the kind of complexity AI was built to help us navigate.

Modern enterprise CMS development isn't the "install WordPress and pick a theme" experience many imagine. Real-world platforms like Kentico Xperience power ecosystems—multiple brands, intricate authentication flows, Dynamics 365 integrations, WS-Federation SSO schemes that need perfect orchestration. The cognitive load is immense. You're not just building websites; you're architecting digital experiences that span organizational boundaries while maintaining security, performance, and developer sanity.

This is where AI tooling is fundamentally changing the game, not through flashy automation, but through something more subtle: context management at human scale.

Consider a scenario I encountered recently: troubleshooting a 500.30 error in a multi-site configuration while implementing Azure Identity Provider integration. Twenty years ago, this meant hours of documentation diving, Stack Overflow archaeology, and tribal knowledge phone calls. Ten years ago, it meant better documentation and more targeted searches. Today? AI-assisted development tools can hold the entire context—your authentication schemes, certificate deployment strategies, CQRS patterns with MediatR, Lucene search configurations—and help you reason through the problem space in natural language.

The transformation isn't that AI writes your code (though it can). It's that AI reduces the context-switching tax that makes complex architectures so mentally expensive.

When you're working with embedded Razor class libraries, managing four separate WS-Federation callbacks, coordinating Dynamics 365 marketing lists, and implementing sophisticated cache invalidation strategies—the traditional "figure it out" approach means holding an impossible amount of architectural knowledge in your head simultaneously. AI becomes a thought partner that remembers the details while you focus on the decisions.

But here's what genuinely intrigues me: platforms like Xperience by Kentico are themselves evolving to incorporate AI capabilities—content recommendations, personalization engines, intelligent search. We're approaching an inflection point where AI assists both the creation of the platform and the experience it delivers. The developer uses AI to navigate CQRS query handlers and cache dependency management, while the end user experiences AI-powered content discovery they never consciously notice.

The irony? The more sophisticated our CMS architectures become—multi-tenant, headless, composable—the more we need AI assistance just to maintain them effectively. We've built systems whose complexity exceeds comfortable human cognition. AI isn't replacing developers in this equation; it's making it possible for developers to keep building increasingly ambitious systems without drowning in their own technical debt.

Is this progress? Unquestionably. But it raises an interesting question: are we building complex systems because AI can help us manage them, or is AI emerging because our systems demanded it?

I suspect the answer is yes.

If you’ve ever worked with traditional CMS platforms or earlier versions of Kentico, you might expect a lengthy, click-heavy setup process. But with Xperience by Kentico, things have changed—dramatically.

Now, it takes just 3 simple .NET CLI commands to get a fully functioning MVC-based application up and running. Whether you’re a .NET Core developer trying XbK for the first time, or a seasoned Kentico dev exploring the new architecture, this streamlined process gets you building faster than ever.


1. Install the Project Templates

dotnet new install kentico.xperience.templates

This command installs the official Xperience by Kentico templates into your environment, allowing you to scaffold an entire solution with a single command.


2. Scaffold the MVC Project

dotnet new kentico-xperience-mvc -n NameOfProject

Replace NameOfProject with whatever you'd like your solution folder and project to be named. This command generates:

  • A ready-to-run ASP.NET Core 8 MVC site
  • Pre-configured XbK integration
  • Default routing, configuration, and content retrieval

No need to piece together startup logic or wire up services manually—Xperience takes care of that.


3. Configure the Database

dotnet kentico-xperience-dbmanager -- -s “ServerName” -d “DatabaseName -a “KenticoAdministrationPassword” --license-file “\location\of\license.txt”

This command:

  • Creates the database schema
  • Seeds initial data
  • Applies the license file
  • Sets up the CMS admin account

If your SQL Server is running locally, "ServerName" might be localhost or localhost\SQLEXPRESS.


Why This Matters

Xperience by Kentico was rebuilt from the ground up to embrace .NET Core fully. That means:

  • No more Web Forms
  • No more admin UI in the same project as your frontend
  • Clean separation of concerns
  • Real developer freedom

This new installation workflow reflects that philosophy: clean, quick, and powerful.


What's Next?

After installation, open your solution, run the application, and log into the Xperience Admin UI using the credentials you configured.

From there, you can start building:

  • Page types
  • Page templates
  • Widgets
  • Components
  • Content modeling strategies

All within a modern, headless-ready DXP that feels native to ASP.NET Core developers.

In my recent work with Kentico Xperience on a SaaS portal, I encountered a tricky issue that prevented the creation of new website channels. Despite numerous attempts to troubleshoot the problem myself, I could not get the admin console to load properly, and I kept receiving the message: “No website channel is running on this domain.”

 

After reaching out to Kentico support, their team dove into the issue. At first, they found no clear answers from the error logs. My local deployment was working perfectly fine, yet the SaaS environment failed to cooperate.

 

What made this issue even more puzzling was that my front-end website loaded without errors, but the admin console refused to display anything. This misalignment between the environments raised questions about middleware collisions or deeper system-level conflicts.

 

Kentico’s support team ran through an extensive debugging process. At one point, they even reviewed the entire source code, comparing it line by line. Finally, they identified the culprit: the order of middleware registrations in my Program.cs file.

 

In particular, there was a middleware conflict between app.UseKenticoCloud() and app.UseKentico(). The app.UseKentico() call was registered too early, which led to collisions that blocked the creation of new channels in the admin portal.

 

The fix was surprisingly simple but easily overlooked: changing the order of middleware registration. By moving the app.UseKentico() call to follow app.UseKenticoCloud(), I was able to resolve the issue. Kentico support also flagged a minor database inconsistency, advising me to ensure that the database is updated before deploying any new packages in the future.

 

After applying the recommended changes, I deployed a fresh package to the SaaS environment, and everything worked smoothly. This solution saved me a great deal of time and frustration, and I owe thanks to the Kentico support team for their thorough investigation and excellent communication throughout the process.

 

If you’re working with Kentico SaaS and run into mysterious issues, don’t forget to check your middleware registration order—it could save you some headaches!