My first thought is actually that the team as a whole needs a plan. Also, not all changes are equal. Consider these two scenarios:
1) A team going from jQuery to vanilla JS is a quite direct translation, basically just syntax with no big conceptual leaps. There will be a minor productivity hit while they change over, but that's about it.
2) A team going from jQuery to React+Flow is not a direct translation. They are now learning SPA-style state management and a static type system, as well as all the syntax changes. They are also probably learning a bunch of ecosystem stuff like webpack, Jest, etc. They will need a lot more training before they can get back to their usual productivity.
The team in scenario (2) is basically learning a whole new coding paradigm. That's pretty big.
Regardless, these sorts of changes are more human than technical. Change Management is important. You have to look at....
On the individual level - most frameworks have an intro tutorial. It's good for everyone to do the same one so they can help each other out; and later on help new starters if required. That step is the starting point to cover basics around the new tech, learn syntax basics and so on. You don't want people doing that in production code bases.
After that it's good if you have leads who can guide people through the architecture they're putting in place, so people can do further training in the absolute specifics. For example a React project might choose Flow, Typescript or just stick with vanilla ES6 - doesn't matter what you pick, the team needs to know what the conventions and expectations are.
From that point people will probably want to move into real work tasks, with some extra time allowed to get used to the new way. The finer details depend heavily on the people involved, their experience levels and how they learn.