Sector(s)

Team Members

daniel_rempe, morenstrat, katzilla

Project Team

Daniel Braunschweig, Reinblau

Visit the site

Visit the site

Organizations Involved

Community contributions

https://www.drupal.org/project/caddy (no release yet - work in progress)

UNICUM.de is the online platform of the UNICUM magazine, targeting students and young adults. It offers content tailored to its audience and includes advertisement-based material. Alongside the conventional online magazine, there are additional sections: the Career Center, UNICUM Abi (targeting pupils), and UNICHECK (targeting students). Within the UNICUM Career Center, both employers and job seekers can register, creating profiles and entering their data. UNICHECK allows universities to independently manage and update their profiles.

Both the design and architecture have become outdated, which is why a relaunch was imminent. UNICUM operated on Drupal 7 within a multisite setup encompassing different domains (unicum.de, karriere.unicum.de, abi.unicum.de, and unicheck.unicum.de). The primary decision at hand involves either migrating the platform to a new CMS or upgrading to a current version of Drupal.

About the project

Phase 1 – All On Board

Project managers, editors, and decision-makers: In a two-part workshop, we first gather everyone involved in the relaunch. It becomes apparent that primarily the editorial team requires a new backend to work efficiently. Due to continual system expansions, the backend has become convoluted, requiring numerous manual steps to display desired results on the frontend.

Top Challenges for the Editorial Team:

  • Advertisement positioning works only through trial and error.
  • High loading times in media management cause delays.
  • The content interface with the Career Center is incomplete.
  • Additionally, improved interfaces between the individual domains are needed. In the UNICUM Career Center, both employers and job seekers can register to create profiles and input their data.

On UNICHECK, universities can create profiles and autonomously maintain their information. Both the editorial team and project leaders aim for a simplified management of the various platforms.

Ingredients for a Successful Migration:

  • Flexible architecture
  • Responsive design
  • More options for contemporary content creation
  • Single Sign-On
  • Registration Wall
  • Fresh design with dynamic content elements

Phase 2: Implementation

During the workshop phase, the current state was described, and the needs for a goal-oriented and efficient working environment on the platform were documented. The implementation phase is characterized by various decision-making stages.

Decision 1: Migration is the Path
In an initial step, the UNICUM team, together with our developers, decide to continue using Drupal as the CMS. The system is well-suited for complex, large web projects, such as the UNICUM universe with a fine grained role and permissions system.

Decision 2: Decoupled CMS for Multichanneling
UNICUM desires multidomain publishing capabilities and requires a content API for third-party marketing. Therefore, a decoupled CMS is chosen. Unlike a traditional CMS integrating content creation and display in one system, a decoupled CMS offers a separate content management experience. Contents can be presented across multiple platforms with different technologies and frameworks without requiring backend logic management. Since backend and frontend components are separate, they can also be scaled independently. Additional benefit: as the CMS and the publicly accessible website or app are separated, a decoupled CMS reduces the risk of security issues.

Decision 3: Incremental Migration
The team decides against a one-time migration of the entire system and opts for an incremental migration. Data is migrated from one system to another in smaller, manageable parts. In further migration steps, only the changes that have occurred since the last migration run are transferred. The incremental implementation occurs in sprints with customer involvement. This means the migration is largely automated. After each sprint, the editorial team has the opportunity to manually revise and test whether the desired (partial) results have been achieved. User-generated content is migrated after the cut-off date.

Phase 3: Fine-Tuning

Following the successful migration, the editorial team continues to be supported by the Reinblau team. Because as always, what's under the hood of the new system and where fine adjustments are needed become apparent only during the journey. However, right after the project's conclusion, the editors notice the difference: 

"We can now work faster because there are no more convoluted pathways. The backend is leaner and more organized."

Our Tech Stack:

Backend:

  • Drupal 10 (creates redirects via REST API directly in Caddy in the FE)

Frontend:

  • Caddy (as a web server)
  • PM2 (as a process manager)
  • Svelte (fetches content via REST API from Drupal 10) 

The gains achieved through the relaunch include

  • Enhanced templating for content
  • Greater flexibility while ensuring consistent presentation
  • Improved performance through Svelte-FE with prefetching
  • Elevated security standards via Decoupled-FE
  • Hybrid operation with Legacy-Drupal 7 (job board) and Drupal 10 (content area) made possible through the Decoupled approach
  • Improved integration and global control capabilities for advertising spaces

Why Drupal was chosen

For this project, Drupal was selected due to the previous website's operation on Drupal (7). In our initial workshop, it became apparent that the editorial team was content with the existing system; they simply required some interface modifications. Additionally, migrating from Drupal 7 to Drupal 9 seemed more feasible for us than transitioning to a different system, primarily because we had already executed several Drupal-to-Drupal migrations.

Technical Specifications

Drupal version: