Explanation

CPU and Memory (RAM)

The Confluence migrator tries its best to handle Confluence packages in a "streaming" fashion, never loading big things in memory. There should be enough RAM to hold the content of the longest document content, the list of page ids present in the package and the list of page titles present in the package. Following the standard sizing recommendations of an XWiki instance should be good, taking in account the fully migrated content.

Storage size

You need quite a lot of storage for importing confluence package. A rule of thumb would be to make sure you have at least 3 times the size of the confluence package you are importing available, but that really depends on what's in the Confluence package and whether it has a lot of attachments.

Here's a rough description of what happens when importing a Confluence package.

• First, the ZIP archive is extracted, if you import a zip package instead of an already extracted folder. This is going to be bigger than the archive size, but the difference is smaller if you have more / bigger attachments (because they are usually already compressed, while XML compresses quite well)
• Then, the entities.xml file present in the Confluence export is parsed and extracted into many individual files in the migrator's working directory, which is by default in XWiki's work folder. Depending on how it was installed, something like /var/lib/xwiki/data, or /opt/tomcat/webapps/xwiki/data, /var/lib/tomcat/webapps/xwiki/data. You can control where these files are extracted and whether to keep them using the working directory and the cleanup parameters. This can be useful if you want to allocate temporary storage space for this.
• These files are then browsed by spaces / pages / revisions and they are converted and added to the wiki in the database sequentially, including their attachments. This causes Solr to index those pages and attachments which of course requires storage on the server hosting the Solr instance (which is by default embedded in XWiki).

In summary, room is needed:

if using the zip file directly (as opposed to providing the unzipped folder):

• in XWiki's storage folder for attaching the attachment
• in XWiki's working folder for extracting the zip file

in any case:

• in XWiki's working folder for parsing and extracting the entities.xml (which you can manually set to a convenient location)
• in the database for storing the migrated pages
• wherever Solr store its index for indexing the migrated content

Note: in order to check the exact location of the temporary directory, you can run the following small piece of Groovy, in a page of your wiki:

{{groovy}}
println services.component.getInstance(org.xwiki.environment.Environment).getTemporaryDirectory().getCanonicalPath();
{{/groovy}}