SUGCON India 2026 — My Key Takeaways from Two Days in Delhi

 

Hello Sitecorian Community,

SUGCON (Sitecore User Group Conference) India 2026 just wrapped up in Delhi on June 4–5, and what an incredible two days it was!

If you couldn’t make it this year, or if you attended and want a structured recap of everything that happened — this post is for you. I’m going to walk through the biggest announcements, the sessions that stood out, and what I personally think you should be paying attention to as a Sitecore practitioner right now.

Let’s dive in. 🚀

🔷 The Big Announcement: Sitecore vNext

If there was one topic that had every room buzzing at SUGCON India 2026, it was Sitecore vNext.

The next major evolution of the Sitecore Platform DXP is officially on the horizon — and here’s what makes it genuinely exciting: it’s not the kind of “upgrade” that forces you to rewrite everything overnight.

What we know about vNext so far:

• Built on a modern .NET foundation, fully aligned with Microsoft’s long-term roadmap
• Uses the Strangler Fig pattern for gradual modernization — you adopt new capabilities at your own pace, alongside your existing implementation
• No forced migrations, no massive rewrites
• AI-powered authoring experiences built in from the start
• A refreshed Content Editor and Experience Editor experience
• Support for Windows Server 2025, SQL Server 2025, Solr 10, and .NET 10

🔥 What really got the room talking: The Strangler Fig approach means organisations can introduce vNext capabilities gradually — running them alongside what they already have, and transitioning components when the time is right for them. That’s a massive shift from the traditional “big bang” upgrade model Sitecore customers have been used to.

And the bridge to get there? Sitecore 10.5.

Sitecore 10.5 is the next stepping stone and it’s already delivering AI-powered authoring capabilities as a preview of what vNext will bring at scale.

✅ Three Things You Can Start Doing Right Now

1. Build clean separation between your Sitecore implementation and custom code — this is what makes the Strangler Fig approach actually work
2. Stay current — 10.4 and 10.5 are key modernization milestones, don’t fall behind
3. Invest in automation — DevOps pipelines, CI/CD, and regression testing will be your best friends during any gradual migration

🔷 AI Is Moving From Buzzword to Engineering Discipline

This was the theme that ran through almost every technical session at SUGCON India 2026: AI has moved out of the slide deck and into the codebase.

The conversations weren’t about whether to use AI. They were about how to engineer with it properly.

Two sessions stood out here in particular.

Building AI-Powered Migration Engines with MCP

The Model Context Protocol (MCP) is enabling a genuinely new class of developer tools. Sessions at SUGCON showed teams using MCP to build migration engines that dramatically cut the time and risk of moving content and configurations across Sitecore environments.

What used to be weeks of careful manual work is being transformed into guided, AI-assisted workflows. For anyone who has managed a large content migration on a Sitecore project — you’ll understand just how significant that is.

Building Hallucination-Safe AI Assistants

This was one of the most practically useful sessions of the conference.

Building AI assistants on top of a DXP is only valuable if those assistants can be trusted. Speakers walked through architectural patterns for:

• Grounding AI responses in verified, approved content sources
• Implementing guardrails that prevent out-of-scope or incorrect responses
• Designing systems that fail gracefully — rather than confidently generating wrong answers

⚠️ Key insight from this session: The shift isn’t just about adding AI to your implementation. It’s about treating AI as an engineering discipline with proper reliability, testing, and governance built in from day one.

🔷 XM Cloud and Headless: Maturing Faster Than You Might Think

For developers in the headless space, the XM Cloud and Next.js sessions offered some of the most immediately actionable content of the two days.

The state of headless Sitecore in mid-2026 is genuinely more mature than it was even 12 months ago. Sessions covered:

• Next.js performance optimization for Sitecore-powered sites — tackling real-world bottlenecks around rendering strategies, edge caching, and ISR/SSR tradeoffs
• Composable DXP architecture patterns that are proving out at scale in production environments
• Developer experience improvements in XM Cloud — local development tooling, component scaffolding, and how teams are structuring their headless codebases for maintainability

