我需要您的帮助来确定可供选择的最佳策略和技术，以继续开发成功的内部 VBA 应用程序。
在我们公司（基于网络的财务信息分销商），多年来，我们开发了一个 VBA XLA 插件应用程序，仅在我们公司内部使用，它有助于将我们的财务信息数据库与 Excel 工作表链接，通过使用几个 UDF，由 ADO/SQL 和其他业务对象逻辑支持。这个应用程序对我们来说是一个可靠、快速和有用的工具，有点类似于旧的 DDE 链接，但比这更复杂和灵活。
最近，我们用基于 SOAP 的 Web 服务和 XMLHTTP MSXML 6.0 技术替换了系统的 ADO/SQL 部分，真正将我们的数据库放到了云中。目标是将应用程序转变为可以在我们公司之外使用的产品。这项工作已经完成，它的表现非常好，具有所有功能、启动时加载、用户身份验证和会话控制登录/注销、与 EXCEL 的无缝集成、用户友好的消息，所有这些都在一个 2.036Kb XLA 插件中完成文件，跨越 15.000 多行良好的 VBA 代码。但是，我们觉得它还不能像现在这样分发......
我们认为，为了成功地作为产品发布给我们的客户，这个应用程序必须转换为编译代码而不是解释的 VBA。有很多理由证明这样做是合理的，包括安全性、速度、稳健性等。但我们现在不需要深入这些细节。
我们的第一个想法是使用 VB6 和自动化设计器将我们的 VBA 代码快速转换为 VB6 自动化插件。除了 VB6 是老技术之外，自动化插件似乎不是理想的解决方案，因为我们的应用程序需要与 Excel 事件和最终用户进行一些交互，至少在“登录”和“注销”期间基于 Web 服务的数据库（以及其他一些需要通过表单进行用户交互的功能），但似乎自动化插件不适合 UDF 以外的任何东西。在这里，我们想了解其他人在自动化插件和最终用户交互方面的经验。
因此，COM 插件是下一个选择。同样，这些允许通过菜单按钮和命令进行交互，但不允许在工作表中使用 UDF。或者我们已经读过。此外，我们已经读到 COM 插件可以作为自动化插件（毕竟允许 UDF），但它们将作为 Excel 环境中的两个独立实体（一个 COM 和一个插件），一半不与对方交流。这是我们不能接受的。同样，我们想更多地了解其他人在这方面的经验。
然后是托管代码（.NET、Interop 和 VSTO）作为其他可行的选项。然而，虽然上手简单，但 Interop 是否会继续存在尚不清楚，也不清楚托管代码的最佳策略是什么。同样，我们想了解其他人在这个领域的经验。
所以，最后的问题是：考虑到我们的要求（即启动时加载、通过基于 SOAP 的 Web 服务（MSXML 6.0）访问数据、UDF 的功能、登录/注销会话控制、用户友好的错误处理等），以及我们已经拥有 15.000 行良好的 VBA 代码这一事实，这是我们继续开发此 Excel 组件以使其成为易于安全分发的产品的最佳技术吗？非常欢迎这方面的所有评论和想法。