Migrating to new code base

Question

We have a prototype of substrate-based blockchain running with few nodes.

After some time running and testing we came up with new version of code-base, which consists of the same runtime, pallets and storage items but with some naming changes for both pallet crates and their storage.

So there are few questions I am interested in:

1. Is it possible to migrate from old code base to new one (which are basically two different repositories with different structure but with similar components) without loosing blocks history and storage data?
2. Would forkless upgrade via uploading new WASM binary work considering it was built from different code-base?

I already checked substrate documentation 1, 2 and didn't find similar problem. There is a storage migration article but the problem discovered there is not exactly what I am looking for. It is just about adding new field to pallet storage.

I know it's possible to transfer all storage between blockchains by dumping all the storage from one and then transfering into another via genesis file configuration. But it would also be nice to store blocks history with all executed transactions.

Answer 1

End of the day, you will need to do a storage migration with your OLD network to make it compatible with your new code. And depending on what you changed, it may not be easily doable.

You cannot just create a brand new client and expect your old blocks to exist, because your new client may not be compatible to import the old blocks.

Additionally, you cannot just change your pallets and expect the old genesis to work since the genesis is dependent on the specific storage items and structures from your original chain.

If you want to work with a whole new client and a whole new codebase, restarting your genesis makes the most sense to me. You can still migrate things like user accounts and balances over to your new chain, but you should assume that all previous history is lost.

If you want to keep the history, you need to start bringing your new changes incrementally into your old client, making sure that any client breaking changes are handled, for example using client_logic_1 from block 1 to N, and using client_logic_2 for block N and on.