Drupal Association
This “Beyond the Build” conversation features George Perry (Exploratorium) and the Kanopi team discussing a multi-year modernization effort that moved one of the web’s oldest sites forward while preserving decades of content.
Who’s involved
- George Perry, Manager of the Online Media Group (part of the Media Studio dept.) at the Exploratorium.
- Kanopi team of Tim Tufts and Jim Birch, supporting strategy, architecture, design, and development.
Context: a truly historic website
- Exploratorium’s site was originally exploratorium.edu and they describe it as one of the first ~600 websites on the internet.
- The organization has tens of thousands of pages, many created across multiple eras (hand-coded HTML, older tools, then Drupal).
- A key theme: preserving a massive “online legacy” while making the platform maintainable.
Why Drupal for Exploratorium
George frames Drupal as a fit for their reality:
- Scale + complexity: tens of thousands of pages, many programs, and long-lived initiatives.
- Many editors + permissions: needs role-based, multi-editor publishing.
- Flexible data model: better suited than WordPress for their volume and content structure.
- Editor experience + SEO: they chose to keep Drupal as both content system and front-end (rather than headless React/Gatsby).
- Open-source alignment: strong preference for open source and contributing back.
The engagement: Drupal 7 → Drupal 8 plan, delivered on Drupal 9
Kanopi was initially brought in to:
- Create a blueprint + roadmap to move from Drupal 7 to Drupal 8 (at the time).
But by the time the work landed:
- The implementation ultimately moved to Drupal 9 (highlighting how fast platform timelines shifted during the project).
The migration approach: phased and pragmatic
They describe a Phase 1 / Phase 2 / Phase 3 strategy because the site was far beyond a simple “lift and shift.”
Notable details:
- Drupal 7 had 41 content types.
- Kanopi and Exploratorium simplified the model by consolidating many outwardly-similar types (exhibits, exhibitions, galleries, events, etc.) into a single umbrella concept: “Experiences.”
- Phase 1 focused on the Events / Calendar area first, since Exploratorium is a major in-person events destination, not just a content site.
The big challenge: complexity and “unknown unknowns”
A few recurring hurdles:
- Hundreds of microsites / folders and old static HTML sections.
- Long-tail legacy artifacts (“ping test page” type discoveries).
- Internal churn and gaps in deep Drupal knowledge on the client team early on.
- Stakeholder sprawl: marketing, fundraising, education teams, and high-profile projects (including NASA partnerships and an eclipse initiative).
George describes it as discovering “skeletons behind skeletons behind skeletons,” which is honestly the most accurate Drupal migration summary I’ve heard.
A clever launch tactic: split traffic across Drupal 7 and Drupal 9
To meet a critical deadline (the eclipse project):
- They launched part of the new Drupal 9 experience early using domain masking / routing so some traffic went to Drupal 9 while the rest still hit Drupal 7.
- This let them hit stakeholder timelines without delaying the broader site.
“Launch isn’t the end”: already planning Drupal 10
Even right after the Drupal 9 cutover (they mention 4/19 or 4/20), the next steps are in motion:
- Plan the Drupal 10 upgrade before Drupal 9 end-of-life pressure.
- Identify deprecated code and module readiness.
- Consider editor shifts like CKEditor 4 → CKEditor 5.
- Time it around organizational cycles like fundraising season.
What made the partnership work so well
This segment is basically a checklist of what good agency-client partnerships look like:
1) True collaboration
- Exploratorium developers took tickets alongside Kanopi so they could learn the system and retain ownership.
2) Transparency + steady cadence
- Weekly working sessions to prioritize, unblock, and handle “sticky” topics.
3) Capacity-building, not dependency
- George explicitly wanted a partner who would help them become stronger, not a team that just took requirements “over the fence.”
4) Root-cause mindset
- When they hit bugs in core/contrib, the posture wasn’t “patch it and move on,” but “can we fix this properly, maybe even contribute back?”
