User mapping while migrating Confluence spaces (export / import) - how?

Question

Hi community, I hope you can help me. I need to migrate several Confluence Spaces from Confluence Server 6.10.1 to another Confluence Server instance (version unknown yet, but not older than 6.10.1). The usernames (and certainly also the user IDs) will be different between source and target side. What is the best way to migrate the spaces and map the users correctly? We thought about soing search-and-replace in the exported XML before importing, but there are users referenced in a mixed way sometimes with their email addresses (which are the usernames on source instance) and sime kind of ID or hash.

Do I have to evaluate these objects like the above one, in order to find out the mapping between username and key, so I can replace all the keys accordingly in objects like the below one, where only keys are used?

If that's the case, is there any tool that can help with this task? Thank you! Daniel

Erik Anderson · Answer

Fast-forward a year and a bit. :) Scenario: * Server A and Server B both run Confluence, but have different user accounts. Users at Subsidiary A running Server A have accounts at Subsidiary B running Server B, but the credentials are different: Server A username "USERNAME@www.example.com" is implemented on Server B as "prefix_USERNAME". Steps: * Export space ABC from Server A to XML. * Import XML file into Server B. * Subsidiary A user logs into Server B using Server B credentials. Edits a page that they had previously edited on Server A. * Export space ABC from Server B to XML. * Examine the XML content. Poking around in the export file, you should be able to find XML structures like the following. These are, unfortunately, scattered throughout the file, so you might have to do some digging. Also, they probably won't be paired up nicely like this, so you'll have to use Search features.

Once you can find all of the ConfluenceUserImpl objects and correlate them based on USERNAME (or whatever key your company might have implemented), you can then go through and replace the GUID value for the old one (in the example above, the one for USERNAME@www.example.com) with the GUID for the new one (the one for prefix_USERNAME) in the XML file, and then import that back into Server B. Alternatively, it looks like it's possible for Confluence admins to fix this with moderate difficulty by tweaking the database, as described in How to change the creator of a page | Confluence | Atlassian Documentation, running queries like the following: update content set creator = (select user_key from user_mapping where lower_username = 'prefix_USERNAME') where creator = (select user_key from user_mapping where lower_username = 'USERNAME@www.example.com'); I hope this helps someone work through this, until such time as Atlassian gives us a better way forward.

Michael Mohr · Answer

Had you finally made progress on your space migration and mapping of users? Because we are now facing the same issue with a company the we purchased and for what we now want to consolidate their own Confluence spaces in our central confluence installation. But even that physically the users stay the same from the purchased company, their accounts are different in bot systems as the purchased company had attached their Confluence to their AD.

Erik Anderson · Answer

I have the same problem.

We have two Confluence servers (for various reasons I won't go into).

Users on Server A also have accounts on Server B.

We must sometimes migrate content (not the users, the content -- the Confluence spaces) from Server A to Server B.

* If content on Server A has page-level restrictions so that only certain users can edit, we can migrate that space to Server B -- but then the restricted page isn't editable by anyone, since the restrictions are based on users who are not defined on Server B.  Someone must manually remove the page-level restrictions, page-by-page, within Confluence on Server B.  This is tedious, time-consuming, and error-prone.

What we need is one of two things.

* Ideally, Atlassian would implement a means of mapping users from Server A to Server B.  This might be a dialog that pops up on import, prompting us to correlate each Server A user mentioned in the XML import with a user on Server B.
* Alternatively, and more simply, Atlassian would document the XML export format to explain where page-level restrictions are defined, how users are identified in the XML (some sort of GUID, presumably?), and some way of correlating those user identifiers with the user names in the UI, so that we could create our own script to alter the XML to suit our purposes.* I have combed through the XML export, and I cannot find either how page-level restrictions are defined, nor how users are identified.  Googling hasn't helped either.