Define storage migrations required to upgrade from Polkadot 1.1.0 to 1.6.0

[gianfra-t]

Context

As part of the master task of updating to Polkadot 1.6.0 (see tasks/#419) we need to identify which migrations need to be defined manually and added to the runtime before performing the upgrade.

Migrations that need to be specified manually are to be defined in the runtime as it was done here, where the migration functions are defined on the corresponding pallet.

Steps

Use the information here regarding storage version management of the pallets.

Ideally, the process should be:

• For each pallet:
  • Identify the current storage version, in polkadot-v1.1.0.
  • Identify the version that polkadot-v1.6.0 uses.
  • Check if the pallet defines a migration automatically or needs to be specified manually.
  • If it doesn't specify automatically, identify which migration functions must be called.

The migration code should be added to the modifications done for this issue and removed after the upgrade is enacted.

The results can be summarized in a Notion page analogous to this one.

Results

Migration analysis from 1.1.0 to 1.6.0 can be found here.

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @ebma @gianfra-t @TorstenStueber

[ebma]

@techies I'm done looking at the pallets, the results are here. To me it seems like we only need to configure two migrations, 1) a migration for cumulus_pallet_xcmp_queue and 2) a migration for pallet_identity.

[TorstenStueber]

Great overview. Okay, then let's go ahead to add these migrations. Are these automatic migrations or migrations we would need to define manually?

[ebma]

As far as I can tell both migrations are manual and require us to define them in the Executive type.