There are quite a few things to consider. For example, if the .NET app doesn't support data export, does it offer an API that can be called to get the data? If not, can you modify the app to call F&O, or to add an API or ability to export data?
If you decide to call an API of the app, will it be visible to F&O?
Will both the system run at the time of import/export? For example, keep in mind that they may be down for maintenance. What will happen if the they're not? Will you try the export later? Which system will be responsible for tracking it and trying again? It may be done by a middle-tier layer.
Regarding your last sentence, API is a much more generic concept than OData. API standard for Application Programming Interface and it's basically something that you can call by code. It may be something inside an application (such as a library used by your program) or something that allows communication between applications. It says nothing about how it's done - there are many possible ways. These days people often use the term API when they mean a specific type of APIs: web APIs (web services), or even web APIs using a particular architecture pattern (REST). It simplify communication if the context is clear, but it's a mistake to think that API means just RESTful web services.
OData is a standard for building one kind of RESTful web services.
Therefore the question about pros and cons of OData and API doesn't make sense. You can't use this or that - OData service is a particular type of API.