The clearest signal from these sessions: headless isn’t the “advanced” or “optional” approach anymore. It’s becoming the default, and the ecosystem tooling around it is catching up fast.

✅ Tip: If you’re still on a traditional Sitecore rendering model and haven’t started exploring a composable path yet, now is the time to start. The XM Cloud ecosystem is ready.

🔷 The Community: Still What Makes SUGCON Special

I’d be doing a disservice to the conference if I only talked about the technology.

What makes SUGCON India genuinely different from any other enterprise tech event is the people — and the culture of openness they’ve built together. Sitecore MVPs, architects, developers, and product leaders all in the same space, sharing knowledge freely, asking hard questions, and genuinely helping each other figure things out.

This edition had a particularly meaningful moment: a heartfelt farewell to Tamas Varga, whose energy and vision have shaped the SUGCON community for years. And a warm welcome to Sebastian Winter, stepping into his new leadership role — wishing him the very best as he continues building on that momentum.

A huge shoutout to the organizing committee who made this all happen in Delhi:

Sakshi Khurana, Sean Broderick, Rob Earlam, Hardeep Bhamra, Vikas Kumar, Yamini Punyavathi Muttevi, Raman Gupta — and every volunteer and sponsor who contributed behind the scenes.

And to the sponsors — Horizontal Digital, Altudo, Arroact Technologies, BIZTECHNOSYS, Codehouse, EPAM Systems, and Techxot — thank you for supporting the community.

🔷 My Personal Takeaways — What I’m Doing Differently Now

Here’s what I’m taking back to the desk and actually acting on:

On vNext and platform modernization: Start getting familiar with the Strangler Fig approach now — don’t wait for a migration to be forced. Understanding the pattern early means you can start shaping your current implementation to support it.

On AI: Move past experimentation. If you’re building anything with AI in the Sitecore space, invest in understanding MCP and hallucination-safe design patterns. The maturity bar for production AI implementations is rising quickly.

On headless and XM Cloud: If you haven’t started the composable journey yet, the ecosystem is ready for you. The tooling, patterns, and community knowledge are all there now.

On community: Show up. Whether at SUGCON, local Sitecore user groups, or online forums — the knowledge shared in this community is one of the most underrated resources in the Sitecore ecosystem, and it only works because people contribute to it.

Wrapping Up

SUGCON India 2026 was a reminder that the Sitecore ecosystem isn’t standing still. vNext signals a platform team that has listened carefully to years of community feedback and is building for the next decade — not defending the last one.

The combination of modern .NET foundations, AI woven thoughtfully into the platform, and a maturing headless ecosystem makes the next 12–18 months a genuinely exciting time to be working in this space.

I hope this recap was useful — whether you attended and want to consolidate your notes, or you couldn’t make it and wanted a proper rundown of what happened.

Stay tuned for more Sitecore articles, tips, and deep-dives right here on the blog.

Till then, Happy Sitecoring! 😊

Did you attend SUGCON India 2026? What was your biggest takeaway? Drop it in the comments below — I’d love to hear from you!

AI Personalization and Governance in SitecoreAI — What We Got Wrong First, and How We Fixed It

Hello Sitecorian Community,

If you have set up personalization on a SitecoreAI project, you’ve probably come across a situation like this a few months after go-live:

“Our personalization is configured. Decision models are deployed. But the analytics show variants are serving to only 4–5% of sessions. Everything else is hitting the fallback experience.”

And separately, when AI-generated content first goes into a governance review:

“If the AI produces something incorrect or off-brand — who is responsible for catching it, and what is the process for fixing it?”

Both of these come up on almost every enterprise SitecoreAI project. They look like different problems, but they have the same root cause: teams move to implementation before fully understanding how the underlying system works.

