XM Cloud Migration and API Patterns — Real Challenges We Faced and How We Fixed Them

Hello Sitecorian Community,

If you’ve been involved in an XM Cloud migration, you’ve probably come across something like this:

“We are three weeks into the migration sprint. Architecture is signed off. Then we discover that most of the existing MVC components won’t work in headless SXA. The estimate needs to change significantly.”

This happens on projects regularly — not because teams are careless, but because most migration guides cover what to do at a high level without going into the specific things that cause problems mid-sprint.

⚠️ Deprecation Timeline — Act on These Now

Before we get into migration challenges, here are the live deadlines affecting every SitecoreAI project right now:

The Real Problem With XM Cloud Migrations

Migrating from Sitecore 10 MVC to XM Cloud is not an upgrade. It is a full re-platforming to a headless, SaaS-based architecture.

Challenge 1 — Every MVC Rendering Needs to Be Rebuilt

This is consistently the largest effort in any XM Cloud migration. There is no conversion path from MVC to Content SDK. Every rendering needs to become a component, and all layouts need to be rebuilt inside the Headless SXA information architecture:

• Tenant → Site → Pages
• Page Designs and Partial Designs replace the old layout system
• All rendering logic moves to the frontend (Content SDK 2.x)
• Custom placeholder nesting does not map cleanly — redesign component by component

⚠️ If your existing solution is not SXA-based: adopting Headless SXA is an additional workload on top of the component rebuild. Budget and scope it separately — it is the most commonly missed item in early estimates. Source: Sitecore Accelerate Cookbook.

Challenge 2 — Personalization Must Be Redesigned, Not Migrated

❌ What doesn’t work

• Porting XP rules to XM Cloud directly
• Expecting xDB segments to carry over
• Treating personalization as a later sprint

✅ What we do instead

• Audit every existing personalization rule
• Identify the business intent behind each rule
• XM Cloud built-in rules for geo, auth, device
• Sitecore Personalize for behavioral targeting

This conversation needs to happen in discovery — not once the migration sprint has started.

Challenge 3 — Bad Content Migrates Perfectly

The tooling handles the mechanical side. What it cannot fix is content that was already messy. Common issues we find after migration:

• Items losing workflow state or associations
• Media references breaking because folder casing changed
• Personalize dependencies embedded in content items that need decoupling first
• Old placeholder configurations no longer matching any component definition
• Inconsistent templates multiplying into template sprawl

✅ What helped us: Run a content audit before any migration script runs. Agree a content freeze window — no new content authored during the audit and initial pass. It sounds disruptive but saves weeks of cleanup.

Challenge 4 — The JSS → Content SDK Migration (Critical)

If you are starting any new XM Cloud or SitecoreAI project today, use Content SDK 2.x. If you have existing JSS implementations, the migration path is documented and there is now a direct JSS 22.0 → Content SDK 2.1 upgrade guide that eliminates the need to step through intermediate versions.

Content SDK 2.x — create a new project (official command)

# Option 1: Content SDK CLI (minimal scaffold)
# Source: doc.sitecore.com/sai/en/developers/content-sdk/20/create-a-content-sdk-app-locally.html
npx create-content-sdk-app@latest nextjs
# Option 2: Official XM Cloud starter repository (recommended for real projects)
git clone https://github.com/Sitecore/xmcloud-starter-js.git
# Use basic-nextjs for a clean start:
cd xmcloud-starter-js/examples/basic-nextjs
npm install
# Or use the skate-park example to see components out of the box:
cd xmcloud-starter-js/examples/kit-nextjs-skate-park
npm install

✅ Key benefit: Content SDK 2.0 delivers up to 49% lighter client-side bundles and an 89% smaller application footprint vs the JSS starter kit. Pages load faster and Core Web Vitals improve directly. Source: sitecore.com/solutions/topics/content-management/from-jss-to-content-sdk

About SitecoreAI Pathway

Pathway is Sitecore’s AI-assisted migration tool. Verified facts as of September 2026:

• Content and schema migration only — not code. Rendering rebuild is a separate effort
• Up to 70% reduction in migration effort — covers both time savings and steps Pathway can automate. Around 100,000 pages migrated in beta
• Included in Sitecore 360 subscriptions at no extra cost
• Pathway v1.3 (April 28, 2026): “Any website” migration available in beta — migrate public HTML sites (non-Sitecore sources) through the same flow as Sitecore XM. Scope, language, media, and discovery behaviour limited in this beta. Source: Sitecore Developer Portal changelog, April 28, 2026
• Pathway v1.4 (July 2, 2026): image migration added for “any website” sources, multi-language migration for XM/XP sources, automatic export structure creation, improved crawl reliability. Source: Sitecore Developer Portal changelog, July 2, 2026
• Named platform support (Adobe AEM, Optimizely, Contentful): announced as roadmap intent at Symposium 2025. As of v1.4, the “any website” capability covers public HTML sources — not deep platform-specific integrations. Watch the official Sitecore Developer Portal changelog for named platform support announcements.
• AI + human-in-the-loop — Pathway flags items needing review, keeps a full audit trail, lets you test with sample data before going live

⚠️ Known limitations (verified from official Pathway docs): No support for complex controls or data sources with child items. One site at a time — repeat per site and language. Target site structure and templates must exist in SitecoreAI before Pathway runs. Workflow states, personalization rules, analytics data, and custom modules are NOT migrated. Source: sitecore.com/resources/insights/artificial-intelligence/move-to-sitecoreai-with-pathway

API Integration — Patterns That Break in Production

“The integration worked perfectly in dev. It worked in UAT. On go-live day, under real traffic, it started timing out. Logs pointed to Experience Edge being hammered.”

API failures on Sitecore projects are rarely about writing the wrong code. They are almost always about misunderstanding how Experience Edge delivers content.

How Experience Edge Actually Works

Critical: Experience Edge serves a static snapshot of Layout Service output produced at publish time. Custom Content Resolvers do NOT execute at request time — they run at publish. If your resolver needs runtime context (visitor session, query string, live API data) — redesign it. That logic belongs in the frontend or a separate API call.

Content not appearing on the live site? Debug the publish-to-Edge pipeline first. Set up infra-level alerting on Edge publish failures — a silent failure during a busy editorial period is one of the most common causes of stale content on a live site.

Caching Strategy by Data Source

The Webhook Write-Back Silent Failure

Common pattern: webhook fires → Azure Function calls AI → result writes back via the Management API. Works in testing. Fails silently in production when the item is in an approved or published workflow state and the API token lacks override permissions.

Webhook write-back — test matrix (must cover all states)

# Validate write-back against EVERY workflow state
#
# Draft                → write allowed ✅
# Awaiting review      → depends on token permissions ⚠️
# Approved             → fails silently without override ⚠️
# Published            → fails silently without override ⚠️
# Fix: ensure your API token has WorkflowState override
# Test this in your integration test suite - not just happy-path Draft

Agent API — Migrate to v2.0 Now

If your implementation uses the Agent REST API directly, v1.0 personalization endpoints were deprecated on August 4, 2026. The brief generation endpoint was deprecated on September 20, 2026. Migrate to v2.0 endpoints. Source: Sitecore Developer Portal, May 18 2026 changelog.

Agent API — v1.0 → v2.0 migration

# DEPRECATED — remove before Aug 4 deadline
GET  /api/v1/personalization/by-page/{pageId}
POST /api/v1/personalization/{pageId}/versions
# USE INSTEAD
POST /api/v2/personalization/{pageId}/versions   # create variant
GET  /api/v2/personalization/{pageId}/versions   # list variants
# DEPRECATED - brief generation (removed Sep 20 2026)
POST /api/v1/briefs/generate
# USE INSTEAD - check Sitecore Developer Portal for new endpoint

Why This Helped Our Team

Before

• Debugging in the wrong place on go-live day
• Multi-source pages unreliable under load
• Webhook write-backs failing silently
• Building custom integrations Connect could handle

After

• Infra-level Edge publish alerts in place
• Each data source has a matching cache strategy
• All workflow states covered in integration tests
• Connect checked first before any custom code

Final Thoughts

Two things that tell you more about migration scope than any architecture review: run a full rendering inventory, and run a content quality audit before sprint one. If your team or client is still on JSS for SitecoreAI — that is now EOL. Content SDK 2.x is the only supported path. If anyone is still on Explorer — it is already gone. And Experience Editor has a hard deadline of January 1, 2027.

