Hi @michal67 this is interesting!
I suspect that in the future, when your migration is more settled, you will want to relax the rules about out of order (OOO) execution.
One thing you might like to consider, rather than pinning the execution order (which you cannot do with shared runners) is to change the build number to rely on something like the date of the last commit. As you mentioned,
CI_PIPELINE_IID is an ID that is incremented on your project, every time a pipeline starts running, so if you allow OOO execution, you cannot rely on that for a build number, but you could possibly find something else. The full list of pre-defined variables might help you, if you want to try something like this.
If this situation is only temporary whilst you migrate, and you don’t mind a bit of a kludge, I would be tempted to keep the build number in a file that is committed to your repo. Then that first stage would read the file, increment the number, commit it back to the repo and pass to the next stage.