In this post I want to cover what we got wrong with personalization first, how we fixed it, and then walk through the governance setup that addresses the second question properly.

The Real Problem With Personalization Underperforming

The first thing worth clarifying — because there is a lot of confusion about this:

Sitecore Personalize decision models are primarily rules-based, not machine learning models that train automatically from your visitor traffic.

They are built on the DMN (Decision Model and Notation) standard. You define conditions, decision tables, and business logic on a visual canvas. Decision models should run in under 200ms — going beyond that risks impacting the visitor experience. This is a hard limit to design to, not a guideline. (Source: Fishtank practitioner implementation guide, confirmed by community implementations.)

Machine learning is available through optional Analytical Model components, but these connect to external propensity or forecast models that you supply via REST API. Sitecore does not auto-train models from your site’s visitor data. You bring the model; Sitecore Personalize calls it.

This matters because the most common mistake we see is teams building complex decision models and then assuming they need more traffic data before they work. In most cases, that is not the problem at all.

Why Variants Were Serving to Only 5% of Sessions

In our experience, low variant serving rates almost always trace back to one of three specific things:

• Conditions are too narrow. The decision rules don’t match enough real visitor profiles to fire. Teams write conditions based on ideal visitor segments, not how real visitors actually arrive on the site.
• Guest profiles are missing session event data. The conditions reference behavioral data — page views, interactions, past purchases — but that data was never captured because the Cloud SDK was not set up correctly from day one.
• The Cloud SDK initialised too late. Behavioral events from the visitor’s first interactions never reached CDP, so there was nothing for the decision model to work with.

⚠️ The step most teams skip: Sitecore’s own best practices documentation recommends running a decision discovery workshop before building anything — bringing together analysts, architects, marketers, and data leads to define the expected outcome, the required input data, and the decision logic. Most low personalization rates we have seen trace back directly to skipping this step and jumping straight to the canvas.

The Two Personalization Layers — Which One to Use When

There are two separate personalization mechanisms in SitecoreAI and it is important to be clear about what each one is for:

XM Cloud Built-inSitecore PersonalizeRule-based: geo, authentication state, device typeDMN decision models, optional external ML Analytical ModelsAvailable from day one — no additional product neededRequires Cloud SDK initialised correctly + CDP event data flowingWorks well for: simple launch-day conditionsWorks well for: complex behavioral targeting, multi-source decisioningNo discovery workshop required for basic setupDiscovery workshop recommended before building any decision model

The sequence that has worked well for us on multiple projects:

1. Run the decision discovery workshop with the full team — define the outcome, inputs, and decision logic before opening Sitecore Personalize
2. Launch with XM Cloud built-in rules for the simple conditions at go-live
3. Validate the Cloud SDK is initialised correctly and events are actually landing in CDP
4. Build Personalize decision models once you have confirmed the event data is clean, complete, and matching what your conditions expect

The Cloud SDK Initialisation Problem

This is the most common root cause we find when personalization is underperforming — and it is an invisible problem until you know to look for it.

If the Cloud SDK initialises after user interactions have already fired — which happens easily in React applications when component mount order is not carefully managed — the visitor’s earliest behavioral events never reach CDP. Those early events are often the highest-intent signals you have. Losing them means decision conditions based on page view counts, product category interests, or funnel stage simply never trigger.

The fix is straightforward. Initialise in the application root, before any component that fires events:

// ✅ Correct — in _app.tsx or the root layout
// Must run before any child component mounts
import { init } from '@sitecore/engage'
useEffect(() => {
  init({
    clientKey: process.env.NEXT_PUBLIC_CDP_CLIENT_KEY,
    targetURL: process.env.NEXT_PUBLIC_CDP_TARGET_URL,
    pointOfSale: process.env.NEXT_PUBLIC_CDP_POINT_OF_SALE,
    cookieDomain: window.location.hostname,
    cookieExpiryDays: 365,
  })
}, []) // Empty dependency array - runs once on mount

✅ Tip: Add a test that confirms the SDK initialises before the first behavioral event fires. We added this to our integration test suite after finding the problem on a live project. It has caught the issue twice since then in earlier environments before it reached production.

How We Approach Experiment Design

Personalization without measurement is decoration. Before any personalized variant goes live, we agree on these things in writing — not after the experiment has already been running for two weeks:

• A single clear hypothesis — for example, “showing industry-specific case studies to financial services visitors on the solutions page will increase demo request form submissions”
• One primary conversion metric tied to a real business outcome, not a proxy metric like time on page or scroll depth
• A minimum runtime before anyone looks at results — stopping an experiment after a few days because the early numbers look good gives you noise, not signal
• A statistical significance threshold agreed before launch — 95% is the standard; 90% is acceptable for lower-stakes tests where speed matters more

One more thing: do not run multiple experiments on the same page at the same time. When two experiments are running simultaneously, you cannot isolate which one caused any change in conversion. We learned this the hard way on a project where three experiments were live at once and the results were completely uninterpretable.

Why This Helped Our Team — Personalization

Before we understood these patterns:

• Variants served to 4–5% of sessions — default fallback almost everywhere
• CDP guest profiles had incomplete behavioral event data because SDK was initialising too late
• Decision models built without a discovery workshop were matching conditions almost nobody actually met
• Experiments ran without agreed hypotheses — results were disputed and inconclusive

After:

• Decision discovery workshop runs before any canvas work begins
• SDK initialisation test is part of the standard integration test suite
• Variant serving rates improved significantly once conditions matched real visitor profiles
• Experiments have written hypotheses, success metrics, and minimum runtimes agreed before launch

Now — Governance for AI-Generated Content

In a governance review on a recent project, the client’s risk team asked this:

“If the AI generates content that is factually incorrect, or that violates our brand guidelines, or our regulatory requirements — who catches it, and what is the process for fixing it before it reaches the public site?”

The system was working well technically. But there was no governance model to point to. That is a different problem and it needs to be solved before AI-generated content goes near production — not after a stakeholder raises it in a review.

1. Human Review Is Structural — Not a Nice to Have

Sitecore’s own platform design is explicit about this: AI agents generate and automate, but human review sits before any content reaches production. In every Agentic Studio Flow we build, every path that leads to a publish action has a Spaces review step between it and the publish trigger.

This is not about distrust of the AI output. It is about having a clear, auditable answer to the question: “who approved this content before it went live?” That answer needs to be a named person with a timestamp — not “the agent did it.”

❌ Without Human Review Gate

• AI generates → publishes directly
• No audit trail for what shipped
• No one to catch off-brand or incorrect output
• Governance review fails on first question

✅ With Spaces Review Step

• AI generates → goes to review board
• Author approves, edits, or rejects
• Approval record with name + timestamp
• Governance review has a real answer

2. Brand Guardrails Need Testing — Not Just Configuration

Sitecore Stream grounds AI generation in your brand guidelines document. This reduces off-brand output. But “reduces” is not the same as “prevents” — and in a regulated industry, that distinction matters.

What we do in practice:

• Define “on-brand” in explicit, testable terms — specific phrases to avoid, required tone characteristics, prohibited content categories — not just “upload the PDF”
• Build a validation test set of 20–30 prompts with known expected outputs, and known boundary cases that should produce a compliant refusal or flagged output
• Re-run this validation set after any brand guidelines update, and after any platform update that touches the Stream layer
• Log every AI generation with prompt, model version, and timestamp — this is the audit trail for compliance questions

⚠️ Common mistake: Teams upload the brand guidelines PDF once at setup and assume the guardrails are working. Brand guidelines change. Platform updates happen. Without a validation test set that runs regularly, you do not actually know what the guardrails are doing.

3. AI Configuration Should Be Environment-Specific

