Last January, I began a “To Drupal or not to Drupal…” thread on my blog because the organization I’ve worked for over twenty years decided to build a Digital Experience Platform (DXP). One goal for the DXP was to move all the organization’s websites to a unified CMS. Sitecore was selected for the unified CMS. The decision to move to Sitecore was not in my control. At the same time, I have to respect the leadership of my organization’s decisions and appreciate their willingness to invest and train their technologists on Sitecore. I chose to keep an open mind about Sitecore and gradually form an educated opinion about the product.

After spending a half year working with Sitecore, my opinion is that Sitecore is a proprietary product with some clear vendor lock-in and expenses. At the same time, every Sitecore expert, also known as an MVP, was a top-notch developer that values and contributes back to Sitecore’s community. From a technology perspective, Sitecore is “flexible” where you could, in theory, change anything with a high level of the application’s knowledge. Still, compared to Drupal, there are not a lot of supported extensions to Sitecore.

Sitecore’s out-of-the-box experience, especially around installing it, was a struggle for everyone at my organization. Sitecore’s example website only demonstrated some fundamental functionality. I can’t give enough praise about Drupal’s Umami demo profile, which shows all the latest and greatest Drupal features. Using a proprietary closed source system did feel like I was using a “black box,” where debugging unexplainable errors felt almost impossible to resolve.

Another challenge my organization struggled with is finding Sitecore expertise. Sitecore has a steep learning curve that feels similar to Drupal. Drupal has a much larger community of developers, which makes it inherently easier to find developers. In planning to support one of the Sitecore websites going live, I had to point out that we needed to assume that the website would have issues and possibly even a show-stopping problem. Like Drupal, I would not launch a Drupal or Sitecore website without some experts on call to help troubleshoot any unexpected problems.

As time went on, the challenges with Sitecore started to add up. Gradually a few developers began to express that moving existing websites and applications, including Drupal, to Sitecore was going to at the very least initially be a step back in terms of productivity and available functionality.

After a recent shift in leadership and introspection by several technical architects, leads, and managers, my organization decided not to move from Drupal to Sitecore. There is now an exploration to possibly leverage Drupal more within the organization. It is unique that people at my organization could listen collaboratively, pause, and rethink such an impactful decision and change direction.

Backing out of the decision and investment in Sitecore was not the outcome I expected; at the same time, I am glad I stayed committed to my organization. This direction reversal is a nice win for the Drupal community and me.

Now, it is time for me to get back to work and focus on Drupal. The most significant “win” for me is now being able to help train other developers at my organization to learn Drupal and become members of Drupal’s growing community.

There are many lessons I have learned from this experience, including what makes Drupal so unique. All the challenges I have discussed around the sustainability of the Webform module and Drupal still apply. Discussing why I love Drupal and how to make Drupal more sustainable can be the subject for a few future posts.

For now, thank you for listening and for your continued support.