DiBK Migrated from a Legacy CMS to Enonic

The Norwegian Building Authority (DiBK) is a national competence centre in the building sector. The Authority’s main tasks are to 1) ensure safe, environmentally friendly, and accessible homes and buildings, and 2) help establish predictable rules for efficient resource use in the building process.

Having been an Optimizely customer for many years, DiBK was running on an old, outdated, and soon to be unsupported version of the content management system. With the prospect of being stuck with a solution lacking technical support, DiBK decided to acquire a new one.

A public procurement process was initiated and a public tender was issued in March 2022. After evaluating the many offers, the Norwegian system integrator agency 99x was chosen in June 2022, with an offer that included implementation of the Enonic platform.

Planning and work started during the summer and early autumn of 2022 before the new, migrated site for the Norwegian Building Authority was launched in February 2023.

Challenge

DiBK’s core tasks in their digital platform are to digitize building cases and provide guidance on building technical regulations. The regulations must therefore be digitally accessible and be able to integrate with other systems.

DiBK desired a future-proof CMS that could seamlessly integrate with in-house developed solutions and external APIs. This marked the start of a migration project led by 99x.

Migration Goals

1. Efficient digital guide publishing
2. Ability to flexibly test user-centered concepts
3. Easy content and design adjustments by internal users
4. Overall simpler, more efficient operations

Legacy CMS Challenges

• End of Support Lifecycle: DiBK's CMS version was nearing the end of its support. This required a change to ensure continued technical support and system security.
• Demanding Content Management Process: The content management was demanding. Many templates made it inefficient and overwhelming for new editors.
• Complex Structural Solution: The legacy CMS solution was structurally cumbersome, leading to challenges in navigation and content management.
• Extensive and Unclear Content Tree: DiBK faced difficulties with an overly extensive and unintuitive content tree, complicating the organization and retrieval of content.
• Slow Content Search Functionality: The search functionality within the CMS was slower than optimal, affecting the efficiency of finding and managing content.
• Mixed Technology Stack: DiBK's digital infrastructure was built on a mix of technologies, leading to compatibility issues with the newer versions of Optimizely.
• Long Loading Times: The older version of the CMS experienced longer loading times, which impacted the content management experience.
• High Cost of Template Development: Developing and maintaining custom templates on the outdated platform was both costly and time-consuming.
• Lack of Future-Proofing: The existing setup lacked the flexibility for future expansions, particularly in integrating and managing new systems or components.

Solution

The editorial team at DiBK was eager for changes. They were seeking a CMS that offered user-friendliness and efficiency in publishing guidelines and managing content, as well as flexibility in building custom pages.

Simultaneously, the new solution had to adhere to a headless architecture for future requirements. For DiBK, the Enonic solution from Seed’s proposal seemed flexible and intuitive, as well as cost-effective.

Migration: Step by Step

99x was faced with the task of migrating the old solution in a 1:1 relationship to a new solution, a process that involved manually mapping parts, macros, mixins, and content types. This meticulous approach was helped by the creation of Excel sheets for all required fields. 99x also developed plugins that enabled the extraction of content from Optimizely for import into Enonic.

The formal migration process was organized as follows:

1. Go through the solution and map all fields and content types.
2. Go through the top nodes in Optimizely’s content API, and decide which pages to include and not.
3. Create services: a) Fetch assets, b) retrieve legacy content
4. Import all images and files (content API included unique IDs linking media with objects)

Content Model

Instead of creating a new block for every new guideline or editorial need, DiBK can now have one block with several editing possibilities. For DiBK, the Enonic concepts of macros and parts enable greater flexibility to build pages as they want with various elements, instead of working in a fixed template. The migration thus enabled DiBK to reduce the number of templates by half.

Also, rather than having many content types, the content tree became more shallow—especially regarding TEK17 content. Now it’s easier for editors to insert new content.

Upon import, 99x thought it unnecessary to have separate content types at the lowest level of guidelines—like paragraph and clause. These were therefore combined in the final content structure.

Everything imported from the content API was stored in an x-data field, like ID and IDs of sub-objects. This data was used to merge content items in the initial import.

Content Types

One of the most common content types for DiBK is the “guideline” or “guidance,” which specifies regulations, advice, and processes for building projects. A DiBK guideline has several fields, one of which is an item set for creating multiple guidances. These can be inserted into the main rich text field through a macro that lists the guidances created within that specific content item.

The “best bet” content type is a part of a search functionality which had to be recreated in Enonic. Here certain keywords are given priority and promotion on the site’s search function. For instance, “best bet” is set up to always prioritize content from the TEK17 standard in search queries.

The “hearings” content type combines displaying on the front-end and linking to external sites in order to respond to a hearing.

“Smartere oppussing” (“Smarter renovation”) is a service with information about renovation. In this content type, DiBK can determine the coordinates where components should be placed on a house in the front-end.

Components

A central component in the new DiBK site is an integration with the service desk solution Pureservice. Editors can create forms in Pureservice through its advanced form definitions, while an API pushes out the specifications of the forms.

Layout and logic come from Pureservice’s own form builder, where the customer service set up logic and flow. In Enonic, editors can enrich the form, before it is rendered in the front-end.

Hearings from Hoering.no are integrated through an API from the Norwegian Directorate for Education and Training (UDIR). When a DiBK editor creates a hearing, there is a flow in Enonic where one can see status, responses, etc. in the front-end. This component has been used in other places as well.

“Boligdugnaden” (“the Housing Effort”) is a search service for housing refugees. It was quickly created by 99x, and its success was even mentioned by mainstream media.

Admin Tools and Widgets

DiBK has made use of the Nynorsk translator app by 99x. In Norway, there is a requirement that public sector sites must have at least 25% of its language in Nynorsk, something this app made easier.

The app and widget is powered by Totaltekst through an API, and can translate manually or automatically directly in Content Studio. Editors can translate a content node, including text used in layouts and parts with one click.