Dev, staging, and production should not use the same AI model, the same brand guidelines document version, or the same moderation settings. We treat all AI configuration the same way we treat database connection strings — stored as environment-specific variables, version-controlled, never hardcoded.

Config ItemDevStagingProductionAI modelLighter capacity — lower cost for iterationProduction parityFull capacityBrand guidelines docWorking draftClient-approved draftFinal approved versionModeration thresholdLenient — faster feedback loopMediumStrictHuman review gateOptionalRequiredRequired

4. CI/CD Pipeline — What Changes With SitecoreAI

The existing XM Cloud deployment pipeline carries over — Deploy App, Sitecore CLI, GitHub Actions all work the same way. What is new is that the pipeline may now need to handle agent and flow deployments from Agentic Studio and app deployments from App Studio. The DevOps tooling for Studio is still maturing through 2026, so expect some manual steps while that catches up.

Here is the pipeline sequence we use on SitecoreAI projects:

1. Unit tests — JSS components (Jest / React Testing Library)
2. Sitecore CLI sync — content serialization validation
3. Integration tests — webhooks, Management API (all workflow states)
4. Brand guardrail validation suite  ← automate this, do not skip it
5. Deploy to staging via Deploy App API
6. Smoke tests — page render, personalization variants, search results
7. Manual approval gate  ← required before any production deployment
8. Deploy to production via Deploy App API

✅ Step 4 is the one most teams skip in early sprints and then regret later. Automating the brand guardrail validation as part of CI means you find problems before they reach staging, not after a client review.

5. Questions to Have Answers for in Regulated Industries

If you are building for financial services, healthcare, or public sector clients, prepare clear answers to these before any pre-sales conversation or delivery kick-off:

• Data residency: SitecoreAI runs on Microsoft Azure. Sitecore Stream uses Azure OpenAI. Confirm which Azure regions are used for processing. Clients with strict data residency requirements will ask this in the first security review.
• Retention: Define a log retention policy for AI generation records before go-live. These are audit records, and regulated industries often have minimum retention requirements that vary by sector.
• Model transparency: Log the exact model version alongside every AI generation event. If a compliance issue surfaces six months after launch, you need to be able to show which model version produced that content on that date.
• Bias and fairness: Healthcare and public sector clients will ask whether AI-driven personalization treats different audience segments equitably. Plan periodic audits of personalization variant distribution across demographic segments into your operational monitoring — not just as a one-time launch check.

Why This Helped Our Team — Governance

Before we had a governance model in place:

• No audit trail for AI-generated content that had shipped to production
• Brand guardrails assumed to be working — no regular validation running
• AI configuration differences between environments were undocumented and inconsistent
• Data residency and retention questions in client reviews had no ready answers

After:

• Every piece of AI-generated content that reached production has an approval record — named reviewer, timestamp, and any edits made
• Brand guardrail validation runs as part of CI — problems are caught before staging, not in client reviews
• AI configuration is version-controlled alongside the rest of the codebase, with clear environment-specific settings
• Data residency, retention, and model transparency answers are prepared as standard artefacts in the project discovery phase

Final Thoughts

Personalization and governance are two areas where teams consistently invest less time upfront than they should — and then spend significantly more time fixing things after go-live than they would have spent getting the foundations right at the start.

For personalization: run the decision discovery workshop. Validate the Cloud SDK before any experiment goes live. Match conditions to real visitor profiles, not idealised ones.

For governance: set up the human review gate before the first AI agent touches production. Treat brand guardrails like tests — they need to run regularly, not just once at setup. And have the regulated industry questions answered before a client asks them in a review meeting, not during one.

That wraps up the Sitecore AI series. I hope these three posts have been useful — whether you are planning a new SitecoreAI project, mid-way through an XM Cloud migration, or trying to figure out why your personalization is not firing the way you expected.

Stay tuned for more Sitecore-related articles, tips, and tricks to enhance your Sitecore experience.

Till then, happy Sitecoring! 😊

Please leave your comments or share this article if it’s useful for you!