Migrating from a Legacy CMS to Enonic
Learn how the Norwegian Building Authority (DiBK) migrated from Optimizely to Enonic in this detailed case study.
Intro
The Norwegian Building Authority (DiBK) is a national competence centre in the building sector. Subordinate to the Ministry of Local Government and Regional Development, DiBK is a central authority in several areas within the building section of the Planning and Building Act.
The Authority’s two 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 Episerver (now 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 either update the existing solution or acquire a new one.
A public procurement process was initiated, starting with a mapping phase where needs and visions were identified. DiBK then issued a public tender in March 2022, with a pre-qualification round lasting two weeks to quickly weed out unqualified candidates.
After evaluating the many offers, a shortlist was created based on relevant criteria. The next step was negotiation rounds with relevant candidates during spring 2022. 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. The goal is not only to make regulations accessible but to simplify their use for all stakeholders.
Faced with an outdated version of Optimizely that was nearing the end of its support lifecycle, DiBK stood at a crossroads. Should they upgrade to a new version or transition to a completely new CMS?
The desire was for a future-proof CMS that could seamlessly integrate with in-house developed solutions and external APIs. This marked the start of a substantial migration project led by 99x.
Prior to the migration, DiBK had already laid the groundwork by completing a redesign project that established a new content model and structure. DiBK further outlined four primary goals for the migration:
- Efficient digital guide publishing
- Ability to flexibly test user-centered concepts
- Easy content and design adjustments by internal users
- Overall simpler, more efficient operations
The main legacy CMS challenges to overcome were:
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 process within DiBK’s specific setup required extensive manual work. The system had developed an extensive array of templates over time, potentially making it overwhelming for new editors and inefficient in general.
Complex Structural Solution
The legacy CMS solution was structurally cumbersome, leading to challenges in navigation and content management within the system.
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, including various MVC frameworks, .NET, and Web Forms, 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, adding to the operational challenges.
Lack of Future-Proofing
The existing setup lacked the necessary flexibility for future expansions, particularly in terms of easily integrating and managing new systems or components.
***
As for the implementation partner 99x, it was a central challenge to reimagine and reimplement DiBK’s external structure, content, and services exactly as they were (albeit better performing), but within the new Enonic environment.
Solution
The editorial team at DiBK was eager for a change. 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. The internal portal was also to be redesigned.
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:
- Go through the solution and map all fields and content types.
- Go through the top nodes in Optimizely’s content API, and decide which pages to include and not.
- Create services: a) Fetch assets, b) retrieve legacy content
- 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.
