As you may have seen there is no perfect solution. Despite it all being HL7, the problem space is actually really wide.
A good start may be the open source HAPI Java HL7 v2 libraries, and the HAPI FHIR Java libraries. There are also .net equivalents. These are code level solutions. So you have to do the “mapping” yourself. However there is no escaping that, because any HL7 V2 you find is likely to have local customisation, so there is no out of the box mapping possible. The effort to create the mechanics of conversion is often not that great, compared to effort of understanding what data you have in front of you, including code mappings.
There are commercial “integration engines” that can do this, but not completely automatically. I won’t list them here, you can google them. They may make the mapping mechanics, and things like pipelines, scalability etc easier, but are expensive (except free ones such as Mirth - however nothing is really free). And you still have you own local data discovery issues.
To be honest, most people are not converting V2 (or V3) data directly to FHIR, although you might expect that to be very common. If an existing interface works people tend to leave it, or create new in parallel. And even if they rip and replace, they probably don’t convert the messages - which are meant to be transient. Normally the raw messages get turned into records in some clinical system, where they can be exported from, e.g. into CSV/XML/Excel which are then easier to turn into FHIR. So you can sometimes leverage the fact the the messaging systems understand their own flavour(s) of V2 and can turn it into something “standard” for that system e.g. a set of exportable SQL data.
There are not many good HL7 V3 tools out there, but it’s XML, so you can just code against it. CDA is a special case, more widely adopted (apart from in the UK, where we have a few large volume V3 systems), so there are some libraries for it, MDHT etc, and mappings for CCDA as part of CDA-on-FHIR.
Yet another issue is the mismatch between messaging and REST/database type data. V2 messages are snapshots that build up a picture over time e.g. test started, intermediate result, final result. You would want to turn that into a lab result in FHIR and not keep all the intermediate states (probably). You could do FHIR messaging as a more direct conversion, but that would achieve little.
So yes, it’s a wide area But for any specific case it’s not that hard to just “write the code”. It’s just that generic solutions are not always practical because there is no generic problem.