In an existing environment with Atlassian Confluence is installed, the likelihood of maintaining version updates as often as they should become available is generally unlikely. As these updates come to pass so does the diminishing possibility that an exported space from one installation may be imported into another installation. A case for importing spaces between installations would be for maintaining a development environment for this application to test prior to rolling out updates to the production environment.

One could argue that both environments should be the same version of the app, with the same or a subset of the same data to test prior to updating the development environment. While that is a valid argument, sometimes you just want to jump right into the newest application rather than create an upgrade path, as time doesn’t permit.

The Official Procedure

There is an official document provided by Atlassian on such a procedure titled, Restoring a Space. More specifically the section titled, Workaround for restoring spaces between major releases. The official documentation reads that ” … to import a space from an earlier major version, you can use a temporary Confluence installation to upgrade the space export to the right version number[.]”

What an impressive amount of effort required if this procedure is followed. However, I have a much simpler work-a-round that worked for me. While the major version is explained on the Atlassian site, it doesn’t become that obvious to me where, for example as the actual version numbers escape me, I was unable to import a backup from a version 4305 to 4517. In my mindset, that does not necessarily constitute a major version. Anyway, since in my case, the difference in versions wasn’t “considerably” different, I attempted a work-a-round.

The Unofficial Procedure

Here is the work-a-round after the generation of a compressed XML export of the desired space, which will generate a file with a name similar to XY-123456-78.xml.zip. For simplicity, “.xml.zip”.

• Extract the “.xml.zip” file into a folder.
• Edit the exportDescriptor.properties file.
• Repace the buildNumber value from the existing value to the value of the target installation. (ie. Change buildNumber=4094 to buildNumber=4517)
• Replace the original exportDescriptor.properties file with the modified exportDesciptor.properties file in the “.xml.zip” file.
• Attempt to import the “.xml.zip” file into the target Confluence install.
• Done.

While this procedural worked for me, as there are any number of variables that could have made this fail, it may not work for your specific configuration. The risk is minimal and if time is part of the equation, and the possibility that this could work, it may be worth the attempt. Good luck.