Stay tuned for more Sitecore-related articles, tips, and tricks to enhance your Sitecore experience.
Till then, happy Sitecoring! 😊

SitecoreAI and Sitecore Studio — What Actually Changed and What We Can Build Now

Hello Sitecorian Community,

If you’ve been working on Sitecore projects over the last few years, you’ve probably hit this situation at some point:

“We have XM Cloud for content, CDP for customer data, Personalize for targeting, and Content Hub for assets — but our team spends half the day switching between four different portals.”

And honestly, that was the reality. Different logins. Different APIs. Different billing conversations. Developers writing glue code between products that were supposed to talk to each other.

At Sitecore Symposium 2025 (November 3–5, Walt Disney World Dolphin Resort, Orlando), Sitecore announced SitecoreAI — and on November 10, 2025, every XM Cloud tenant was automatically upgraded. No migration. No new contract required.

What Is SitecoreAI, Really?

The simplest description:

SitecoreAI = XM Cloud + CDP + Personalize + Search + DAM — unified into one platform, one login, one data model, with AI built into every layer.

Sitecore calls this going from “composable” to “composed.” Sitecore COO Dave Tilbury on stage at Symposium: “no addons, no upsells, no tokens, no games.” Buy one module, get production-scale access to the entire suite. (Source: Velir Symposium 2025 recap, sitecore.com/platform/ai-and-agents)

❌ Before (XM Cloud era)

• 4 separate portals, 4 logins
• Token-based AI billing surprises
• Separate contracts per product
• Sitecore Stream = separate add-on
• “You can’t customise SaaS”

✅ After (SitecoreAI)

• One unified workspace, one login
• No tokens, no upsells — one metric
• Buy one, access the full suite
• Brand-aware AI copilot baked in
• Sitecore Studio — governed extensibility

What Stays the Same for Developers

Most important for teams mid-project: your toolchain is unchanged.

• Your Sitecore CLI and serialization workflows carry over
• The Deploy App pipeline works exactly the same
• All existing SDK integrations continue without breaking changes

⚠️ Content SDK update (September 2026): JSS 22.x reached end of life in June 2026. JSS 23.x does not support SitecoreAI. The Content SDK 2.x is now the only supported path for SitecoreAI development. Content SDK 2.0 requires Next.js 16 minimum and delivers up to 49% lighter client bundles and 89% smaller application footprint versus JSS starter kits. If you are still on JSS for SitecoreAI, migrate now. Source: developers.sitecore.com/learn/getting-started/sitecoreai/content-sdk

✅ Content Hub update (September 2026): The native SitecoreAI DAM launched February 2026 and full-page editing in Content Hub went GA June 2026. The “phased integration” framing is now outdated — both products share the same unified platform environment. Check the Sitecore Developer Portal changelog for updated integration patterns.

Platform Architecture — SitecoreAI at a Glance

Sitecore Studio — The Four Parts

• Agentic Studio — build and run AI agents and multi-step flows. 20+ pre-built agents included out of the box
• App Studio — build and package custom extensions and apps (the new Helix for SaaS)
• Sitecore Connect — pre-built connectors: Salesforce, OpenAI, Gemini, and more
• Marketplace — discover and publish community-built agents and apps

Agentic Studio — Four Concepts Before You Build

🤖 Agents — one helper, one job
An agent has one clear, narrow purpose — “generate SEO metadata for a content item”. Keep scope tight. One agent = one job = consistent, predictable output. Sitecore ships 20+ pre-built agents (Content Generator, Blog Writer, Translation Assistant, Bulk Content Generator, Account Data Enricher, and more).

🔗 Flows — chain agents into a workflow
A visual canvas to chain multiple agents step by step. Example: Generate → Human review in Spaces → Publish. This is where single agents become business automation. Always include a review step before any publish action.

🗂 Spaces — shared review board
The team workspace where AI-generated output lands for human review before going anywhere. When a stakeholder asks “who approved that AI-written content?” — the answer is in Spaces: named reviewer, timestamp, edits made.

