under DMUs cover

 Oracle Data Migration Assistant for Unicode  (DMU) is a nice tool to convert databases (but no CDB$ROOT, sorry) from any character set to unicode. 

It is a nice java tool which is described already, So I will focus more on the steps what's going on. 

DMU uses an internal package DBMS_DUMA_INTERNAL which just creates an interface to DUMA_LIB library. 

Beside that, in my simple testcase DMU used the undocumented function SYS_OP_CSCONV(<column>, <target characterset> [, <assumend source characterset>] ). Even it is not part of the SQL documentation, it can be found in the DMU documentation. 

To enambe DMU doing all it's magic, some events are set. In my case they were: 

ALTER SESSION SET EVENTS '22838 TRACE NAME CONTEXT LEVEL 1, FOREVER'
ALTER SESSION SET EVENTS '14533 TRACE NAME CONTEXT LEVEL 1, FOREVER'
ALTER SESSION SET EVENTS '14535 TRACE NAME CONTEXT LEVEL 1, FOREVER'
ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT LEVEL 1, FOREVER'

and at the end, another undocumented command is executed: 

ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8

The lastest (21) docu tells: 

CHARACTER SET, NATIONAL CHARACTER SET

You can no longer change the database character set or the national character set using the ALTER DATABASE statement. Refer to Oracle Database Globalization Support Guide for information on database character set migration.

Of course using any of these statements is totally unsupported (even others already used some parts to fix existing problems) it's woth to know SYS_OP_CSCONV() can be used in any case where "wrong" characters were inserted and need to be fixed. 

One last bit I stumbled across: it seems even DMU can not manipulate AUD$INIFIED:

---

There is one even less documented function: SYS_OP_CSCONVTEST. It also has 3 parameters, I just assume these are equal to those of SYS_OP_CSCONV. 
It returns a number, in my tests there were 3 possible results:

1	needs conversion
0	no conversion needed
-1	no conversion possible

Let's hope this is of any help.