Rijksportaal: migrating 9 Dutch ministries to 1 intranet

We migrated the intranets of 9 Dutch ministries to the centralized Rijksportaal intranet. Learn how we approached this website migration project and how our client has benefited.

The Dutch central government (Rijksoverheid) has created one single intranet portal called ‘Rijksportaal’ to replace a large number of departmental intranets. Rijksportaal is an efficiency-driven concept intended to promote interdepartmental cooperation and knowledge sharing.

Information Layers

It supports the idea of one centralized government. The information is presented to the users in a layered manner: government-wide content seen by anyone and targeted information based on user authentication. We have laid the content foundation.

 Rijksportaal

Starting Point

The first release of Rijksportaal was based on EasyWCM and SAP. We automatically migrated the content of the government-wide personnel department, as well as government-wide information around communications and operations. This content was the starting point of the government-wide information set.

New CMS

Fall 2010, a second release of Rijksportaal was delivered by the project team with a different content management system behind it: FirstSpirit. We have again automatically migrated the government-wide information to the new CMS. After this roll-out, the departments joined the new intranet one-by-one.

Full Involvement

We have been involved with all of the migrations. Some full-fledged automated solutions, some a mix of automated migrations and manual migrations. In the hybrid form, we prepublished a navigational structure, empty content pages, and metadata prepared together with an information architect, paving the way for an easy manual migration with the desired target structure already in place.

Net Migration Time

We have been working for the Dutch central government for 4 years and counting. Net migration time using our tooling is only a small percentage of the total time (approximately 50 days per ministry, sizes of up to 25,000 pages). Many hours have been spent on organizational, technical, and communication issues out of our reach, but necessary to tackle for a good outcome of the project.

Inventory

For each department that we migrated, we started by building a crawling tool to collect all of the content on the current intranet in an inventory. We extracted that information and compared it to the available target content structure.

Structural Mapping

The content pages to be migrated were placed into the target navigational structure in a mapping spreadsheet. An information architect helped the departments with this process. Using the mapping sheet, we imported the content in Setting Authorizations

One additional mapping sheet was needed where content authorizations were handled: both who could access the content in the CMS (the editorial model) and who was allowed to see the information in the front-end. We implemented this Impact

During the migration process, the impact of our work for the departments was mainly in testing the imported content and authorizations during the iterations. In general, the departmental editing teams have benefited from our approach. The large amounts of content, with heavy restructuring and authorization requirements, could not have been migrated successfully without our help.

Share this post on

Comments

Subscribe to email updates