Should I Stay or Should I Go? Why not both?: Planning your Sitecore XM Cloud Migration

Should I Stay or Should I Go?

In the last episode, I discussed a crossroads decision point that businesses often find themselves in: stay with an establish platform like Sitecore XP, or migrate to Sitecore XM Cloud. Stuck between two giants in the digital platform space? What if I told you there's a third, equally formidable option? Let me introduce it: both.

Why Not Both?

Hear me out. Migrating to XM Cloud can be a serious undertaking. As I previously suggested, in addition to re-architecting the website and every component, you may want to consider a complete redesign as well. This can be a large pill to swallow for many organizations that haven't already planned for such an expense. A 'dot' upgrade is one thing, but re-architecture, redesign, and redevelopment is much more involved.

What if there was a way to migrate to XM Cloud over time as your budget and capacity allows?  Well, there is. On a recently-launched client project, the client wanted to move to XM Cloud quickly, but didn't have the appropriate budget for the year and didn't want to wait for a 'big bang' at the end of long design and development cycles. As it turns out, Microsoft has a solution we can incorporate to address this issue.

Hello Azure Front Door, you had me at . . . Hello

Azure Front Door is many things, but if you wanted to simplify it for easy comprehension: it's an entry point to your domain. When incorporated, all traffic for your domain gets routed through Azure Front Door and then rules are executed against the incoming request to match for specific patterns. The patterns to match could be from the request path, the domain, the protocol, geo-location, etc.. Actions are assigned to the rule and a match can direct traffic to multiple endpoints (origins).

In the case of our client, we helped them develop a prioritized list of pages to migrate to XM Cloud immediately, and over time we will eventually migrate all approved pages to XM Cloud. The prioritization process involves determining which pages we will keep, which we will modify, and which we will eliminate from the new site. The pages that were not prioritized to move to XM Cloud will continue to live on the Sitecore XP platform as-is. In our case, we modified the XP header and footer to more closely match the header and footer of the newly-designed site to not cause total shock when navigating from XM Cloud to XP pages, but no changes are required to make the XP pages work just as they always have.

When Azure Front Door fields a request for the domain, it is processed by a ruleset. Our rules were configured to look for the XM Cloud pages. If the pattern of the incoming request matches a pattern for a page on the new XM Cloud site, it is directed to the XM Cloud origin. When it does not match, Front Door passes the entire request through to the XP origin. This can all happen using the same domain name so that your users aren't confused.

In this way, we have achieved running both versions of Sitecore concurrently and can complete redesign and redevelopment of the remaining portions of the site as budget and time allow!

Gotchas?

Oh yeah, there are some gotchas, of course.

Depending on how many pages you want to divert to one origin or another, Azure Front Door will handle it gracefully or it will start to choke. Front Door starts to break down as you approach the limit for routing rules. (25 for Standard tier or 50 for the Premium tier) This may sound like plenty, but if you happen to have some redirects in addition to the routing, or want to handle http vs https differently, these add up quickly. What helps here is that you can apply many patterns within a single rule when matching. For example: if the rule states that anyting matching your patterns should just forward on the same request path to the origin specified, you can bundle many patterns together to perform the same action. So if you're clever with how you match and how you redirect, this may not be too much of a limitation, but it's still something to look out for.

Running Sitecore XP and XM Cloud alongside each other is going to have some cost concerns. You're essentially running two websites, with two licenses, with hosting for two sites at the same time. While running both alongside each other will allow you to dip your toes in the water, you may drop your wallet in the lake too.

Conclusion

The decision to upgrade your Sitecore implementation to the latest version of XP or migrate to Sitecore XM Cloud is an important one. You may have thought those were the only two options, but you now you have (at least) one more option. Operating both platforms simultaneously can help get your organization moving towards the Cloud at their own pace. Understand the pros and cons of the options before jumping in is essential to ensure that you're making the right decision for your organization or client.

