Sitecore announced SitecoreAI on 4 November 2025. The press release was clear about the commercial story: SitecoreAI is the evolution of XM Cloud, current XM Cloud customers do not run a content migration, data stays in place, and Agentic Studio shows up on the same tenant. I have spent the year since that announcement on Next.js implementation work, and the question I still get in kickoff calls is the same one. If the upgrade is seamless, why does the head application feel like a project?
The honest answer is that two upgrades got collapsed into one sentence. The SaaS content tenant moved forward without a replatform. The JavaScript stack that renders that tenant has its own lifecycle, and that lifecycle has been moving since the week of the announcement. This post is the map I use with a Next.js team in October 2026, looking back at what was public in November 2025 and what the developer documentation says now.
The 4 November 2025 announcement, published from London, described SitecoreAI as a composable SaaS platform built on XM Cloud and hosted on Microsoft Azure. It unifies content management, customer data, personalization, and search. The new workspace is Agentic Studio. Sitecore said it launched with 20 prebuilt agents covering work from campaign planning through content migration, production, and testing, plus visual tools so marketers and agency partners can design their own agents and flows. Agentic Flows orchestrate multi-step work from briefing and experimentation through publishing. Spaces are the collaboration surface between people and those agents.
The same release named the upgrade path for existing XM Cloud customers: no migration, continuity of data, and access to Agentic Studio and the prebuilt agents. I take that sentence literally. Items, templates, sites, media, and the Experience Edge content the site already reads are not thrown away because the product name changed. When a stakeholder asks me to budget a "SitecoreAI migration" for a healthy XM Cloud implementation, I split the estimate. Tenant continuity is the vendor's claim. Head-application work is ours, and it is a different line item.
Sitecore also framed the product around discovery that happens outside the website: feeds, summaries, and moments where the brand has to show up with a governed message. That framing matters for implementation teams because it pulls Search, brand kits, and the rendering app into one conversation. It does not, by itself, change a getStaticProps function.
A few days before the announcement, the Sitecore developer changelog recorded two SDK facts that are easy to miss if you only read the press release. On 29 October 2025 Sitecore published an SDK lifecycle for XM Cloud: Content SDK 1.x became the actively supported SDK, and JSS support on XM Cloud moved onto a phase-out path. On 30 October 2025 Content SDK 1.2 added Next.js App Router support and shipped it as a beta. Server components, streaming, nested layouts, and fetching layout data from server components were in that beta. Sitecore said the beta was supported for teams who wanted to try it, and that the shape could still change. I treated "try it" as the operative instruction in late 2025. I still treat a router migration as its own project in 2026.
The websites I work on still render Sitecore content through a head application. Pages are still compositions of placeholders and components. Field values still arrive as layout data or as a GraphQL result. Experience Edge is still the delivery API in front of published content. A page that was fast in October 2025 did not become fast because Agentic Studio appeared in the portal, and a page that over-fetched GraphQL did not heal itself either.
Authors still publish. Workflows, if you had them, still gate what Edge will serve. I wrote earlier in 2025 about Stream's optimize-content actions inside the page editor, and about cache tag purge when a publish has to show up on Netlify. Those problems are still implementation problems. SitecoreAI gives authors more ways to draft and to run a governed flow. The CDN in front of the Next.js app does not learn about that flow unless we invalidate it.
Component code remains the contract for anything an agent is allowed to create. If the hero component reads heading, summary, and image, an agent that writes a fourth field into a datasource does not get a new visual. It gets a value the component ignores. I have watched teams discover this the expensive way: a flow "succeeds" in Agentic Studio, the page item exists, and the site renders an empty region because the rendering item or the component map was never part of the flow.
Search stays a configured product. SitecoreAI's story includes search, and the Questions and Answers capability in Sitecore Search is a real, documented feature. Index attributes, document extractors, and widget rfkIds do not reconfigure themselves when the portal is rebranded. I cover that work in the posts later this week. For this one, the point is narrower. Announcement week was not a Search cutover.
The SDK lifecycle is the change I plan against. JSS carried XM Cloud sites for years, including the multisite Next.js apps most of us still have in production. Sitecore's own position, written into the October 2025 lifecycle note and repeated in the Content SDK upgrade guides, is that one JavaScript SDK should not keep serving two diverging runtimes. Content SDK is the SDK for SitecoreAI. It drops Experience Editor chromes, generates a component map instead of the old component builder, and funnels data access through SitecoreClient.
By October 2026 the upgrade guide I hand a team is the Content SDK 2.1 guide for a JSS 22.0 Next.js app. That guide expects Next.js 16, React 19, sitecore.config.ts, sitecore.cli.config.ts, and a defineProxy helper, because Next.js 16 runs proxy.ts. Content SDK 1.5 and earlier called the same idea defineMiddleware. Match the guide to the package version you install, and trust the create-content-sdk-app scaffold when a checklist still says only middleware.ts.
Editing changed in a way authors notice before developers do. Content SDK does not support the Experience Editor, and it does not support preview opened from the Content Editor. Preview and visual editing go through the SitecoreAI page builder, using metadata on the fields. field.editable is gone. Field components read field.metadata. pageState, pageEditing, and renderingType on the layout context fold into page.mode, with flags such as isEditing, isPreview, isNormal, and isDesignLibrary. Any component that branched on the old context properties still compiles only if nobody deleted the property access. Once the import moves to @sitecore-content-sdk/nextjs, those branches fail, or worse, they silently stop wrapping the authoring chrome.
Environment names moved with the SDK. The 2.1 guide renames SITECORE_API_KEY to NEXT_PUBLIC_SITECORE_API_KEY, SITECORE_API_HOST to NEXT_PUBLIC_SITECORE_API_HOST, SITECORE_SITE_NAME to NEXT_PUBLIC_DEFAULT_SITE_NAME, DEFAULT_LANGUAGE to NEXT_PUBLIC_DEFAULT_LANGUAGE, and JSS_EDITING_SECRET to SITECORE_EDITING_SECRET. SITECORE_EDGE_URL is replaced by NEXT_PUBLIC_SITECORE_EDGE_PLATFORM_HOSTNAME on Next.js so the client bundle and the server agree. DISABLE_SSG_FETCH becomes GENERATE_STATIC_PATHS, and the meaning is inverted. I have seen a pipeline "succeed" with an empty static path list because someone copied true from the old variable into the new one.
Logging into Agentic Studio in November 2025 did not require any of it. Picking up the SDK Sitecore is supporting now does.
I keep four buckets on the board. Mixing them is how a two-week authoring rollout becomes a quarter-long rewrite.
Tenant continuity. Confirm the organization is on SitecoreAI, Agentic Studio is visible to the roles that need it, and existing sites still resolve. This is mostly an admin and smoke-test exercise. Sitecore's November 2025 statement was that XM Cloud customers do not migrate content to get there.
Authoring and agents. Brand kits, prebuilt agents, and any custom workflow agent. Custom agents need a Builder license, which is documented on the create-a-workflow-agent page. This bucket changes the portal. It should only create pages and content that the current component set already understands.
The rendering app. Content SDK, on the version you can support, Pages Router first if that is what production runs. App Router support shipped as a beta in Content SDK 1.2 at the end of October 2025. I still schedule that router move separately from the package swap.
Discovery. Sitecore Search attributes, extractors, and the Questions and Answers group if you want answers grounded in your index. That work pays off the "world beyond the website" line in the press release. It is not a side effect of installing Content SDK.
Agents and the page builder both end up calling the same renderings. The guard I want is boring. It asks two questions: are we in an authoring mode the page builder understands, and is every rendering name present in the component map the build generated?
type PageMode = {
isEditing?: boolean;
isPreview?: boolean;
isNormal?: boolean;
isDesignLibrary?: boolean;
};
export function isAuthoringMode(mode: PageMode | undefined): boolean {
return Boolean(mode?.isEditing || mode?.isPreview || mode?.isDesignLibrary);
}
export function assertKnownRendering(
componentName: string,
componentMap: Record<string, unknown>
): void {
if (!componentMap[componentName]) {
throw new Error(
`Rendering "${componentName}" is not in the Content SDK component map. ` +
`An agent or the page builder can place it only after the Next.js app registers it.`
);
}
}
page.mode is the Content SDK shape. The throw is my choice. The SDK's usual behavior for an unknown rendering is to render a fallback, which is friendlier in production and useless in a migration branch. I fail the authoring build so a new agent flow cannot ship a rendering the repository has never heard of.
The matching config check is about Edge, not about agents. After the environment rename, a Next.js app should resolve the platform host from the public variable and fall back to Sitecore's default only when nobody has set one:
const edgeUrl =
process.env.NEXT_PUBLIC_SITECORE_EDGE_PLATFORM_HOSTNAME ||
'https://edge-platform.sitecorecloud.io';
That default is the one the Content SDK 2.1 guide documents. If your tenant uses a custom Edge hostname, the public variable has to be present at build time. Next.js inlines NEXT_PUBLIC_* then. A runtime-only secret with the old SITECORE_EDGE_URL name will not reach the client, and preview will look randomly broken depending on which side issued the request.
I do not schedule a head rewrite because the product brochure changed. The November 2025 promise to XM Cloud customers was continuity. Spending that continuity on a from-scratch App Router app throws away the part that was actually seamless.
I do not let a workflow agent create templates. The Next.js component and the GraphQL selection are compiled. An agent can fill fields, place a rendering that already exists, and start an experiment. The Agent API documents job ids so a bad write can be reverted. Search Q&A stays a separate piece of work: generation only sees attributes you extracted, and extractor validation does not execute client-side JavaScript.
This is the order I recommend when the site is already on XM Cloud and SitecoreAI is in the portal. It is an implementation sequence, not a Sitecore-mandated program.
temp/config, page-props plugins, and every read of field.editable.sitecore-tools before next build.The platform move was real in November 2025, and for an XM Cloud customer it was mostly a portal change. The Next.js change is real too. It shows up when you leave JSS, when you follow page builder metadata, and when you stop assuming an agent understands a component you have not registered. Those are the items I put on the board. The product rename is not one of them.
In this blog post, we will explore a common requirement in Sitecore Headless SXA, exposing site-specific settings and global data to the front end when working with a JSS headless site. ## Problem S
Read MoreRecently, while working with a Sitecore 10.4 deployment in an Azure environment, we encountered an interesting challenge: handling Sitecore Content Management (CM) and IdentityServer (SI) behind a pr
Read MoreIn this blog post, I'll walk you through the process of smoothly leveraging the Search SDK Starter Kit into a Sitecore Next.js solution. ## Prerequisites Before proceeding, ensure the following prer
Read More
![Leveraging Sitecore Search SDK Starter Kit into Your Sitecore Next.js Solution [Part 2]](/_next/image?url=%2Fimages%2Fpost%2Fstarter-kit.png&w=828&q=75)