Don't do this.
Speaking as a developer, this sounds great. We get to rewrite that horrible old spaghetti code from scratch! We get to paid to learn a new language! There's a mandate for quality, so we can actually get the time needed to write good code!
...Oh, and there's the fact that this project will take a year or five. Speaking from a business perspective... not so great.
Of course, in reality, there's no way management will accept a realistic timeline for such a project. Instead, they'll insist on an unrealistic timeline. Put another way, they will insist (indirectly) on lowering quality. Which will end up with your developers spending a lot of time replacing legacy, presumably working spaghetti code with shiny, new, possibly not-working spaghetti code.
From your comment:
From what I understood was a decision made only from the perspective of choosing the most appropriate tools.
The 'most appropriate tools' are the tools used and understood by the majority of the Team. Adding a new tool to your toolbox is admirable... but it's a non-trivial undertaking. And, consequentially, it has a chance of failure (whether you define failure as time needed to learn or quality of code developed while learning, etc.)
Adding a new tool for the sake of expanding horizons: Good.
Adding a new tool as a dependency for an important project's success: Bad.
If you do really, truly have no choice but to rewrite an entire system in an entirely new language, then your best chance is to hire someone already experienced in that language. Or multiple someones. And you can't just point them at the problem and say 'go', either. Their job would be two-fold: to ensure quality of the product, and to disseminate their knowledge into the rest of the team.
Regardless, it'll be expensive and time-consuming.
Also, a part of the team would have to support the old application. Which are the best criteria to choose those? Personal option?
This seems to me like it should be a separate question, but I'll answer it here anyway. The best option is probably to do a rotation. If you rotate the people, then everyone gets some time to support/maintain the old application, so they all gain familiarity with it. If you don't rotate the people... then you'll likely have trouble keeping the ones stuck doing nonstop maintenance from quitting.