Stanford On and Off-Campus Learning Opportunities (SOLO) began in 2015 when Stanford’s Office of International affairs contacted us, Aten Design Group, with an exciting idea. They wanted to create a platform where Stanford staff and faculty could build custom forms to collect applications for academic opportunities. In just a few months we launched a lean proof-of-concept built on Drupal 7.
As that initial use-case gained traction with the Stanford staff (called Program Officers) collecting and evaluating student applications, requests for new features started rolling in. Integration with Stanford’s student records API, third-party review processes, the collection of letters of recommendation, and automated notifications were among the first.
Just a year after our initial launch the product team (now Stanford’s Research Information Technology & Innovation team, or RITI) realized the technology had wider applications. The fundamental feature set of SOLO could be repurposed for Stanford faculty to apply for research grants — a process similar to applying for academic opportunities with some minor but important differences. A few custom modules later, Stanford Seed Funding (SSF) was born.
As we continued to build and deploy new features for the two platforms on a regular development schedule, the number of opportunities offered to students and faculty increased. Thousands of users applied for around thirty distinct opportunities in 2017. The following year the number of opportunities quadrupled. Today, the two sites have managed nearly a thousand opportunities and seen upwards of 18,000 applicants.
Drupal 7 end-of-life: Decision time
That development track — as most of us are now familiar with — had a hard stop: Drupal 7 end-of-life. Early last year we started evaluating upgrade paths for Drupal 7. We had been building new features for SOLO and SSF non-stop for nearly six years in regular development cycles, and had accrued a pretty massive suite of features — and custom code. Aten Design Group had been building on Drupal 8/9 since their release, and at first that seemed like the natural transition to make. The time and effort necessary to make that jump, however, gave us pause.
Our first guesstimate placed a full Drupal 8/9 rebuild in the neighborhood of 4000 hours. Even if we grew our very lean project team (normally one to three members on the Aten side depending on needs) that amount of hours would take serious calendar time to get through. And that calendar time would mean pausing our ongoing development cycles and disrupting our engagement with an active user base that continued to request new features at a regular beat.
Drupal 7 extended support, on the other hand, wasn’t a great fit for our team’s ethos. We knew active support for Drupal 7 would continue to wind down, and we weren’t excited about a solution earmarked for cold storage. There’s an “I” in RITI for Innovation, after all.
Enter Backdrop CMS.
Backdrop CMS ticked a lot of boxes that appealed to our 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
Backdrop CMS is also nearly 100% backwards compatible with the Drupal 7 API and will be for years. For our highly specialized and prolific custom code that spelled refactor not rewrite, and implied massive potential savings.
To our team the decision was clear. In classic Agile fashion we did some (but not too much!) preliminary research and preparation, then, on the first of October last year, we dove into the upgrade process at full speed.
Live on Backdrop CMS: The upgrade
We ran into plenty of unforeseen issues and spent countless hours poring over code line-by-line in the pursuit of a stable Backdrop CMS version of our platforms. The process pitched us against seventeen not-yet-converted Drupal 7 contributed modules (including doozys like Stanford CAPx integration, SimpleSAML Auth, and Encrypt) and nearly thirty of our own custom modules. Speaking of which, both Aten and RITI are excited about contributing back what we can (we’ve already published preliminary versions of SendGrid Integration, SimpleSAML Authentication, and Authmap) — stay tuned for more on that front.
Stanford Seed Funding and Stanford On and Off-Campus Learning Opportunities launched on Backdrop CMS in January. The entire process took about 550 hours across three calendar months. That was more than we’d originally hoped, but we managed to tuck a move to Pantheon and a complete rewrite of our testing suites in Cypress into that budget as well. The platforms run some 50% faster than before (Pantheon and Backdrop CMS share the credit), and we’ve returned to our regular development cycle just a few short months after saying “yes” to Backdrop CMS.
Perhaps most impressively, our total cost was less than 20% of the cost to rebuild — that’s a big win in my book.
We’re super excited to switch our focus back to our platforms and our users, and very much looking forward to the future of Backdrop CMS, Stanford Seed Funding, and Stanford On and Off-Campus Learning Opportunities.