You have an existing service on a two hundred thread pool that spends most of its time waiting on downstream calls. Would you move it to virtual threads, and how?

Yes, if the work is blocking I/O rather than CPU bound. Switch the server and any task executors to a virtual thread per task executor, then remove the assumptions the old pool provided: add explicit limits on downstream concurrency with semaphores or connection pools, audit synchronized blocks and native calls that can pin a carrier, and check thread local usage. Roll it out behind a flag and compare throughput and tail latency.

If the threads are mostly parked waiting on HTTP or database calls, yes, because two hundred threads is also two hundred concurrent requests, and everything else queues behind them. The change itself is small: run the web server on virtual threads and swap task executors for one that creates a virtual thread per task. The work is in what the pool was doing implicitly. It was a concurrency limit, so once it is gone I can suddenly have ten thousand requests all hitting a database with a fifty connection pool, and instead of a queue at the thread pool I get timeouts at the connection pool. So I put explicit limits back where they belong, usually a semaphore per downstream dependency sized deliberately. Then I audit for pinning, which is much less of an issue on recent versions since synchronized no longer pins, but native calls still do. I also check for thread locals holding anything large, because per thread caches that were fine across two hundred threads are not fine across a hundred thousand. Then I ramp traffic behind a flag and watch tail latency, not just throughput.