For the application generally, I wouldn't anticipate many issues so long as you are familiar with the changes to make in the Clarity CSA configuration (changing J2EE vendor from generic to tomcat, and ensuring the Tomcat path where you extracted it to is correct, mainly, along with ensuring the details on the Application tab are correct for entry URLs and ports/protocols).
For the overall implementation, if you were using any services from Websphere itself to act as your loadbalancer then you would need to have an alternative plan/solution for that now.
Many other things such as the service to service communication in Clarity, and the fact that the beacon and bg services run as java apps outside of any J2EE containers (i.e. don't need tomcat or websphere existence or knowledge to operate), and that it's all the same code deployed and running and would continue to operate as usual.
In case it's not clear, it is possible to make the switch 'in place' without having to reinstall Clarity. When you're prompted at the beginning of the installer, it's only concerning itself with the expectations it should have in terms of how services are deployed and how they get stopped/started; it doesn't actually change what is installed or which J2EE platform it will work on. If it's not an in-place change though (you are also moving servers in the process) then normal migration techniques which may also include doing a fresh install of Clarity against a new database to begin with can still be included.