The export site functionality crashes the whole system and we're never going to move to a cloud solution.  

Honestly, this suggestion is 6 YEARS OLD!!! And we still don't have migration tool. So we are fighting with "value is bigger than 255 chars" and similar nonsense because Atlassian (which is positioning them self as Enterprise solutions) have HUGE tech dept in all fields.

For the same customer I used the Bitbucket DB migration from MS SQL Server to PostgreSQL. That worked really well. Please implement the same functionality for Confluence.

Is there any updates yet?

+1 ...even a preflight checker would help

"Is this DB dump valid?" "Does it make sense to export XML from this instance?"

Is this feature coming?

We are having hard time migrating from mysql to postgres: XML dump either cannot be created or restored.

Please pay attention to this request.

I was able to fix my issue by following this guide.

dkeller1 it seems like you affected by https://jira.atlassian.com/browse/CONFDEV-25424

Are you able to use postgres instead of mysql?

After tinkering with a small (6.1MB) embedded database XML export, trying to import it to a MySQL db failing again and again, I would weep with joy if there were a more robust database migration tool.

We were using the embedded database because we were testing the software and decided that we would move it to a production environment. Well, looks like that may not happen now, since we will lose all of our initial work. Does not instill much confidence.

Troubleshooting this error is not how I wanted to spend my day:
Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x99 C...' for column 'TITLE' at row 1

I am sitting here fighting with an antique version of Confluence 3.2 wondering exactly how I am going to upgrade to the latest version.

I have been trying to do this for 18 months - at each stage a problem is solved and a new one appears.

For example, if your confluence-data filesystem is damaged and you lost some attachment files, you will find that the XML dump will quite happily reference them from the database but that the restore/reindex will fail.

This is unforgivable - especially for a system that costs an awful lot. One of the purposes of a dump/restore cycle is to clean and validate what you are dumping - or at least to complain loudly at dump time if it really is broken.

I would expect the dump format to be unified and independent of the database internals so that there would be no issues dumping 3.2 and restoring direct to 5.1. At the moment it cannot even competently dump 3.2 and restore to 3.2! To quote a phrase I heard the other day, I detect a certain amount of plebbery in some of Atlassian's core design and implementation.

In my opinion this particular issue, whilst I agree with its sentiments, is the wrong approach. I would rather have a competent dump/restore feature which would make database migrations simple enough.