Published 31 July 2025
In the final blog of this three-part series, Bruce shares practical lessons and insights from a real-world Sitecore XM Cloud implementation, highlighting benefits, challenges, and best practices for development and content management.
In my first blog of this series of three, I talked about my journey from being a Sitecore newbie 18 years ago, to becoming frustrated with monolithic CMS systems. Along the way I had jumped ship and was basking in the joy of rapid development using React and Vercel, powered by leaders in the headless field, including Contentful and Kentico which lead to the second blog in this series. In my final blog for this series, I’m taking all I learnt and applying it to a real-world scenario, a brand new Sitecore XM Cloud build with a complete redesign and partial migration from Sitecore XP.
In the beginning
A slow burn – that’s how this project started. The client was an existing Sitecore XP customer who had been on the platform for several years, but as is often the case with monolithic systems, they had only used around 20% of its functionality. Sitecore XP is a sophisticated and powerful platform; however, many projects relegate the marketing and personalisation features to the mythical “phase two” which rarely materialises. In the end, most use XP simply as a content management system. It’s like owning a Ferrari and only using it for the odd trip to the shops.
Their existing website was… adequate. But customer satisfaction? Not so much. What began as a conversation about an upgrade or redesign quickly evolved into a full-scale transformation to Sitecore XM Cloud. And the benefits were clear:
Massive savings
Sitecore XP previously required substantial infrastructure, a typical mid-sized enterprise setup involved a Content Management Server, multiple Content Delivery Servers, an MSSQL Server, and a SOLR Server at a minimum. Multiply that by three for dev, staging and production environments, and the costs quickly added up. Plus, you were still on the hook for all the patching, upgrades, and backups.
By contrast, Sitecore XM Cloud is a SaaS product. You can run multiple environments, all managed through the Cloud Portal, without ever needing to touch a server or worry about upgrades, it’s all handled for you. Hosting is typically provisioned via a cloud provider like Vercel, replacing your traditional content delivery infrastructure.
The need for speed
At its core, XM Cloud is a content management service that publishes content to an API endpoint. Paired with your GitHub, GitLab or Azure DevOps repository, Vercel detects changes and automatically builds and deploys your site. XM Cloud mirrors this by spinning up Dockerised instances of Sitecore when a specified branch is updated. This allows for some customisation such as building custom content resolvers, though deep modifications to the core product aren’t encouraged.
The result? Speed. Vercel delivers an incredibly fast experience, with virtually no downtime. CI/CD pipelines are seamless and robust, supporting rapid iteration and zero service disruption.
From a developer experience perspective, it’s also a massive win. Spinning up a local Sitecore XP environment used to take days. With Docker-based starter kits, it’s now a matter of hours — and developers enjoy a consistent, predictable environment. No more “it works on my machine” moments.
Shifting the bulk of development from MVC to React also leads to major cost savings. Sitecore developers are scarce and often expensive. Front-end developers (JavaScript, CSS, HTML) are far more available and budget-friendly. Our experience showed that a single Sitecore developer could keep 2–3 front-end developers busy significantly reducing delivery costs
Lessons learnt: Taxonomy
Like the Monty Python skit where “No one expects the Spanish Inquisition”, no one seems to ever plan taxonomy, yet it impacts so many areas, let me explain. While content modelling defines the content structure which is in turn defined by the business shape itself , there is a whole other layer of definition that is often forgotten, this includes:
- Dictionaries – common phrases used throughout the site stored as content for re-use and avoidance of duplication.
- JSON/LD – which stands for JavaScript Object Notation for Linked Data, is a method of encoding linked data using JSON. It’s a way to structure data on web pages so that search engines and other applications can better understand the content and meaning of the information. Think of it as a way to make your website’s data “speak the language” of search engines and AI, helping them deliver more relevant results. There is a large, well-defined schema for implementing this: https://json-ld.org/
- Meta-tagging – often this will be using fields from your content but planning for this can be sub-standard in a of projects.
- Search categorisation – if you want people to easily find information, it helps to have categorisation, facets and filtering applied to our content. A simple example of why this is important might be around help desk calls. These cost a company money and driving down volumes by making sure, important, relevant content can be easily found on the site is often the key.
In the case of our project, this definition was done mid-development phase, whereas it would have been preferable to have a fully defined lexicon at the start.
Lessons learnt: Involve your architect
Without a doubt we were fortunate enough to have what I consider a most efficient component production pipeline – allow me to explain. In theory, a classic Sitecore project has two clear-cut development roles:
- Front-end – HTML, CSS, JavaScript
- Back-end – Sitecore configuration, templates, components, placeholders, partial design, page designs, rendering variants, MVC files, Razor views etc.
What I discovered in XM Cloud land, is these roles can become blurred if responsibilities are not carefully defined. As an example, let’s say we are tasked to build a simple Call to Action (CTA) component with the following specifications:
- A datasource with the following fields – a headline, a sub-heading, link and image
- A CTA folder under the data node allowing CTA Folders and CTA Items to be inserted
- 4 different ways to be displayed: Image left, Image right, Full width No Image, Full Width Background Image, Headline & Link (no subheading)
This is where the Sitecore architecture role becomes important, above we have 4 different layouts for the same data, a good candidate for 4 different rendering variants? Not necessarily, we want the content editors to easily achieve these 4 layouts but with the maximum simplicity and rock-solid bombproofing. So, the questions we first must ask are:
- Which fields are compulsory and what happens when a field if empty or over filled (think too much text), does the layout break? How do we manage this?
- Can the same piece of content be used for all variations? This would be ideal as it simplifies organising our CTAs into folders based more around specific business purposes rather than appearance. It also means less content to manage if content items can be re-used with different variations.
- How will the content editor interact with this component? What UI controls will they need to easily work with it? How can we put guard rails in place, so it won’t break, but doesn’t frustrate the users.
These considerations are clearly Sitecore specific and front-end developers can’t be expected to answer them. Yet how the actual HTML / CSS / JavaScript is put together is intricately tied to the decisions we must make above – a simple example, the image left / image right variants. If the front-end has been done before the Sitecore team is involved, it may have been built as two separate HTML blocks, which would force the Sitecore dev to create two rendering variants which the content editors would then choose when editing the component.
A simpler, less-code approach would be to build a single variant called Two-Column which defaults to image left. Then, we could add an SXA style to the component called Reverse Image. When selected, this would add a CSS class to the component which would swap the order of the columns.
I was involved at an early stage so was lucky enough to be able to say things like “Those five components the designer has designed? They are all the same, same fields, same content, different layout and can be achieved with 1component with 3 variants and 3 style controls”. Even so, there was still a good deal of condensing down commonalities when it came to build time.
Lessons learnt: It’s an application
The moral of the story? You’re not just building a website; you are building a content management application on top of a robust and versatile platform. The content editing experience must be factored in, and Visual Designers and Sitecore Architects should ideally be collaborating from day one from a content modelling starting point.
However, every project will vary from this ideal, in our case all the HTML and CSS was pre-done. Luckily the front-end dev had done brilliant work, allowing for a streamlined approach where roles were clearly defined, and double handling almost eliminated, it went like this:
All components were firstly scaffolded out as .tsx TypeScript template files in the solution with the HTML included and a console.log(props) added to avoid any linting issues.
The Sitecore dev picked up the ticket and would then:
- Create the item and folder templates, insert options and field validations
- Create the component definition with template type, datasource location and add the component to allowed renderings.
- Create a folder under the data node and add to the serialisation config
- Edit the .tsx adding the required imports, interfaces and types and replacing hard coded field values with fields, adding any styling logic, bombproofing code and Custom Experience Buttons.
- Test in all editing environments, Page Builder, Experience Editor and Content Editor
- Pass to testers with Training video to be cycled through visual bug fixes and released to the client.
Lesson learnt: Page builder is the future
Page Builder, or Pages is shaping to be the preferred editing environment for XM Cloud. Experience Editor is still available, but this will likely change. The reason is around the SDK support for React applications, previously the JSS SDK was used, however this SDK included a lot of functionality that was not required for XM Cloud, so a new SDK has been developed – the Content SDK which is essentially a slimmed down XM Cloud specific bit of kit. Read more about it here.
Put simply, Experience Editor is not supported by the Content SDK, leaving Page Builder as the only WYSIWYG editing environment. When we started this project, this was an issue as Page Builder did not support sophisticated fields such as Multi-list and Tree-list. Support for these fields was added halfway through our project, and even though the Content SDK is still in Beta, it important to factor in this upcoming change for any XM Cloud project.
Lessons learnt: Tips and tricks
Communication is key:
- To quote Mike Tyson, “everyone has a plan until they get punched in the mouth”. Things always shift during development and the sooner you communicate this to your client, your team and the testers, the better.
- Your application is your creation, don’t just build it them dump it on the steps at the orphanage – nurture it through the cycles until it is all grown up and ready for prime time.
- Over-explain and don’t assume everyone knows what you are on about, we used Microsoft Clipchamp extensively for professional quality training videos for all components and activities we expected the content editors to undertake.
- Document – make sure your developers document what they build somewhere. Someone will be along to change it later and knowing how and why you made the decisions you did will minimise technical debt build up.
Other considerations:
- Be proactive – we had multiple instances of “whoahh!! they didn’t think of that did they”. Clients will always appreciate initiative – a good example was Content Security Policy (CSP) which had not been considered. By proactively bringing this to the client’s attention along with a proposed solution, timeline and cost, the scope was changed, and the work was done pronto.
- Look for the value add – as an example the client used Sitecore Search, out of the box it worked fine, but the client was delighted when we demonstrated using search boosting for specific terms to expose highly relevant content in the top results – think driving down help desk calls.
- Leverage the platform – this includes using SXA OOTB functionality, setting guardrails like field validations, placeholder restrictions, organising the toolbox, and generally creating a great future-proofed content management experience.
Thinking about moving to XM Cloud?
If you’re starting to rethink your CMS, downloading our Sitecore XM Cloud eBook is a good place to start. In this guide, we’ll walk through why so many teams are making the move, what XM Cloud has to offer, and what you can expect if you decide to take the next step.
About the author
Bruce Davis-Goff is a Sitecore MVP and is Engage Squared’s Sitecore Practice Lead. He is a previous Sitecore employee and winner of the prestigious Sitecore MVP trophy for 6 years running (2017 – 2023). Bruce is passionate about all things tech and brings a wealth of knowledge and experience to our practice. So, whether it’s a rebuild, migration, reskin, or upgrade, we have you covered with the team to make it happen.
