We don't know why it has a non rotating password!

One of the challenges of accounts that are inherited by an owner is that they may have no knowledge as to why the account has a non rotating password. There may also be long standing assumptions about constraints that require operation with a non rotating password. These assumptions should be challenged and fully understood before signing off on a non-rotating password. There may also be new technologies that now make it possible to rotate.

If there is no obvious reason for a non-rotating password, the owner may approve a move to rotating password with the proviso that the account is monitored for failures and there is a blackout plan in place (e.g. replace the old password).

This might be a reasonable approach for a non critical system, or where you have a decent maintenance window to implement a change. Where there are multiple, non-rotating accounts, you could consider testing on one account before attempting a change on all.

For a critical system you will almost certainly want to test password rotation works without any loss of service in a test environment. You will also want to fully understand the consequences of any failure. For example is this a customer facing system? How may users would be impacted?

It would also be useful to understand if a previous attempt was made to rotate the password and if there was any service impacting failure as a result of the change.

If you decide to test, you will of course have to set expectations around delivery dates. And if there is no environment or it is not in a fit state, or is not available for some time, you will have some work to do just to get to the point you can do a test.