Frontline insights: Building with Sitecore XM Cloud

After more than two years working hands-on with XM Cloud projects personally, I was especially interested in attending Derk Hudepol’s “XM Cloud Lessons Learned” session at SUGCON Europe 2025. Not just to compare notes, but to validate our own experience against one of the platform’s early adopters, pick up some fresh techniques, and reflect on the maturing state of XM Cloud delivery.

What followed was a clear-eyed walkthrough of architectural patterns, performance tactics, and practical pitfalls. For us at Think Fresh Digital, it was encouraging to see how closely our own approach aligns. Here's a breakdown of the most valuable takeaways, and what they mean for digital delivery teams today.

A shared blueprint for XM Cloud builds

Derk’s architecture could have been lifted straight from our own diagrams and repository:

• Separation of frontend and application concerns by a dedicated design system
• Design tokens exported from Figma, imported into the design system and implemented via Storybook
• Monorepo setup using Turborepo and multiple front-end applications
• Centrally managed UI components, imported selectively to optimise bundle sizes

The takeaway? There’s growing consensus around what good looks like in XM Cloud builds. It’s modular, design-driven, performance-focused, and clearly scalable.

It’s also worth highlighting the evolving “Sitecore Accelerate for XM Cloud” documentation. Sitecore’s own description sums it up well:: “Sitecore Accelerate Cookbook provides a set of recipes to guide the project team through an XM Cloud set-up, configuration and implementation, covering both technical and business aspects.”

This is a valuable and improving resource for anyone embarking on an XM Cloud project:

https://developers.sitecore.com/learn/accelerate/xm-cloud

Data driven migration ROI tracking

One of the most important lessons was the value of quantifying both authoring and development improvements post-migration.

• How long does it take to build a page in XP vs XM Cloud?
• What’s the impact on developer velocity before and after switching stacks?
• Can you baseline and track these as KPIs?

We often apply this thinking in client projects, but it’s just as critical internally. Migrating to XM Cloud is an investment. Demonstrating its return should be part of the plan.

Lock down JSS package versions

A subtle but crucial warning: Sitecore JSS doesn’t follow semantic versioning to the letter. That means relying on the caret (^) in your package.json may result in unexpected breaking changes as minor updates roll out.

Stick to:

• Tilde (~) for patch-level updates
• Fully pinned versions for maximum stability

To clarify the difference between the use of the carat versus the use of the tilde:

• ~version “Approximately equivalent to version”, will automatically update you to all future patch versions that are backwards-compatible, without incrementing the minor version. ~1.2.3 will use releases from 1.2.3 to < 1.3.0.
• ^version “Compatible with version”, will automatically update you to all future minor/patch versions that are backwards-compatible, without incrementing the major version. ^1.2.3 will use releases from 1.2.3 to < 2.0.0.

A small change with big impact on CI/CD reliability. If you are unfamiliar with Semantic Versioning everything you need to know can be found at:

https://semver.org

Adopt a cadence for front-end upgrades

Compared to the slower-moving world of .NET MVC, the JavaScript ecosystem moves fast, really fast. Frameworks like Next.js and Node, along with all their dependencies, evolve at a rapid pace.

Derk recommends—and we agree, adopting a structured cadence:

• Every few sprints, audit your dependency tree
• Follow Sitecore’s changelogs
• Apply upgrades incrementally rather than reactively

This avoids the dreaded “upgrade cliff” and keeps your stack predictable.

Cache invalidation in XM Cloud is still evolving and it’s a challenge for everyone

Revalidating routes in an ISR-based Next.js setup with XM Cloud is a real challenge, especially when global components like headers or footers change.

Key issues:

• Publishing to Edge is batched and lacks transparency
• No UI currently exists to monitor the publishing queue
• For global content updates, you may need to trigger revalidation across every page
• With pages-router (which JSS currently requires), this involves manually passing every path, risking 429 (Too Many Requests) errors on Sitecore Edge or third-party services your pages depend on at build time

For sites with wildcard routes, like product pages, this quickly becomes complex.

Derk’s solution (one we’ve also implemented) is to implement Edge webhooks which send publishing payloads to Vercel API routes that call back to Edge for payload details and then invoke revalidate selectively.

