Existing intranet and wiki systems in all companies are filled with content. When it comes to launching a new Confluence system or a Confluence-based intranet such as Linchpin, many customers want their existing information to be transferred to the new environment and want a fool-proof and efficient migration strategy.

The ideal looks something like this: Set up and configure the software tool, then press a button - and a clean export and import of the data starts. After a while, everything is neatly in place in the new Confluence system, a successful migration. That's a very nice theory. Unfortunately, it cannot be put into practice.

As things stand, there are no automated migration solutions that deliver good results, even if you work iteratively, involve developers and repeat the data transfer several times. Countless pages will be broken, attachments won't be integrated correctly, the permissions differ from system to system - the sources of error are numerous and unresolvable. Briefly: In reality, it is impossible to migrate an intranet cleanly and successfully at the touch of a button.

There are alternative approaches. However, they all require effort, and unfortunately none of them can be had without a certain amount of pain.

Write off the contents in the legacy system and start afresh

This first suggestion is radical: Draw a line in the sand and start from scratch in the new system! No content is migrated. In the legacy instance, the light is turned off and people work from that point on in Confluence or their new Confluence-based intranet.

This should not cause any problems for the teams as they go about their day-to-day work. Preparation and debriefing meetings are done before the new system is integrated instead of at the end of an implementation project. You start with a lean, clean system, you can take advantage of the many possibilities offered by a Confluence intranet with its world-class editor right from the start, and your new system can grow organically to fit your current needs.

However, the drawbacks of this approach are obvious. Information that is constantly being referred to is suddenly no longer available - all the procedural information, software documentation, onboarding content, etc. Employees have to reassemble and document content (again) which is relevant to them in the long term. A lot of previously available information now has to be created and edited again. Information availability is ultimately temporarily impaired. From the user's point of view, this reduces relevance of the new system and the benefits of the new software when they compare it to the legacy system. This is quite dangerous for employee acceptance.

Manual import

A second option is to migrate the data manually. Perhaps you can recruit a few students as data processors for such a project, and after a briefing them about how to use the Confluence intranet, everything will go smoothly.

This is primarily a labour-intensive task: Someone copies each page individually from the old system into the new Confluence instance, repairing the structure if necessary, uploading attachments, checking links, assigning the right tags, etc. This migration team may even improve the content at this time to take advantage of the helpful additional functionality that Confluence offers out of the box.

The advantage: You will have all your content from the legacy system meticulously prepared and completely available in the new instance - possibly in a better condition than before. It takes time, but these results are as good as they can be.

Disadvantage 1: With several thousand or tens of thousands of pages, you need sufficient manpower which comes with additional costs. For many customers, outsourcing to external contractors will be a knock out criteria: not every organization will allow a handful of students to comb through all the internal company information. The intranet implementation team will have no choice but to recruit internal support for this hard work, and internal resources are scarce enough as it is.

Disadvantage 2: The new system contains a pile of garbage right from the start with all its negative consequences. When everything is copied, all the redundant, obsolete, and erroneous content is inherited from the legacy system - and the related efficiency problems: longer search durations, confusing search results, uncertainty about duplicate content when creating new content, ... These are not really favourable starting conditions.

Both instances operate in parallel

The strategy of running the new and old systems in parallel is a very organic alternative and establishes the conditions required for a smooth transition without any pressure. Employees are encouraged to work on the new platform, but the existing system remains fully available. There is no fixed date for the end of the old intranet. Meanwhile, the intranet team provides support for Confluence onboarding and manual migration for teams as needed.

After a generous period of time, the intranet team can check the usage statistics and see if anyone is still working on the old system. They make multiple announcements, so that even the stragglers (who will certainly be there) will know about the new system and will be able to help them migrate. Then the old intranet is switched off.

This approach is long term - and also the one that will cause some discomfort for some intranet teams. After all, it's possible that everything won't go as planned: employees simply continue to use the familiar system and ignore the new one. Or they don't use either of them at all. The intranet team will have trouble working out why they weren't successful.

Another obvious catch here is the cost aspect. Operating in parallel often means doubled license fees (and operating expenses) - in this case, perhaps even for several years. This is not easy to justify in many organizations. We have seen many projects where the money saved from the high legacy license costs were actually supposed to finance the new Confluence project.

Parallel operation with the legacy system in read-only mode

This strategy also relies on running both the old and new systems in parallel, albeit temporarily. If the legacy system or its permissions concept allows for such a thing, it can be useful to switch the instance to read-only mode. This way, people can access the legacy system, but they can no longer edit or add new information. Therefore they will start using the new Confluence-based intranet system or Confluence instance. If a team needs to update existing content, they simply transfer it to the new system and work with it there.

Here, too, the intranet team needs promote this transition. It might make sense to have a small editorial team that can help employees move content and prepare new content using Confluence onboarding resources.

The intranet team could also consider exerting some gentle pressure and frequently announcing the official shutdown date for the legacy system in the form of intranet news articles and community contributions in the intranet microblog:

"Dear colleagues, please remember: By 30 June you should have moved any information you still need and want to have to the new intranet system. If you have any questions or need help, please contact the intranet team."

Gradually, employees will take over the content relevant to their work by themselves. The information in the legacy system that has not been migrated organically in three to six months will eventually be lost. No one will miss it.

But here, too, the duplicate licensing and operating costs are a problem for the team.

Static export of the legacy system

The goal of this approach is to make the information from the existing system available in another way before you unplug it. For example, Confluence lets you export an entire instance to HTML format. Other systems probably also have options that allow a static export.

This gives you an exported snapshot that you can make available internally as a HTML website, for example, so that all content remains available. But as in the previous example, users can no longer edit this data or interact with the system.

Employees then can move the content they need and want to continue working on into the new system independently by themselves (with the support of the intranet team).

There is no pressure from deadlines and costs with this approach. However, many teams still shy away from adopting a self-directed approach and don't want to actively involve employees in the migration process. These strategies take time, there are at least temporary challenges, such as finding information efficiently, and ultimately internal resources will be tied doing editorial work.

All these approaches are trade-offs with advantages and disadvantages. There is no single best way and no clever solutions that let you simply push a button to migrate systems. Which way a company chooses depends strongly on the project framework, the requirements set on the new Confluence system and the degree of personal responsibility that the employees are granted.

While it might be effective in specific scenarios to turn the old system off and start from scratch, the risks and costs involved cannot be ignored. Manual migration is the more complex counterpart to automated migration: This achieves a complete and good result, but the new system will be filled out-of-date, erroneous or unnecessary content from the outset.

My recommendation: Let your employees do it themselves in a self-directed, practical process, where your intranet team actively supports them. The people who use the system every day know best what they need from the old system and what they don't need.

Your experienced Atlassian Confluence partner

Do you have questions about Atlassian Confluence or an intranet solution based on Confluence such as Linchpin? Are you thinking about implementing a new system or would you like to optimize or extend an existing system? We are Atlassian Platinum Solution Partners and would be happy to assist you with all aspects concerning a successful migration: licensing, customization, operation, support and custom development. Get in touch with us today!

Lesen Sie diese Seite auf Deutsch

Further information

Linchpin - the social intranet suite based on Confluence
Challenges of migrating a company wiki to Confluence and why it is worth overcoming them
How a social intranet can change enterprises
Harnessing employee initiative with the “deep intranet”