Managing AUD$ without DBMS_AUDIT_MGMT
A), B) - You performed the same in the test environment, so you have an estimation of how long it takes. If it is short enough to do it during operation, go for it. If not, you can do it during a scheduled downtime. Typically users do not log in every second or so, sessions get created then they are reused by applications or connection pools. If you have frequent logins to the database, that is flawed design. Also, what is more important? The audit or the users being able to log in. You can temporary disable auditing.

C) - COMPRESS HIGH requires the Advanced Compression option to be licensed. If you have the necessary license, go for it. If not, then you will have some explaining to do.

Generally about audit: instead of moving the audit inside the database, you should be working on removing it from the database. Storing and handling audit data inside the source database is a pain in the ass. The amount of audit data stored inside the database should be kept as low as possible. You have 500 GB of unneeded data that is included in your backups, copied to clone databases. You should regularly archive then delete audit data from the database. In my opinion, instead of storing any audit data in the database, sending the audit data to a remote server through syslog is a much better solution.