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.

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.

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.

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.

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.

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.

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.

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.