Upgrading confluence v4 to v5 vs migrating to SharePoint

Question

Which would be the less difficult process?
We've been on Confluence since v2 in 2007. We've migrated to v3 and v4. At some point Atlassian changed their schema, database collation to case sensitive and strings to unicode. The upgrade process to v5 falls on it's face when adding a new user_mapping table (expects nvarchar when linking to other tabled).  Changing database collation (drop all links and indexes, change collation, switch columns to nvarchar, rebuild all links and indexes) was attempted with unsupported tools but would leave the database in an unsupportable state.  Export to XML (in order to import to a database with new schema) misses a required file (https://jira.atlassian.com/browse/CONF-12206).  And then the import process fails "java.lang.OutOfMemoryError: GC overhead limit exceeded".  4 weeks burned so far and haven't even started testing plugins on Confluence 5.

Working with Atlassian support Reference: CSP-124664

Nic Brough -Adaptavist- · Answer

I think the trick for me was realising that the data export/import was independent of the exact storage settings.  So I could get the settings correct first and then get the data across.

Alex Mags · Answer

I think your solution of making a new confluence4 database and then importing the data from old confluence4 database is the way to go.  Instead of the Confluence database backup to XML process I'm trying SQL Server Management Studio's "Import Data" task to copy the data into a new database.

Nic Brough -Adaptavist- · Answer

We can't see your support issues, we're just end users of Atlassian stuff.

I thin the call about migrating to sharepoint is up to you, as you need to judge the effort involved in copying all the pages over and changing their format against the effort in fixing your Confluence database.

It sounds like you have a v4 database with unsupported settings, which the migration to v5 can't handle - is that a good summary?

I've run into much the same although it was on MySQL, not MS-SQL.  The fix in my case was to drop the new database completely, then recreate it according to the standard settings for a new fresh v5 installation.  Then I could take a standard backup of the v4 database and re-import it into the v5 one (of course, that means I've now got a v4 data set, and need to upgrade, but at least I have all the right database settings!).  The reason this works is the MySQL "dump" tool doesn't do anything that clever - it simply goes over every line in the database and generates a SQL statement that would create it in an empty database.  The underlying settings are irrelevant.  I don't know if you could do that with MS-SQL