Sure. There are quite some challenges there.
One big issue is the router. Only FlowRouter supports both Blaze and React equally. But it will force you to use Blaze / BlazeLayout as the leading template engine and wrap all React components in Blaze. This results in multiple React roots which is neither performant nor does it play well with global (Redux) state management. More on this here: Which Router are you using for a mixed Blaze and React app? I’d say the best option would be to migrate to ReactRouter completely. But this would mean a lot of refactoring (and thus additional work) in the Blaze code.
Another (smaller) issue is internationalisation.
tap:i18n doesn’t work with React, so I am using
universe:i18n instead and ended up with two different i18n solutions in one single app. It works, but won’t allow you to share i18n strings across both worlds. My apps are also based on a lot of (local) Atmosphere packages that are shared across multiple apps. Here I had to learn that in the most recent recent versions of Meteor (which you definitely want for React)
tap:i18n just doesn’t work anymore if you use it in a package that uses the
ecmascript package, too. So I had to refactor all my packages and put all i18n related stuff in separate packages that do not reference
ecmascript. Once you know this, it’s pretty easy to handle. But it took me some grey hairs to figure it out.
My conclusion is: The “soft migration” strategy MDG promotes in their guides doesn’t work well if your app is a bit more complex than just a simple demo. If I wouldn’t have a quite large code-base already, I would definitely try to go for React-only instead.