Dynamically initializing Context and creating connection string for Web API
I am not familiar with Dapper, but my assumption is that the objectives of using it are similar to using any other data access framework. Just from looking at their GitHub page, it looks like a very nice tool.

Unfortunately, maintaining compatibility with old applications is the reality that enterprises have to deal with, so in concept, I don't think this is a terrible idea. I would suggest doing something to ensure you have good connectivity between your API and your databases, though. If your company uses QOS, and the MSSQL traffic is not prioritized, but HTTP is, then using a SOAP service at the data source might be a good idea, and then just forward the request to that service. Web API would also be good, but implementation is a little more complex. That may be okay, though, if you want to avoid the overhead of SOAP envelopes.

From an API perspective, I would not recommend using custom HTTP headers. Part of the goal of Web API is having a standards compliant HTTP endpoint. Although that does not exclude using custom headers, I think that it might be better to try and device a custom route for the legacy integration, in places where you do not need to integrate with the modern systems. An alternative approach, if the intent is to store the data twice, is to dependency inject both your EF context, and your legacy adapter, into the controller. When the legacy adapter can go away, you "just" remove it from your controller. That way, you can integrate it across all of your API, and provide as seamless an experience as possible for your consumers.

Good luck with your implementation. I'm working on resolving several legacy applications myself, and it seems to be tough work whenever I hear anyone mention it.