⚡ Signals — event-based triggers
Signals fire a flow automatically when a condition is met. Example: content performance drops below a threshold → fire the optimization flow. This is where reactive automation lives without custom polling scripts.

A Real Example: Bulk SEO Metadata — 600 Pages, Monday Deadline

A client had 600 product pages needing SEO titles, descriptions, and keywords before a Monday go-live. Previously: custom PowerShell, manual effort, a Saturday. With Agentic Studio:

Agentic Studio — flow structure

Bulk content trigger (content tree query)
   ↓
[Agent: Generate SEO Metadata + brand RAG context]
   ↓
[Spaces: Author Review Board]  ← Human approval required
   ↓  (on approval)
[Publish to Experience Edge]

600 pages queue through the agent overnight. Monday morning: authors open Spaces, approve or edit, publish. The weekend is saved.

App Studio — The Developer Extensibility Layer

App Studio is where developers build underlying extensions — custom connectors, UI plugins, packaged apps. Think of it as the modern replacement for custom pipelines and processor chains, deployed as versioned, shareable, Marketplace-distributable apps. For Helix veterans: same bounded module discipline, SaaS-native deployment instead of server-side.

Why This Matters for Our Teams

Before SitecoreAI

• Bulk ops = custom PowerShell scripts
• AI generation = external tooling
• No governed way to build reusable AI workflows
• Pricing complexity = slow procurement

After SitecoreAI

• Agents handle bulk ops with an audit trail
• Brand-aware generation in the authoring UI
• App Studio = governed, versioned extensions
• One metric per module — demo anything on day 1

Final Thoughts

SitecoreAI is a genuine platform shift, not a rebrand. Your toolchain carries over. Start exploring Agentic Studio with one simple agent in a sprint spike - prove value on a single use case before scaling. If your team is still on JSS for SitecoreAI, plan the Content SDK 2.x migration now. JSS is already end of life for this platform.

Stay tuned for more Sitecore-related articles, tips, and tricks to enhance your Sitecore experience.
Till then, happy Sitecoring! 😊

Building a Custom Sitecore MCP Server in .NET — Tailored for Real Project Work

Hello Sitecorian Community! 👋

This is the blog I have been building toward across the whole series. Blogs 1–3 covered the foundations — understanding MCP, building a minimal .NET server, and setting up Anton Tishchenko’s community server against a live XP instance. All of that was preparation for this: building something genuinely mine, shaped around the actual work I do every day on a Sitecore project.

The Problem I Wanted to Solve

When I started thinking about what to build, the answer came quickly — because the pain was already obvious.

On every Sitecore project I have worked on, there is a category of work that is critical but relentlessly repetitive: managing Content Security Domain (CSD) role access. CSD is Sitecore’s standard security model for controlling which roles can read, write, rename, create, delete, or administer content nodes in the content tree.

On the surface it sounds simple — give a role access to a path. In practice, on an active project with multiple content authors, developers, and client stakeholders all requesting access at different points, it turns into a constant stream of small but time-consuming tasks.

The Before: A Manual, Repetitive Grind

Here is what the daily reality looked like before this server existed.

Every request followed the same path through the Sitecore Security Editor:

1. Open the Security Editor in the Sitecore Content Editor
2. Search for the role by name — sounds trivial, but role names across multiple domains (sitecore\, cog\, client-specific) are easy to get wrong, especially for roles you don't work with daily
3. Navigate to each content node — sometimes a single path, often multiple paths (content root + media library root for the same site)
4. Tick the correct permission type — CSD access (Read + Write) or CSD Admin (6 rights), with inheritance enabled so child items pick it up
5. Repeat for every path in the request — a single request often covers 2–4 paths
6. Repeat the whole thing for every role — some requests cover multiple roles at once
7. Verify the rules were applied correctly and propagated as expected

The hidden cost: this work required a developer. It was not something a BA or project manager could safely do through the Sitecore UI. Every request became a ticket, a context switch, an interruption to actual development work — adding zero feature value, carrying real risk of human error.

Figure 1 — The same CSD access request: a 5-step manual process taking 15–20 minutes vs a single natural language prompt taking under 1 minute

