Sitecore Best Practice Series:


Sitecore XM Cloud Best Practices

# Practice Rationale
1. Use SPE for platform customizations and reporting instead of .Net Reduce future maintenance by making your customizations and automations less intrusive to the platform with SPE.
2. Package modules as NuGet packages Serilize module content using SCS and include it with module code in the XM Cloud solution. Packaging modules using NuGet or other package managers allows to easily add a module to your implementation and reduce environment creation and solution deployment time.
3. Understand the underlying principles of Helix and apply them as needed Helix is a combination of architectural design princples that touch content and code architecture. While the code architecture is no longer applicable to head implementations, many content structure and general development principles are timeless, make sure to follow the relevant ones.
4. Implement redirect functionality at the Edge While redirect rules can continue to be managed in Sitecore XMC, implement a middleware layr in Vercel to cache the redirect rules and execute them at the Edge.
5. Use Vercel’s image optimization Take advantage of performance gains and reduce operation overhead related to generating next gen image formats by using Vercel's automated image conversion to webp.
6. Create business logic, APIs, jobs outside of XM Cloud solution Avoid deploying data processing logic, jobs, or creating custom APIs hosted in the XMC instance to avoid breaking changes and issues with platform performance. It is possible that Sitecore will implement a gate diallowing these types platform customizations in the future.
7. Avoid customizing the XMC platform as much as possible Export platform customizations out of the solution into external serverless applications being called by XMC webhooks and using XMC's APIs to manage the platform and manipulate content to significantly reduce the amoutn of future maintenance and potential breaking changes with major platform upgrades.
8. Avoid circular referenced in content items Circular content references like item 1->item 2->item 1 may cause significant delays in publishing to Edge in XMC.
9. Use rendering parameters to expose functional and visual component customizations The new pages tool makes rendering parameters a code piece in content author experience dedicating the entire right section of the editor to it. Make sure to follow the Headless SXA guidelines in exposing component configration and styling for content authors to enable self-service.
10. Remove ghost code from the Sitecore XMC Head Foundation solution While the Sitecore XMC Head Foundation solution ( is the right place to start building an XMC implementation, it it likely you will not make use of all the code in the repository. Reduce maintenance by removing all unused "ghost code".
11. Use the Sitecore XMC Head Foundation repository Use the startup project repository from Sitecore for your projects: The cosde structure lays out some recommended architectural practices and provides examples of implemetations that may help reduce development time.
12. Do not store secrets in Sitecore XM Cloud Deploy While XM Cloud Deploy is a good place to store environmet-specific configurations, avoid storing secrets in the application and instead use secure cloud stores like Azure Vault. Azure Vault allows for centralized secret management with additional tools for streamlining and automating relevant operations, like key rotations, for instance.
13. Build the “head” of the application using the Edge Frontend developers do not need to setup a local instance of Sitecore XMC unless they work directly with content and templates, and rather work against the Edge in a cloud XMC instance. This practice helps reduce the effort going into a local development machine setup, and speeds up the development flow by removing the need to maintain the local XMC instance.
14. Retain as much .Net code as possible when migrating to XMC When moving from another .Net platform or modernizing from Sitecore XP to XM Cloud, try to keep as much of the existing .Net code as possible, because .Net performs faster than Next.js when it comes to jobs, processing, APIs, and business logic in general. This practice will also help keep the cost of migration down.
%d bloggers like this: