Looking at the current picture of the ecosystem we see that some teams have had problems when performing runtime upgrades for their parachain, leading their network to a state where it can not produce blocks and being forced to go through relay governance or perform some original series of actions to be able to return to service.

We are aware that parachain builders are always cautious about performing all the necessary testing before executing runtime upgrades and migrations. However, we would like to provide the conversation with an argument that can help minimize downtime should any team find themselves in the unfortunate scenario where they are unable to produce blocks.

In this case nothing more than a simple suggestion that could be considered as a good practice when performing these upgrades until other measures are in place. We refer to removing the manager lock temporarily prior to the execution of the upgrade, and recovering that lock once the network is found to be stable after the execution of the upgrade. We keep in mind that this approach may cause the different communities to question the level of network centralization, however, we rely on the communication skills of the different teams as well as the communities to understand the current context.

The opportunity to use the extrinsics introduced in [polkadot#5451](https://github.com/paritytech/polkadot/pull/5451) can make a big difference in terms of the availability of a parachain in a scenario in which the parachain cannot produce blocks and therefore cannot send a message to the relaychain expressing the willingness to execute actions such as those included in the previous PR.

Considering the above, the enactment of a runtime upgrade would follow the following steps:

- Encode the call [`registrar.remove_lock(<paraId>)`](https://github.com/paritytech/polkadot/blob/894fef606a7a07ddb0ea3c2561145d21a53206c5/runtime/common/src/paras_registrar.rs#L337) in the relevant relaychain.
- Prepare an XCM in the parachain that includes a `Transact` instruction with the previously encoded call as payload.
- Execute the runtime upgrade following your usual method of doing so.
- Observe that the parachain is stable after X blocks following the upgrade or completion of the relevant migrations.
- The parachain manager should send the [`registrar.add_lock(<paraId>)`](https://github.com/paritytech/polkadot/blob/894fef606a7a07ddb0ea3c2561145d21a53206c5/runtime/common/src/paras_registrar.rs#L373) call directly in the relaychain to get back the lock it had previously.

> ⚠️ In the same way that we suggest this approach, we also have to notify you that today [there is a bug that affects the `registrar.schedule_code_upgrade`](https://github.com/paritytech/polkadot/issues/7202) extrinsic and until this is not solved it is not a safe extrinsic to use, since its execution will end up bricking the parachain.
This notice might also be of importance in case you are about to renew your slot.

Here an example performing these calls from the Rococo parachain `1836`:

- Encoded call `registrar.remove_lock(1836)` in Rococo: `0x46042c070000`.