Figure 2 — Developer hours spent on CSD access management. The onboarding scenario (30–40 requests) sees the greatest saving: 5+ hours to ~45 minutes

The After: Natural Language + MCP

With the Sitecore MCP Server connected to VSCode, the same work now looks like this:

I need to set up CSD access for the "cgdev" team on the DemoSite.

1. Search for Sitecore roles matching "cgdev" to find the exact role names.
2. Grant CSD access (Read and Write) for the found roles on:
   - /sitecore/content/DemoSite
   - /sitecore/media library/DemoSite
3. Also grant CSD Admin access to any role matching "cgadmin" on the same paths.

GitHub Copilot in agent mode chains the tool calls in sequence — search, then grant, then confirm — and summarises the result. The whole thing takes under a minute. No Security Editor. No navigation. No repeated clicking across paths and roles.

The CSD Tools — Five Tools That Changed My Daily Workflow

The server exposes five tools specifically for CSD role access management. Here is each one in detail.

Figure 3 — Grant flow (top) and revoke flow (bottom). Both start with SearchCsdRole to confirm the exact identity. The no-Deny constraint in the revoke tools is enforced in code — not a prompt instruction

SearchCsdRole — Find the exact role identity first

Before granting or revoking access, you need the exact role identity string — including the domain prefix. On a real project with multiple domains (sitecore\, cog\, client-specific), guessing is error-prone.

This tool searches across all Sitecore domains by partial name match and returns the exact identities.

Search for Sitecore roles matching the name "cgdev".

Returns results like sitecore\cgdev, cog\cgdeveloper — whichever match. You pass those exact strings to the grant or revoke tools. This one step alone eliminates a common class of access mistakes.

GrantCsdAccess — Read + Write with inheritance

Grants CSD access (Read and Write) to one or more roles across one or more content paths. All rules apply with PropagationType Any, meaning they inherit to all child items automatically.

Grant CSD access for the role "sitecore\cgdev" on the following paths:
- /sitecore/content/DemoSite
- /sitecore/media library/DemoSite

You can also pass multiple roles at once. What used to be 4 separate Security Editor operations — 2 roles × 2 paths — is now one prompt.

Safety behaviour: paths that do not exist in Sitecore are reported as PathNotFound and skipped. The tool never silently fails and never applies partial access without telling you.

GrantCsdAdminAccess — Full admin rights with inheritance

Grants full CSD Admin access — Read, Write, Rename, Create, Delete, and Administer — with inheritance. Used for roles that need full editorial control over a site section, not just content authoring. Previously this required manually ticking six checkboxes per role per path in the Security Editor — easy to miss one under time pressure.

Grant CSD Admin access to the role "sitecore\cgadmin" on /sitecore/content/DemoSite 
and /sitecore/media library/DemoSite.

RevokeCsdAccess — Remove Read + Write safely

Removes CSD Read and Write Allow rules from roles on specified content paths. Designed for offboarding team members or restructuring access when a content section is reorganised.

Revoke CSD access for "sitecore\cgdev" on /sitecore/content/DemoSite 
and /sitecore/media library/DemoSite.

The most important design decision in this tool: it reads the item’s explicit ACL, filters out only the target Allow entries for the specified role, and resets the ACL with those entries removed. No Deny rules are ever written. A mistake during a revoke operation should never lock someone out of Sitecore content unexpectedly. This constraint is enforced in code — it cannot be overridden by a prompt.

If a role had no rules on an item, the tool reports RulesRevoked: 0 for that path and continues. It never fails silently.

RevokeCsdAdminAccess — Remove all 6 admin rights safely

Same safe revoke behaviour, but targets all six CSD Admin rights. Used when a role is being downgraded from admin to standard CSD access, or fully removed from a section.

Revoke all CSD Admin permissions for "sitecore\cgadmin" on /sitecore/content/DemoSite.

CSD Access Rights Reference

Figure 4 — CSD grants Read + Write. CSD Admin grants all 6 rights. Both propagate to all descendants automatically

How the CSD Tools Work Under the Hood

The CSD tools build inline SPE (Sitecore PowerShell Extensions) scripts at call time and execute them through the same PowerShell remoting client used by the RunSitecorePowerShellScript tool.

