You can solve any computer programming problem with indirection, except too much indirection.
I think I can see your thinking here. You want to move to a new application which will be a client of the web service but you don't want to get any of the old dated ickyness of the web service on your nice new clean application. So you want to protect it by wrapping the old web service in REST.
This idea may be workable but it also may be tragically flawed. It really depends on how the SOAP web service is designed. REST is more than simply a protocol. It's a style of building a protocol. It may be that your SOAP web service is architected in a way that is incompatible with following that faithfully.
This nagging concern wont go away until you have this working no matter what I say so I'll show the best way to get this working. For now, forget that the SOAP web service exists.
Instead design the REST service around what you know the application will actually need. Follow all the best REST principles here and don't support anything that you might need. Only things regularly used today.
Now with that REST design that can support your applications needs ask yourself: can you map to your SOAP web service in a reasonable way? Adapting might be significant work. But if you can do it you'll have a well designed REST interface to support your application.
One of my favorite techniques is let use drive design. I'm applying it here as a way to let you evaluate how feasible this approach is for your case with minimal effort.
Sure performance may take a hit but never guess at how much. Measure how much with the simplest test you can. This approach lets you build that test before you rewrite the whole application.
You can even do a differential performance test that retrieves the same thing as the above REST test directly through SOAP. Now you can see exactly what your added overhead is costing you just by comparing times.
This may seem like a fair bit of work but it's work you would have had to do anyway. By putting it up front it lets you settle the issue before doubt about it seeps into the rest of your design.
To speed testing consider investing time with some client emulating tools that can drive these protocols: Postman, Insomnia, Curl...