@TheGoldenEye solutions 1. and 2. suggested by @nazarhussain are not storing delegates secrets anywhere, it is just a decryption password that is being provided. Those 2 ways are not recommended due to security reasons, anyone with access to delegates machines could decrypt his secrets.
If a delegate is aware of that security risk but still chooses option 2., the decryption password can be changed anytime after a migration. A migration proceeds in a fully automated way using option 2..
The solution proposed by you gives delegates an option to include a newly introduced delegates section to an old config beforehand, leaving the responsibility of creating a proper structure up to a delegate. The only difference between Option 3:
> Convert secrets to encrypted passphrase before hand, during migration skip the secrets migration. After migration add the encrypted passphrase and restart the node.
is that after a migration node doesn’t have to be restarted. A delegate needs to enable his forging via API PUT call anyway. Nazar mentioned 3 options, there is more. A delegate willing to have his config.json prepared on his own might simply migrate installing Lisk Core v1.0.0 from builds or sources (https://lisk.io/documentation/lisk-core/upgrade) and enable forging via API PUT call just after migration happens.
I feel sceptcal about accepting this PR. Releasing version `1.0.0-rc.3` with a change untested during test migration (as its not a breaking change) puts the most important migration of 1.0.0 to Mainnet into unnecessary risk, while not introducing a functionality that wouldn’t be present now.