• Role searches use Get-Role -Filter with the partial name you provide
• Access grants use New-ItemAcl and Add-ItemAcl with PropagationType Any
• Access revokes read the item’s full explicit ACL, filter out the target Allow entries for the specified role, and apply the cleaned ACL back with Set-ItemAcl — no Deny rules are ever constructed or written

The Time Saving — In Real Numbers

Across a normal working week, that is roughly 8–10 hours of developer time moving from access management back to actual development work.

The Other Tools in the Server

Figure 5 — All 8 tools across 4 areas. CSD tools are the most project-specific; GraphQL, Item Service, and PowerShell cover broader daily Sitecore interactions

QuerySitecoreGraphQl

Run any GraphQL query against a Sitecore schema (edge, master, core). Handles the HTTP POST with the sc_apikey header. Supports variables and schema introspection.

Query the Sitecore Home item via GraphQL using the path /sitecore/content/Home in English.

Run a Sitecore GraphQL introspection query to list all available types on the edge schema.

GetSitecoreItemByPath

Retrieve a Sitecore item and all its fields by content tree path using the Item Service API (SSC). Supports any database and language.

Get the Sitecore item /sitecore/content/Home from the web database and tell me 
if it has been published — check the __Updated field.

RunSitecorePowerShellScript

Execute any script via SPE remoting — the most open-ended tool in the set. Copilot constructs the script from your intent, or you write it yourself.

Run a Sitecore PowerShell script to get all direct children of /sitecore/content/Home 
and return their Name, ID, and TemplateName as JSON.

Run a Sitecore PowerShell script to clear all Sitecore caches on the CM server.

Program.cs — How It All Wires Up

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = Host.CreateApplicationBuilder(args);
// All logs to stderr - stdout is reserved for MCP protocol messages
builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace);
builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithTools<GraphQlTools>()
    .WithTools<ItemServiceTools>()
    .WithTools<PowerShellTools>()
    .WithTools<CsdAccessTools>();
await builder.Build().RunAsync();

Each tool class registered independently with .WithTools<T>(). Adding a new tool category is one line.

Prerequisites

• .NET 8 SDK
• Sitecore XP or XM CM instance with GraphQL endpoint enabled, Item Service (SSC) enabled, and SPE installed with remoting enabled

Getting Started

git clone https://github.com/gaurarun777/sitecore-mcp.git
cd sitecore-mcp

Open in VSCode — the .vscode/mcp.json prompts for all credentials interactively when the server starts. Nothing sensitive is hardcoded.

⭐ github.com/gaurarun777/sitecore-mcp

Key Lessons from Building This

Design safety into the tool, not into the prompt

The no-Deny-rules constraint in the CSD revoke tools is enforced in code. It cannot be overridden by any prompt. On tools that touch access control, safety behaviour belongs in the implementation — not in hoping the caller remembers the right instruction.

Search before act

The SearchCsdRole tool exists for a reason. Role names across multiple Sitecore domains are easy to misremember. Searching first and confirming the exact identity before granting or revoking is the difference between a clean operation and an access mistake that takes time to diagnose and fix.

Repetitive work is the right first target

The CSD tools did not replace complex, high-judgment Sitecore development work. They replaced work that was clearly repetitive, time-consuming, and low-judgment — the kind where the value is accuracy and speed, not deep thinking. That is always the right first target for any automation.

One prompt can chain multiple tool calls

Copilot in agent mode chains tool calls automatically. You do not need to build orchestration into the server. Design tools to be focused and single-purpose — let the AI chain them together in response to a compound prompt.

The Full Journey

When I sat in that SUGCON India 2026 session, I wasn’t thinking about access management scripts. But when I looked at where developer time was actually going on the project, the answer was obvious. The MCP server did not solve an interesting engineering problem — it solved a real, daily, expensive one.

That is probably the most useful thing you can build.

Till then, Happy Sitecoring! 😊

References:
github.com/gaurarun777/sitecore-mcp
Microsoft Learn — Build MCP Server with C#
Flux Digital — Sitecore MCP Server with XP + VSCode & CoPilot
Anton Tishchenko — mcp-sitecore-server (GitHub)
SUGCON India 2026 — sitecoreknowledgeshare.blogspot.com