Find where your application waits
A request may spend much of its lifetime waiting for an HTTP response or a query. Before changing concurrency models, record time spent on CPU, connection acquisition and downstream calls. Use that diagnosis to choose a representative experiment.
What virtual threads solve
Virtual threads support large numbers of concurrent tasks using a thread-based programming model. They are particularly useful for tasks that spend substantial time waiting on I/O. They do not make CPU operations execute faster or multiply system resources.
Your database still has a limit
More concurrent tasks do not create more connections or downstream capacity. Set an explicit limit for each scarce resource. A practical approach is to separate the number of tasks you can create from the number of simultaneous operations you allow against each external system.
Design the experiment
Compare the old and new behaviour under the same load and infrastructure limits. Observe latency, errors, CPU, memory and connection-pool waiting time. Include a slow dependency scenario. Decide in advance which results would justify the change.
Adopt deliberately
Begin with a bounded workflow that spends significant time waiting on I/O. Keep timeouts and concurrency limits visible in configuration. Review the documentation for your Java version and the libraries involved before extending the model across the application.