If database has Begin of the deletion `SQL_ASCII` or `MULE_INTERNAL` encoding (secondEnd of the deletion one Begin of the insertionof following encodings: `EUC_JIS_2004`, `LATIN10`, `MULE_INTERNAL`, `SQL_ASCII`, or `WIN874` (see [tableEnd of the insertion Begin of the deletion was found during non complete checkEnd of the deletion with Begin of the insertionencodings](https://www.postgresql.org/docs/current/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED), all that are allowed as server encoding and are not supporting `ICU`),End of the insertion Begin of the deletion different database encodings),End of the deletion migration to v15 fails when running migration to add [ICU collation for versions name](https://github.com/opf/openproject/blob/6566fd1c56b347bf92a08604451d19f77c362501/db/migrate/20240920152544_set_versions_name_collation.rb). We [suggest to use unicode (UTF-8)](https://github.com/opf/openproject/blob/dev/docs/installation-and-operations/configuration/database/README.md#:~:text=OPENPROJECT_DB_ENCODING), but don't require it.

We should give guidance to check database encoding if the migration fails and document what should be done to fix it. At least if database uses `SQL_ASCII` it **may** be safe to just change database encoding, but I'm not sure we should suggest it. Otherwise the safe way is to: dump the database, create new database with unicode encoding, restore to new database, test application with new database, replace old database with the new database. Documentation can be placed under `docs/installation-and-operations/misc/migration` or `docs/installation-and-operations/misc`.