Effective, but not without challenges:

• The necessity to call back to Edge for every page update in the webhook payload, which can lead to 429 errors, which in turn necessitates complex retry and/or queuing / rate limiting logic
• If you have enabled Edge runtime publishing, Edge runtime publishing disables dependency tracking—your revalidation function won’t know what to refresh when only a datasource item changes.

https://doc.sitecore.com/xmc/en/developers/xm-cloud/enable-edge-runtime-publishing.html

There are other approaches to solving this challenge such as making on-demand page level revalidation available to content authors in conjunction with a much longer ISR interval. This approach means that pages naturally revalidate after say 6 hours but if authors want to see a particular page update immediately, they can trigger an immediate revalidation.

This works well for specific pages but doesn’t solve the challenge of site wide changes to global components or dynamically generated pages that depend on wildcard items.

For these scenarios there are options:

• For dynamic content: Use edge webhooks to detect changes to global components or configuration items your dynamic pages depend on and build a custom “sitemap” function to retrieve all your dynamic paths and pass them into the on-demand revalidation function backed by a retry and/or queuing mechanism. 429s can still be a problem here if your dynamic pages rely on third-party service at build time. For these issues consider loading these components on the client when they come into view or on user interaction
• Scheduled redeploys: For global component changes, negotiated as part of SLA expectations.

Note: it’s important to remember in all this that ISR doesn’t guarantee immediate updates, it just triggers background validation (Stale-While-Revalidate pattern). The first user still sees stale content. Only on-demand revalidation delivers immediate updates.

Lastly on this topic, to get around Sitecore Edge webhooks having a lack of a management UI, Derk also built a lightweight admin interface on top of the Edge Webhooks API using v0 by Vercel. Smart thinking—and a great workaround until native tools improve.

Vercel-specific optimisations matter

If you're deploying on Vercel, be mindful of resource consumption and the configuration of your application. Vercel recently published tips that are well worth reviewing.

• Utilise Fluid Compute wisely
• Rely on Vercel’s native firewall to block bot traffic
• Review Sitecore middleware, it may be unnecessary
• Use Vercel’s observability tools to pinpoint excessive API or middleware calls

Simple changes here can lead to significant cost and performance gains. We’ll be sharing more on this topic in a dedicated article.

The full guide is here:

https://vercel.com/guides/how-to-optimize-next.js-sitecore-jss

Configure workflow early

This one hit home: define your content workflow at the beginning of the project. Retroactively applying workflow rules is messy, time-consuming, and frustrating for everyone involved.

It’s tempting to leave it until “after MVP”—but don’t. Build it in from the start, alongside roles and permissions.

At Think Fresh Digital this is something we always put right up at the top of the backlog.

A Forms permissions gap to watch

Currently, creating new forms in XM Cloud requires full admin privileges, far beyond what most content authors should have access to.

It’s not ideal, but Sitecore is aware of the issue and has prioritised a fix. Until then, plan accordingly and avoid exposing unnecessary permissions in production environments.

Best practices are emerging, let’s keep sharing them

Derk’s session was refreshingly grounded. No shiny new features or gloss, just honest reflections from someone deep in the trenches of XM Cloud delivery.

It was validating to see how closely our approaches align. But more importantly, it underscored the need for shared learning. As a community, we’re shaping what “good” looks like in XM Cloud delivery, and the more we share, the stronger those foundations become.

Some of the issues raised—like cache revalidation, deserve deep dives of their own. But for now, these lessons stand as valuable reference points for anyone navigating XM Cloud projects at scale.

References

Khan, F. (2014) What’s the difference between tilde(~) and caret(^) in package.json?, Stack Overflow. Available at: https://stackoverflow.com/a/22345808.

Getting started with ISR (2025) Vercel.com. Available at: https://vercel.com/docs/incremental-static-regeneration/quickstart#on-demand-revalidation (Accessed: 21 April 2025).

Okour, A. (2024) On-Demand ISR for Sitecore pages right from the content editor, Medium. Available at: https://www.sitecorecoding.com/on-demand-isr-for-sitecore-pages-right-from-the-content-editor-b6c97569b9a1 (Accessed: 21 April 2025).