Eric Toupin
Drupal 7 is wobbling towards end-of-life, with PHP 7.x close by its side. Webmasters, marketing and communications teams, and product owners everywhere are asking the same question: What’s next for my Drupal 7 platform?
Backdrop CMS is just one of a variety of upgrade paths for your Drupal 7 website — but in special cases it’s the right one. I’ll save you some skimming: Upgrading from Drupal 7 to Backdrop CMS is a good fit if you’re happy with your existing platform.
Why is that? The short answer is that Backdrop CMS is an upgrade-in-place for Drupal 7 that resolves end-of-life (EOL) concerns and facilitates further feature development. Importantly, it is dramatically more cost effective than the alternatives.
The long answer? A true story, below.
The setup: A software story
Stanford Seed Funding (SSF) and Stanford On and Off-Campus Learning Opportunities (SOLO) began in 2015 as an ambitious idea, an excited team, and a lean proof of concept built on Drupal 7. The platforms gained traction, picked up users, and grew. And they kept growing.
SOLO and SSF became complex and feature rich. They are now application workflow management platforms that organize and streamline a wide variety of communication, collaboration, and evaluation processes. The two websites facilitate the assessment of thousands of applicants each year for research, education, and funding opportunities that require diverse stakeholders to participate in multi-step evaluation processes.
Aten Design Group and Stanford’s Research Information Technology & Innovation team (RITI) have been actively expanding the two sites and introducing new suites of features for more than five years. The platforms serve nearly a dozen distinct audiences, generate longform PDFs from fielded and WYSIWYG content, serve up large datasets as dynamically generated Zip and CSV downloads, integrate with a variety of APIs, and deliver dozens of automated notifications that nudge application review processes along their various workflows.
SOLO and SSF are the result of more than sixty coding sprints and an equal number of structured planning and feedback cycles. The platforms utilize more than fifty contributed modules and more than thirty custom modules built-to-order for extremely specific stakeholder needs. They are living products that continue to release new features on a regular schedule, and still very much embody the product owner’s realized ambitions for the software. The unrealized ambitions for the software (the product backlog) is a manicured and prioritized list of features with realistic aspirations toward some future sprint.
The user base for the platforms is steadily growing, and the future of the software looks bright. But there is a problem: SOLO and SSF were built on Drupal 7. And we all know how that story ends.
The conflict: Heroes and villains
The villain of this story is time. Or more specifically it’s Drupal 7 and PHP 7.x EOL, both of which were threatening the continued success of the platforms. As Drupal 7 teetered towards end-of-life and with Drupal 8/9 stepping into the limelight, it was natural to assume active development (read community support) in the Drupal 7 space would slow way, way down. And while the Drupal community was making the leap to bigger, better versions, that same leap was a steep commitment for organizations whose primary concern was simply ensuring their software was secure and supported.
A further consideration: The SOLO and SSF platforms had not reached the end of a natural lifecycle. Both projects followed rapid development cycles closely tied to user feedback and stakeholder requests, and both platforms were in their prime in terms of features and user engagement, if not underlying technology. A rebuild would be expensive and time consuming, and would risk disrupting a successful development rhythm that regularly addressed evolving user needs via monthly coding sprints.
In light of these unique circumstances, a move to Drupal 8/9 didn’t feel right. While a development team spent thousands of hours rebuilding existing functionality the stakeholders’ wishlist of features would just keep growing — perhaps out of sight. Meanwhile, parking the software in Drupal 7 extended support felt like shopping for a cemetery plot. It would provide security, yes, but at the cost of saying “No” to community and innovation.
Enter Backdrop CMS.
Backdrop CMS flourishes a specific collection of features that appealed to the team:
- A direct upgrade path from Drupal 7
- PHP 8 compatible out of the box
- Considerable performance improvements compared to Drupal 7
- An active and innovative community with established leadership
- A software roadmap stretching years into the future
- Ships with upgrades: configuration management in code, an object oriented API, and more
Perhaps most importantly, Backdrop CMS is nearly 100% backwards compatible with the Drupal 7 API and will be for years. For our highly specialized and prolific custom code this spells refactor not rewrite.
The resolution: Drupal 7 to Backdrop CMS upgrade
In January we launched Stanford Seed Funding and Stanford On and Off-Campus Learning Opportunities on Backdrop CMS. All said and done, upgrading both platforms took about 550 hours across three calendar months. That was more than we’d originally hoped, but dramatically less than the 3500 - 4000 hours we informally estimated for a rebuild in Drupal 9. We ran into plenty of unforeseen issues while converting seventeen Drupal 7 modules into working Backdrop CMS versions, rebuilding thirty custom modules we had created specifically for SOLO and SSF, and refactoring our custom theme to work in the new ecosystem.
I personally spent six weeks poring over XDebug, combing through debug_backtrace() output, and Googling strange combinations of words related to whatever the problem of the day was. In the end, though, a few weeks is not half-bad to upgrade a codebase that resulted from five years of ongoing development.
The savings we accrued by opting for Backdrop CMS paid dividends. We took the opportunity to move SOLO and SSF to Pantheon (hello, structured development environment), and we completely rebuilt our automated testing suites in Cypress. Neither of those were light lifts, and both were a long time coming.
Today Stanford On and Off-Campus Learning Opportunities and Stanford Seed Funding are humming away on their new codebase and in their new hosting environment performing some 50% faster than before. Our automated tests — nearly twenty suites containing thousands of individual steps — run in ~20 minutes instead of an hour or so. Our total cost was less than 20% of the cost to rebuild. And about three square months after we set to work on the upgrade we were ready to continue our regular ongoing sprint cycles.
That’s a win in my book.
And where is all the Backdrop CMS code produced along the way? We’ve pushed preliminary versions of a couple of projects (SendGrid Integration, SimpleSAML Authentication, Authmap) and have another dozen or so in the works. Both Aten and RITI are excited about contributing back what we can — stay tuned for more on that front.
Curious to see what a Backdrop CMS upgrade option looks like for your site? Let's talk.