Migrating your intranet at scale: 5 key insights you need to know

Have you ever migrated to a new application without actually knowing it? You logging in one day and all the information was there as you left it the previous day, everything seemed familiar, but when diving deeper you realise you are on a new application with a big upgrade in functionality. This was "the dream" for the Dutch Department of Home Affairs (Ministerie van Binnenlandse Zaken), for the migration to their new Social Intranet platform. Below, we share their story and also 5 key insights we gained, working on large migration projects.

Scroll to next section
hero c-hero__image

Have you ever migrated to a new application without actually knowing it? You logging in one day and all the information was there as you left it the previous day, everything seemed familiar, but when diving deeper you realise you are on a new application with a big upgrade in functionality. This was "the dream" for the Dutch Department of Home Affairs (Ministerie van Binnenlandse Zaken ), for the migration to their new Social Intranet platform.

On the surface, the project looks similar to the one we recently wrote a case study about, for the Custodial Institutions Agency (Dienst Justitiële Inrichtingen). Therefore this blog could be the shortest one we have ever written.

But you guessed it right. This migration had a few layers of added complexity associated with it that we would like to share with you.

The case

The Department of Home Affairs recently selected a new social intranet platform, Harmonics. Previously, they used another well known Dutch social intranet platform. Where this might appear as a straightforward data migration, given both platforms were built with the same purpose in mind (social intranet, information sharing, knowledge bank, collaboration), looks can be deceiving - figuratively speaking.

Just because two software applications share the same purpose and functionality, that doesn't mean under the hood data is stored and interacts with the application in the same way. To the contrary: there are so many options to orchestrate data and data flows within an application, that it is in fact highly unlikely this is the case.

Some background

Good for us, because this is where we can help. But before we delve into the detail, please allow us to remind you of the options available when needing to migrate data from one application to another:

  • A traditional or cloud based database to database connection
  • Export content from the source application and ask the vendor of the destination application to build a custom import process that can handle the way the content is structured
  • Use APIs to extract and deliver data For more detail, read our blog on the Custodial Institutions Agency case study here.

When the Department of Home Affairs selected Harmonics as their next social intranet platform, our partner Winkwaves teamed up with us for the associated data migration work as part of the Government tender process.

The challenge

Of course, we were pleased to assist with another large government data migration. From the Department of Home Affairs we understood one of the key objectives of this data migration was that there would be minimal (preferably no) impact to the user experience.

The reason for this was that usually any change to an application in any organisation is met with resistance by users. The Department of Home Affairs did not want to undo years of hard work of fostering engagement with their previous social intranet platform. They had identified that if users would migrate seamlessly to Harmonics, this would assist with keeping up the momentum of use of their social intranet environment.

In practice, this meant that the ‘look & feel’ for users post migration, should be as close as possible to the ‘look & feel’ prior to the migration. In other words, content that users had created over the past years should be available on the new platform where the user expects it to be, groups in which the users collaborated should be copied over, all document libraries should be readily available and any interactions users have had with each other should be there on the new platform. Bar a few improvements in functionality, which drove the migration to a new social intranet platform in the first place. So “the dream” was that on day one after the migration to Harmonics, users would log on and be able to continue their journey right where they left off the previous day, in the old platfrom.

No small challenge. But that’s just the way we like it.

The result

In a nutshell, a consistent and solid user experience is exactly what we achieved. Our migration approach played a pivotal role in creating a smooth transition from the previous platform to Harmonics. The first day, after logging on to the new system, users felt as if they were dealing with an upgraded version of the old system, rather than a wholesale application change where they had to start from scratch.

How did we manage to achieve this result? In part via our technical smarts in Harmonizer, but we would argue a bigger part is perseverance and creativity. There were roadblocks along the way - as in any data project. It would have been really easy to give up, or to define certain things as ‘out of our scope’. However doing this would likely either have led to a lesser migration result or, worst case, to an abandoned project.

The critical factors for success were the following:

  • In terms of technical smarts, using Harmonizer’s elaborate toolbox of flexible data transformations to migrate absolutely all content, including likes, comments, documents, internal links, tags, etcetera. All these content types were moved to the ideal location in Harmonics to facilitate an unchanged high quality user experience
  • Perseverance, creative problem solving and tenacity where there was no straightforward solution. As an example, the Application Programming Interface (API, or in layman's terms the facility used for data extraction in modern (cloud) applications) of the previous social intranet platform is currently in a Beta stage and therefore did not always have the ability to extract all data required for the migration. Using our knowledge of APIs, we found creative solutions for most gaps identified and enabled extraction of all data required to facilitate the desired user experience from day one.

Our client at the Department of Home Affairs was very appreciative of our efforts, to the point that they acknowledged that without these efforts the data migration would have been close to impossible. Or at least, would not have enabled meeting the objective of a seamless user transition from Harmonics.

The insights

Intuitively, we knew this already, however this project has generated the explicit insight for us that there is no guarantee that a data migration project will be successful - in spite of both applications having an open API. There are softer factors at play, and on top of a technically strong platform this is where we can really make a difference for our clients with our 'managed service' approach.

From a root cause standpoint, the following elements can get in the way of a successful data migration. These are the insights we wanted to share with you, so you can better prepare yourself for your next data migration:

  1. There is a gap between the conceptual specifications of the API and the way the specifications are implemented. Do a gap analysis before embarking on the data migration project to iron out any of these inconsistencies. E.g. does the API enable you to extract all required data, including all fields, history and possibly even archived information?
  2. API documentation is often not up to date or is incorrect. Actually test the API in-depth before commencing your project as well, so you know exactly what you can or cannot do.
  3. The migration should not be approached as a technical trick only, something a programmer can resolve on their own in any number of budgeted hours. There are often several ways the information can be migrated into the new platform. Therefore, one should involve power users and business analysts in the data migration project working group to ensure the end result is optimised for your users.
  4. There is a lack of (depth of) understanding of both applications. Make sure that application specialists are at the coalface of your migration.
  5. The API is not fit-for-purpose in its current state to handle the migration. API's are often designed and developed with a different purpose than data migration in mind. Include a fit-for-purpose analysis as part of your API document analysis and gap analysis outlined above. If need be, get the API enhanced or fixed before commencing your data migration project

As true API, integration and migration specialists, we aim to take a holistic approach to remediate all these risks for a data migration project, taking a managed services approach. Our standard service focusses on achieving "the dream" for our customers. It's the results that matter to us, not the set of technical procedures we agreed on paper. And we do not charge top dollar for it.

If our approach interests you, and you would like to know more, please book a free consultation here.

Scroll to top