From Drupal to HubSpot: Rebuilding paloaltou.edu with Peerless Components

Universities do not change platforms casually. A .edu site carries years of content, a long list of stakeholders, and editors who need to publish without filing a ticket. So when Palo Alto University moved to HubSpot CMS, the rebuild had to be fast to execute and boring to maintain. That is exactly what a component library is for: paloaltou.edu runs today on components from Peerless.

Why leave Drupal

Drupal earned its place in higher ed, but it comes with a treadmill: module updates, security patches, PHP hosting, and a development bottleneck between an editor wanting a change and the change going live. Moving to HubSpot CMS trades all of that for managed hosting and drag-and-drop editing that non-technical staff can actually use.

Components, not a theme install

This build took a different shape than sportspage.io, which extends Peerless as a child theme. For the university, Peerless served as a component library. Modules that fit came over directly, like the two-column media block and the footer. Pieces the university needed that no business theme ships, like an upcoming-events feed, were built new to the same conventions: BEM classes under the m- prefix, editable fields for every piece of content, and no baked-in margins, so spacing stays a page-level decision.

Same conventions, different brand

Because Peerless keeps its design tokens in CSS variables and its stylesheets in ITCSS layers, applying the university brand did not mean fighting the components' CSS. Tokens changed; components kept working. The result reads as a university site, not as a business theme wearing a costume.

Editors got the site back

The real outcome of the migration is organizational. On Drupal, layout changes belonged to developers. On HubSpot, pages are drag-and-drop areas assembled from those modules, so the people responsible for content own the layout too, without being able to break the design system underneath it.

Three sites, one system

Peerless now runs at three scales: its own site, a child theme powering a second production site, and a component library seeding a full .edu migration. That is the bet behind building it as a disciplined system instead of a one-off design, and it is the same workflow we bring to client builds.