How migrating 650+ sites saved this major university time, money, and effort for years to come

Princeton Web Development Services (WDS) is a software and application service department within Princeton University’s Office of Information Technology. Princeton University is a four-year Ivy League university in Princeton, New Jersey. Founded in 1746, Princeton has a well-established reputation of academic excellence as the fourth-oldest institution of higher education in the United States. 

Princeton needed to migrate 650+ sites to their new Drupal 9 (D9) website platform.  Drupal is a content management system (CMS) for building digital experiences. Through our collaboration, we were able to efficiently and effectively migrate 651 websites that were in 3 different bundles of codebases. 

The migrated sites on the new platform have many advantages, including architectural improvements, consolidated branding, content presentation, and accuracy of data ported over. 

Thanks to templates, sites are now much easier to get up and running and the process is much more automated - ultimately saving WDS time, money, and many headaches. 

At a glance

The WDS team’s main focus is to provide support to Princeton University’s internal units - including departments, centres, and programs - so they can design and build websites with little to no development experience. This allocates more time and energy back to those teams, allowing them to focus on their specific departmental needs.  

WDS needed help migrating hundreds of sites to the D9 platform, which uses new architecture and design, before D7 reached its EOL. Along with the migration goals, Princeton also sought advanced theme support to enhance their brand and incorporate new features. To begin, we conducted a technical audit and discovery to lay the foundation for future development as well as for a migration to a platform that they can optimise, which will support their internal teams for years to come. 

Full-scale migration scripts to scale fully 

This was a massive and intricate migration. The 650+ sites that needed to be migrated and updated were composed of three different types of sites: Template, Scholar, and Custom. Their differences derive from which Drupal distribution they operate off of.  

Template Sites (also known as ‘Princeton Site Builder version 1’ sites): The group of sites that are using a Drupal multi-site installation, each of which have separate codebase repositories and different sets of modules and functionalities. 

Scholar Sites: The group of sites that are using the OpenScholar distribution specifically, sharing one database and a common set of modules or functionalities.  

Custom Sites: The group of sites that are completely independent; containing different codebases, databases, and/or functionalities.  

The process became even more convoluted when we had to reshape the group of Custom Sites to fit the platform that it was migrating to - each of which had varying capabilities. It would be ineffective (and, not to mention, foolish) to just transfer each type of site as it was in bulk. Rather, to maintain the site's reliability and functionality from one platform to the other, it was key that almost every Custom Site had its own unique migration script, because most wouldn’t be exactly reusable or translatable. 

We also proactively planned for the future - Princeton WDS needed support creating more automation processes to facilitate transferring content, branding, and layouts from an older version of a site to a newer one without so much manual overhead. This newfound capability will alleviate headaches, streamline internal efficiencies, and prepare them for whatever lies ahead. 

Drupal 7’s end of life was just the beginning. 

Complex scripts and huge amounts of migrations aside, there was also the pressure of D7’s impending EOL our teams needed to adhere to. At the time of our project, D7’s EOL was scheduled for November 2022 (now, the EOL date is postponed to January 5, 2025), which gave us approximately 11 months to perfectly execute hundreds of migrations, before they would become either cumbersome, obsolete, or both. 

It was a requirement that all sites remained functional from one stage of the migration to the other. Just because Princeton WDS was essentially creating new versions of their sites, didn’t mean they could simply close up shop until all of the migrations were complete; they have far too many stakeholders and site owners that depend on them and their services. WDS needed to ensure that migrations were done in batches and developments were continuously done in strategic, small releases, so that the impact of the migration and going live dates were as minimal as possible, helping them maintain their standard of reliability throughout the project.  

Even after sites were successfully migrated, some of the new versions required manual clean up and upgrades, which meant active involvement in post-migration work. As granular as our discovery and migration scripts were, it was unrealistic to expect to capture all gaps and platform differences for that many sites. So, it was necessary to manually go into some of the sites, to make sure everything was accurate, functional, and up to the calibre of the Princeton brand. 

A seamless partnership made all the difference. 

Considering its size, scale, and strict timeline, the project seemed to have all of the ingredients to be a challenge. Fortunately, because of WDS’ communication skills, bolstered by our teams’ collaborative, trusting relationship, this project was an undeniable success. 

As one of the solutions, Princeton implemented a multi-site approach - one codebase shared among their thousands of websites for consistent content sharing, organisation, and data integration. We accomplished this by leveraging Acquia’s Site Factory platform. The Site Factory solution offers a perfect balance of structure and flexibility: WDS can create sites with rigid branded features that suit the reputation of their institution while embedding them into flexible layouts and themes, depending on the site owners’ unique needs. 

Considering the level of accuracy and precision that the migration scripts required, creativity abounded. Our experts created independent and tailored migration plans based on the site type while taking into account the platform differences of where it was being migrated to. Our engineers strategically made the migration scripts as re-usable as possible to keep pace with the tight timeline while maintaining the sites’ functionality - so it wouldn’t disrupt WDS members from doing their jobs.  

By templatizing their site formats, WDS can easily get hundreds of sites up and running as well as efficiently release feature enhancements, bug fixes, and successfully deliver on future requests from internal teams for those sites that already exist. The ability to create these new sites and issue these improvements in more streamlined and strategic ways generates cost savings, automated workflows, and more time back to them, so they can continue to carry out their mission. 

In total, we were able to migrate 252 template sites within 6 months, 382 scholar sites within 3.5 months, and 17 custom sites within 3.5 months. And, just to make it a little more intense, certain situations arose during our project that required some of these sites to be migrated more quickly in sprints - so we did just that. 30 Template Sites and up to 100 Scholar Sites were successfully migrated in two weeks to pull off fast approaching deadlines. 

The relationship that made it work. 

Together, we were able to upgrade WDS’ technology to ensure seamless communication channels amidst the D7 EOL, as well as strengthen the branding of the sites by moving designs to the same themes. We helped them assess the technical risks and planned their migration to ultimately achieve success while paying careful consideration to budget, scope, and schedule. Looking towards their future scaling their capabilities, we supported them in identifying and documenting any gaps in functionality when moving from a site from one platform to another, so that future feature development is more informed. 

This project was predicated on our joint effort with the WDS team - while we were responsible for data migration and theme development, the WDS team did a fantastic job maintaining the platform and executing feature developments to cover any platform or functionality related gaps. 

WDS’ new technology and their knowledge of how to effectively leverage it is uniquely theirs. Both in congruence effectively support their internal departments, multiple stakeholders, and their university at large.