As anyone familiar with marketing technology would agree, change is constant. The footprint required of a typical digital marketer—from mobile to social to SEO to customer data and analytics—has been accelerating fast, let alone the shift to SaaS and new approaches for front-end design and performance. Scott Brinker calls this phenomenon Martec’s Law. A common approach to cope with the ever-churning treadmill is to reset your trajectory based on modern platforms and architectures and take into account the new expectations and realities.

As Brinker notes, many organizations choose to spin off business units or use cases, e.g., the mobile app, as a way of experimenting with the changes and minimizing risk during the transition. However, such a reset often involves examining the company’s digital experience platform (DXP) and determining if that platform is keeping pace with the changes required, a step that especially holds true for those clients running Sitecore XM/XP. More on that later. 

Even though Sitecore XM/XP has been a mainstay of content management at the mid-market and enterprise tiers for over a decade, Sitecore is currently caught in the Martec’s Law realities and in a world of major transition as the company attempts to reset by overhauling its whole identity and architecture. Instead of continuing as an on-prem DXP, Sitecore has shifted portions of its architecture to be more SaaS-like while paring back components that don’t perform core-content management functions and replacing them with acquisitions. Sitecore calls the resultant architecture “Composable DXP,” but the reality for existing customers is much more complicated.

Brands that are running the XM/XP legacy, which Sitecore calls Platform DXP, are effectively running on an architectural dead end. Since Sitecore has upgraded only portions of the platform to ASP.NET core, you are limited in how you deploy the solution, and your Sitecore team is generally working with the older .Net framework, including MVC.

Also, Sitecore has moved several products to maintenance mode without a path to newer offerings. Examples are Experience Commerce and the Experience Database (xDB) functionality of XP, which have been replaced by the Four51 and Boxever acquisitions. With no direct upgrade path, customers are left starting from scratch. If forced to replatform, many of them are considering other vendors.

On the technology side, Sitecore has, to its credit, prepared for the future by acquiring SaaS vendors, including Stylelabs for digital asset management (DAM) in 2018 and four vendors in 2021: Boxever for customer data, Four51 for commerce, Moosend for email, and Reflektion for search.

As for core content management, Sitecore has launched XM Cloud, which brings a more SaaS-like experience. Content delivery is replaced by cloud deployment and GraphQL, but without MVC support. The content-management app offers more features, enabling potentially faster initial setup even though still based on the XM legacy system, including the need for local developer instances and deployment for customization.

Nonetheless, Sitecore’s current offering is complex and expensive—basically an aggregation of vendors and technologies under the same company umbrella, but with little cohesion. For what that actually means for customers, see the excellent breakdown of the costs and challenges by our cofounder Adam Conn. 

Despite Sitecore’s efforts to segregate its customers into two personas, legacy DXP and composable DXP, the real picture is complicated because Sitecore also has a stripped-down headless offering built on the Stylelabs acquisition and rebranded as Sitecore Content Hub. Similarly, Sitecore is introducing functionality like Sitecore Components, an updated Sitecore Experience Accelerator (SXA) that’s a prescribed and proprietary approach for building front-end apps.

Despite a lot of talk around openness and collaboration with others in a larger composable, with the Sitecore CEO admitting that “in the past, the company acted as a ‘Sitecore Bulldozer’” and “We want to be a friendly neighbor,” those approaches are not reflected in Sitecore’s current product strategy and interoperability. Commerce, deployment, front-end framework choice, and search functions continue to be heavily coupled with Sitecore solutions or locked in OEM partnerships, where Sitecore maintains the relationship, limiting customers’ ability to select vendors based on needs, cost goals, and long-term architectural strategy.

Depending on how digital projects are handled within an organization, Uniform has published two informative guides that explain how to derisk migration and modernize processes:

However, Sitecore customers must ask additional questions of themselves, such as if the new Sitecore offerings are compelling enough in terms of cost or technology. After all, if you do enjoy working with your agency partner, who’s tied to Sitecore, it might make sense to continue doing that. But, if you are not happy with Sitecore, you can either continue with your current approach or choose one of two converging paths, as described below.

One of the first questions organizations often ask themselves is “Can we get away with doing nothing?” Nobody wants to undertake a new, costly project that, at least in the initial phases, just gets you out of the hole with nothing new to show. So, a common choice is to put your head in the sand and carry on with the XM/XP offering for as long as feasible.

However, that choice is unsustainable long term, especially if you are relying on significant improvements or new features. Eventually, the tech debt will be too big and you’ll have to mount a drastic reset that might be driven by factors outside your control, such as your development team or agency losing talent on older technologies, such as .Net framework or MVC, and platforms.

In the long run, you’ll face the fact that you have only two options of moving forward, as follows.

As covered in Brinker’s Martec’s Law, it’s often easier to spin out units or use cases and build from there, which is a common entry point for working with composable vendors.

Many organizations start with a microsite or mobile app as a way of testing new tools and approaches by adding content models and use cases and varying the approaches for delivery. That technique has a lot of appeal because it often means less risk. A downside is that it’s slower. That’s where a digital experience composition platform (DXCP) like Uniform can come into play by not only enabling the approaches but also rapidly connecting the underlying content and customer data sources.

The first step is to refactor the front end, which is usually what is holding you back the most. An  example is that the older platforms are on Java or .NET MVC while most modern development is through React or other JavaScript-based frameworks. The result is difficulty in recruiting skilled developers, keeping dependencies up-to-date, resolving security issues, and tackling the end-of-life phase of underlying frameworks.

With Uniform, you work with generic front-end components, such as our example Component Starter Kit, while mapping them to content sources, either legacy or newly migrated to other systems. Afterwards, you can change the back-end content sources any time without updating your front-end designs, and also migrate the back end on a case-by-case basis for any system or content. Three significant benefits emerge:

For customers moving from an existing DXP, Uniform offers numerous options. Our CDN, compatibility with various Sitecore versions and licenses, and decoupling of content delivery give teams all the tools they need to modernize at their pace.

Also, Uniform is built on open principles, giving you the freedom to choose from any underlying source of content or working with any front-end framework or channel. You can get started quickly; your marketing and creative teams can work together effectively; and you avoid vendor lock-in in the long run.

To find out how to get the most out of your DXP, schedule a free demo with us.