We are certainly experienced in successfully synching up SQL databases with a variety of sources, but would like to to better understand the context here. I think while certainly a power app addresses two major functions, namely, providing a friendly interface for mapping data and for manually launching database synch processes using such maps, the more challenging part of the project involves things like below.

1. Is this a 'one time' migration? If so, it is best accomplished by dedicated SQL stored procedures in the sql Database with a Shared Service link to the Sage 100. Very little attention would be given to user interfaces or friendly user mapping tools such as afforded by a power apps

2. If this is a periodic bulk synchronization, ie, once a time, hour, month, etc. , does it require any user attention to execute it or should that be by schedule? Does it require user maintainable mapping tables? Have you looked at some of the third party tools for doing this?

3.Is the SQL data source well documented or understood? Is it custom? Is it local, hosted, or Azure/AWS. Is it very large?

4. Does the transfer involve synching up changes and deletes, operations that get exponentially harder to accommodate than appends or bulk replacements.

We would like to talk to you about your need. 

If SQL is on the same network as the Sage server, you might be able to use VI instead of any kind of external / custom programming.

If the data needs to bridge over the internet, something like InSynch might be worth considering (instead of developing something custom / in-house).

For a real-time interactive user interface using the O365 connector Sage has built (reference the Sage Contacts function), that would require an MS Power App... but I don't know of anyone actually doing this in production.  (I've only seen it demonstrated).

ScriptBasic uses ODBC and BOI with a traditional BASIC syntax. Open source and free.

See my profile for more info

I wonder if Sage 100 was open source and free would people stop using it?