Crossroads: Animal House or Sit Tight: Key Considerations Before Migrating to Sitecore XM Cloud

Crossroads

As Sitecore XM Cloud gains more traction in the market, businesses often find themselves at a crossroads, contemplating a shift from established solutions like Sitecore XP to more modern platforms like Sitecore XM Cloud. While the promise of enhanced scalability, flexibility, and performance is alluring and you may want to charge in like Bluto from Animal House, but it's crucial to tread carefully and consider various factors before making such a significant transition. 

Do you go ahead and go all-in on Saas and XM Cloud, or do you continue down your path of upgrades and traditional Sitecore XP? Let's explore some key considerations that can impact the success of your move to Sitecore XM Cloud.

Cost Analysis: Licensing and Hardware

Shifting to Sitecore XM Cloud involves not only licensing changes but also considerations regarding the underlying hardware infrastructure. Assess the financial implications of this transition by comparing licensing costs and evaluating whether your existing hardware is compatible with the cloud-based architecture. A key selling point of any SaaS platform is the savings on infrastructure, but your (or your client's) organization may have infrastructure that will continue to live on in the future platform. It's vital to have a clear understanding of the long-term cost implications and potential return on investment.

Skillset Evaluation: Backend vs. Front-end Development

We already discussed cheese, I mean, the rise of the Sitecore frontend developers, in my last post, but Sitecore XM Cloud embraces a more modern approach, often requiring expertise in front-end technologies such as React and Next.js. Assess the skillset of the existing team; if the developers are predominantly C# backend experts, you may need to invest in upskilling or hiring front-end developers to ensure a smooth transition. Frontend tech is no joke; some might say it never was, but it's not 'just' HTML and CSS. Bridging this skills gap is critical for the successful implementation of a headless site based on Sitecore XM Cloud.

Site Redesign Considerations

Shifting to Sitecore XM Cloud will necessitate a reimagining of your website's architecture. The move towards a headless architecture means that every component must be re-developed to align with the new paradigm. There are ways to make this migration to headless in more of a piecemeal manner, but there are defintely cost implications. 

While you're at it: How's that design holding up?  If you're re-developing every component, perhaps it's a chance to redesign as well. It's a chance to not only adopt a new platform but also to enhance the overall user experience with a fresh design.

Evaluate whether your organization is prepared for a full site re-architecture and potential site redesign, taking into account the time, resources, and potential disruption to ongoing operations. 

Content Strategy and Migration

Consider how your current content strategy aligns with the capabilities of Sitecore XM Cloud. The shift might require a comprehensive content migration plan, ensuring that your existing assets seamlessly integrate with the new platform. If you've made the decision to re-develop and re-design, does your content need some attention too?  Plan on a comprehensive content audit to determine what content you keep, what content you update, what content you kill. Evaluate the tools and processes available for content migration and factor in the time and effort required for this crucial aspect of the transition.

LET'S GO!!

Inspiration Animal House GIFfrom Inspiration GIFs

Transitioning from Sitecore XP to Sitecore XM Cloud holds the promise of a more scalable, flexible, and modern digital experience platform. However, success in this journey requires careful consideration of costs, skillset gaps, the need for a site redevelopment (and optionally, redesign), and content audit/content migration. 

In the end, you may decide that your organization or client is not yet prepared for the investment to move to XM Cloud and you need to sit tight.  You may need more time to gain stakeholder support or budget or maybe you're considering dipping your toes into the water instead of jumping in, à la Animal House. I suspect that all organizations will eventually be forced into the SaaS platform model to retain full support, but but by understanding and addressing these considerations thoughtfully, you can make plans for a successful quick or measured transformation that maximizes the benefits of Sitecore XM Cloud while minimizing potential challenges.

The Evolution of Sitecore Development: Embracing SaaS, Front-End Expertise, and Cheese!

Who Moved My Cheese?!

In the ever-evolving landscape of web development, platforms like Sitecore have played a pivotal role in shaping digital experiences. Traditionally, Sitecore development has relied heavily on backend (usually C#) developers to craft Sitecore solutions. However, with the advent of Sitecore XM Cloud and the shift towards a Software as a Service (SaaS) model, the dynamics of Sitecore development are undergoing a significant transformation. 

I often introduce myself as an architect that has a background in Microsoft technologies, specifically C# and Sitecore.  Moving the focus of Sitecore development towards frond-end technologies sounds like I'm putting myself and other backend devs out of work, but fear not, it doesn't have to be that way. I remember a time where people thought that the introduction of Visual Studio meant that the days were numbered for developers.  You may be thinking now that the same is true when we talk about the evolution of Sitecore development. (well, if you're a backend developer, that is)    

What does this shift mean for traditional, backend Sitecore developers, the increasing importance of frontend developers, and the shift towards a more collaborative, product-focused approach?  I'm glad you asked.

The Shift to Sitecore XM Cloud

1. Embrace Cheese, I mean, SaaS for Scalability
   Sitecore XM Cloud represents a shift towards a cloud-based, scalable architecture. This move not only simplifies infrastructure management (aint nobody got time for that) but also opens new doors for collaboration between backend and frontend developers. The emphasis on SaaS allows for quicker deployment, reduced maintenance overhead, and a more seamless development process.
   
   
2. The Rise of Front-End Development in Sitecore
• React and Next.js Integration
  We are flipping staffing models from staffing a 'bunch' of backend developers along with a 'few' frontend developers on its head. As Sitecore (and partners) embrace a more API-first approach, the need for proficient frontend developers has become more pronounced. React and Next.js have become integral components in the Sitecore development toolkit and frontend developers now play a crucial role in shaping the user interface and optimizing the overall user experience.  We aren't forgetting about the backend devs as you will see below.
  
  
• Enhanced Content Delivery
  With a focus on content delivery to the frontend, Sitecore developers are transitioning from being solely backend experts to becoming well-versed in frontend technologies. This shift not only empowers developers to create more interactive and dynamic user interfaces but also facilitates a more collaborative development environment.

The Changing Role of Sitecore Developers

1. From Code-Centric to Product-Centric
• Configuring Sitecore for Frontend Integration
  Sitecore developers are no longer just coders; they are becoming product experts who understand the intricacies of configuring Sitecore to seamlessly integrate with frontend technologies. This involves mastering the art of content organization, personalization, and API configurations to ensure a smooth flow of data between the backend and frontend.
  
  
• Collaboration with Frontend Teams
  The lines between backend and frontend development are blurring, and collaboration is key. Sitecore developers now work hand-in-hand with frontend teams, providing them with the necessary tools and data structures to bring digital experiences to life. We can move away from 'The front-end devs have to understand and run Sitecore on their machines' fallacy.  Let's let front-end devs do what they do best.  Let's let Sitecore experts do what they do best.  Let's let them collaborate so they can build build great Sitecore sites. This collaboration fosters a more holistic approach to Sitecore development.

Embrace the Cheese, I mean, Change

The evolution of Sitecore development towards a SaaS model, particularly with Sitecore XM Cloud, marks a shift in the skills and expertise required to develop today's modern websites. While backend Sitecore developers will always be valuable, the demand for frontend developers with React and Next.js experience is on the rise. 

Sitecore developers are no longer confined to the backend; they are evolving into versatile product experts, bridging the gap between backend infrastructure and frontend innovation. We still need backend deveopers to help with the configuration of Sitecore, creation of Sitecore artifacts, devOps processes, integrations, search, gated content, etc. This transformation not only enhances the efficiency of development processes but also results in more dynamic and engaging digital experiences for end-users. 

As the world of Sitecore development continues to evolve, embracing this change is essential for staying at the forefront of digital innovation.

References:

Who Moved My Cheese (We had a training session early in my career where we discussed this book and it's always in my head and I wonder if people look at me like I'm crazy when I mention it.  The book is about embracing change. It talks about a mouse who is mad that his cheese has been moved and he can't let it go.  Instead of focusing on that, embrace the change and learn how to operate while your cheese is in a new location.  I hope this helps to explain why I keep referring to "cheese" in this post.)

Syncing TDS content with Sitecore and the Field Content Does Not Match Content-Length Error

So I recently ran into an issue on a new-to-me project.  The solution was already created, the project team had moved on to other projects and I was tasked with getting a new team ready to make some enhancements. While attempting to sync my Sitecore content with my local instance, I received a TDS error stating:

This is a known issue when working with TDS and git and the solution to correcting this has been provided earlier by others here and here.  In summary, the solution is to update the .gitattributes file by adding a line with the following:


This works great going forward, but doesn't address the issue you already have.  As both articles mention, the solution is to delete your local TDS files and re-sync.  For my situation, this doesn't work as I don't have the items in my local instance yet and deleting the items on disk would just lose them forever.

The solve is rather manual in nature, but here is what I did:

1. Attempt to sync TDS with Sitecore and make note of all the items that have the error.  In my example, I'm only showing a single line, but you may have many. (as I did before I took this screenshot)
   
   
   
2. Open the .item file in a text editor.
3. Take note of the template type of the item and create a new item in Sitecore with the same type. (making sure to create the item with the same name/path as in the item file)
4. Copy the relevant fields from the .item file and paste them into the proper fields in your new Sitecore item.  In my case, I have an "Action" template item and only care about "Type", "Parameters" and "Security" fields. (Note: You don't have to worry about every field, but you should take care to bring over the important fields to your application.  You can usually ignore fields like "_sortorder", "__owner", "__created", etc.)
   
   
   
5. Save your Sitecore item.
6. Sync your TDS item to Sitecore from Visual Studio.

Your error is now gone and you can continue on your way.  As mentioned, this can become an extremely tedious process depending on how many items and how many fields you have on your items, but in my case, was a necessary evil. Someone smarter than me could probably develop a script of some kind to address the error on a larger scale, but I'll leave that to the aforementioned smarter people.

References:

Deploying Sitecore Items with Git and TDS (Hans Léautaud from 2014): https://medium.com/sitecore-tips-tricks/deploying-sitecore-items-with-git-and-tds-f6a47605d1b4

Hedgehog TDS - Field Content Does Not Match Content-Length (Corey Smith from 2016): https://www.coreysmith.co/hedgehog-tds-field-content-does-not-match-content-length/

Sitecore Roles PaaS Solr Connectivity

Here's a quick one for everyone.  I recently provisioned a full Sitecore XP 9.0.1 environment in Azure PaaS.  The only exception to this is a VM that is running Solr.  I was getting a lot of errors in Application Insights about xConnect not being able to connect to the Solr server.  I suspected that I was missing a hybrid connection somewhere, but wasn't sure which role was missing it.

I couldn't find a list from Sitecore's documentation of all the roles that need to access Solr.  I know that I could look for the "ContentSearch.Solr.ServiceBaseAddress" setting to find all references to my Solr server, so I downloaded all the config files from each Sitecore role and found the one I was missing (xConnect Search).  I added the hybrid connection to the Solr server to my xConnect Search App Service and was back to running with no exceptions again!

Note: The "ContentSearch.Solr.ServiceBaseAddress" setting was removed in Sitecore 9.0.2 and is now in the "solr.search" connection string.

For reference, here are the 5 roles that should be able to communicate with Solr:

• Content Management
• Content Delivery
• Processing
• Reporting
• xConnect Search

References:

Walkthrough - Install/Configure Solr: https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/walkthrough--setting-up-solr.html

Azure Hybrid Connections: https://docs.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections

Limit TreelistEx Selections to X Number of Items

I recently had a requirement to limit the content author's ability to select items.  In this case, they were only allowed to select two items.  I love using "TreeListEx" and therefore selected that field type.  I knew that I could set validation on fields and went about looking for the built-in validator that would limit the number of selections. . . I didn't find it.

While I was surprised to not find this validator, I thought that surely, someone else smarter than me had mentioned it on the interwebs; I was not disappointed.  A quick search yielded a StackOverflow post about it that cited a blog post.  In summary, apply a Regex value to the "Validation" field of your field. (Add a helpful "ValidationText" message while you're at it.)

I dutifully copied and pasted the Regex expression into my field and was a little surprised to see an error message while testing the validator:

Well, that didn't go as expected.  After a bit of Internet sleuthing on the error, I found that there might be a character (or "characters") in the string that needs to be escaped.  I simply changed "^({[^}]+}|?){0,2}$" to "^(\{[^}]+\}|\?){0,2}$" (included the escaping 'backslashes' before the curly brackets and question mark) and was on my way!

Update: And of course as I'm finalizing the research for this post, I see that Ben *actually* did solve this and it can be seen in the screenshot he included, but the Regex text in his post didn't include the escape characters

References:

Stack Overflow Post: https://sitecore.stackexchange.com/questions/1016/what-fieldtype-should-i-use-to-select-one-item-from-a-bucket
Ben Ramey's blog post cited in the SO post: http://www.benramey.com/2012/06/12/limit-selected-items-on-sitecore-multilist-field/

Sitecore CD Hardening via Release Deployments

Security hardening on your CD servers is an absolute must.  It should not be an afterthought and you should address it early so that you're not trying to cram it in just before go-live.

In the days before automated deployments, CD hardening would involve manually manipulating the IIS folder level permissions on each CD server in your environments. With automated deployments, we can make this much easier!

Which Sitecore Version are We Deploying?

Take note of which version of Sitecore you are working with.  Prior to Sitecore 8.2, Update 3, you are still limited to manipulating IIS folder level permissions.  You can also handle this with configuration, but that's outside the scope of this post.  With Sitecore 8.2, Update 3 and newer, we have the option of changing the forms authentication mode in order to secure the server.

Disable Forms Authentication

The simple way to disable access to your Sitecore interface is to change the authentication mode from "Forms" to "None" in your web.config:


Easy enough to do on each of your CD servers, right?  But we want to automate that with our deployments.

Azure Devops and Web.config Tranforms

Using a web.config transform, we can target the "authentication" node and change the value to "None." 

What about local development though? 

When developing locally, you can use the "Debug" solution configuration that lets the web.config use the "Forms" setting when developing locally. This is exactly how Sitecore ships out of the box.

Use the "Release" solution configuration to set a transform on that element to change it to a token value.  Note: This assumes you are using the "Release" configuration when building your solution in Azure Devops (was VSTS). 

Why a token value instead of just setting it to "None"? 

We are utilizing (mostly) clean deploys.  When deploying, we wipe the web root and install all of Sitecore and our custom code and configuration from scratch.  Additionally, we deploy the same set of files to every server.  Different values for the tokens are controlled via variables and variable groups in Azure Devops. We expect this token value to be replaced at the time the release is generated and deployed to our different environments.

Putting it Together

So, we have a Web.Release.config file in our solution that looks like this:


In Azure Devops, we have a Variable Group for our CM servers that has the same "#{AuthenticationMode}" token with a value of "Forms":

Additionally, in Azure Devops, we have another Variable Group for our CD servers that has the "#{AuthenticationMode}" token with a value of "None":

When the release is built, use the Replace Tokens task in your release definition to process all your config files and replace the tokens with values from your Azure Deveops Variables Library.

Summary

Security hardening is an important task that shouldn't be overlooked and shouldn't be pushed to the end of your development cycle.  Consider security early and keep yourself and your clients out of the news.

Additional Reading

Sitecore - Deny anonymous users access to a folder

Sitecore - Restrict access to the client

Visual Studio Marketplace - Replace Tokens Task