我正在启动一个新项目，我们希望将基于桌面的 Access 2016 应用程序（具有大量后端 VBA 和表之间的关系）迁移到本地 SharePoint 2016 中，并很快迁移到 SharePoint Online 中。据我所知，我们将获得 SharePoint 网站的网站权限，我们可以用它做任何我们想做的事情。我希望通过本地 SharePoint 2016 以及最终的 SharePoint Online 意味着有一个 SQL Server 以及最终的 Azure SQL 数据库，我可以迁移 Access 后端表和查询，因为我知道 SharePoint 列表不足以实现此目的，尽管SharePoint 列表是数据库表的等效替代品的错误观念。
我关心的是如何构建自定义表单、执行所需的业务逻辑、执行 CRUD 操作以及将 Excel 文件形式的数据从 SharePoint 站点上传到后端。
我是 SharePoint 新手，鉴于它不支持 VBA，微软今年早些时候取消了 Access Web Apps，并且他们正在逐步淘汰 SharePoint Designer 2013 和 InfoPath，过去一周的一些研究表明我的最佳选择正在构建使用 ASP.NET Core 自定义 Web 应用程序，并以某种方式将其部署到我们可以控制的 SharePoint 站点和子站点，或者开发大量 HTML、CSS 和 JS 来创建前端界面。我读过有关 Business Connectivity Service 的信息，用于从 SharePoint 站点前端和数据库后端获取数据或从 SharePoint 站点前端和数据库后端发布数据，以及使用 Javascript 和 AJAX 调用在数据库和前端之间执行 CRUD 操作。我研究了 PowerApps，这些似乎还不够，我仍在尝试区分 SharePoint Web 部件和 SharePoint 加载项。
以上任何一个都是可行的选择吗？有人可以提出更好的方法来解决这个问题吗？我需要什么技术才能最好地解决这个问题？
支持将表从 Access 移动到 SharePoint 仍然是一种选择和选项。
因此您的所有 VBA 代码等都将像以前一样工作。唯一真正的问题是您是否想将数据移动到 SharePoint 表而不是使用 SQL Server。
SQL Server 表比 SharePoint 表快得多。
但是，您当然可以考虑将表移至 SharePoint。当您将表移至 SharePoint（或 SQL Server）时，Access 代码、表单、报告等甚至您的 VBA 代码都将像以前一样工作。这意味着您将继续将 Access 应用程序部署到每个桌面。唯一的区别是现在您的表位于 SharePoint 或 SQL 服务器上。
上述选择不会产生基于 Web 的应用程序。
因此您可以移动数据，但您的应用程序仍将是桌面应用程序。
如果您希望构建基于 Web 的应用程序，那么 Access 是错误的工具 - 您需要采用 Visual Studio 之类的工具。
因此，您可以继续使用 Access，并将数据表放入云端或现场 SharePoint - 但应用程序仍将基于桌面。
在过去几年中我广泛使用了以下内容，我对这次经历感到满意：
是的，PowerApps 有缺点，但有很多现实的解决方法，并且会定期添加新功能/改进。
我还使用 SharePoint 列表作为数据源，但几乎总是迁移到 Azure SQL 数据库。