Migrate VM SQL Server Entities to Azure DevOps Source Control

ITBobbyP85

I have been tasked to migrate our existing SQL Server entities, Table Definitions, SQL Server Stored Procedures, etc. that reside on our VM Servers to Azure DevOps and Source Control. I have no idea where to start with this. I am aware and currently use Source Control and CI/CD for our existing AZURE Databases. But now our Director wants to migrate our VM SQL Server Entities to Azure DevOps and Source Control.

Can someone maybe provide me a YouTube or Web Site that walks you through how to migrate VM Server Entities to Azure DevOps Source Control? Is this even possible using SQL Source Control via SQL Server Management Studio?Our server entities on VM Servers will continue to reside there. We are just looking to Source Control the VM Server Entities to Azure DevOps Source Control.

These VM Server Entities DO NOT currently reside in TFS or any other Source Control. In one case, the VM Server Entities are from our 3rd Party application and Database that are typically controlled by our 3rd Party Vendor.

I am hoping that someone that maybe has migrated VM Server Entities to Azure DevOps for just Source Control.

Thanks for your review and am hopeful for a reply.

TheMaskedData

@ITBobbyP85 a thought on this - in general, objects on an Azure SQL Database and objects that exist on a SQL Server Database residing on a VM are, in many cases, exactly the same. Maybe with some slight syntax differences, but they're fundamentally database level objects (Tables, sprocs etc.) 

Therefore, they are considered in the same way by technologies such as SQL Source Control and Redgate Deploy and are equally fine to put into source control.

I would recommend reaching out to the Redgate team, possibly your Redgate account manager so that you can have a better conversation about this as their Solution Engineers are all too familiar with both approaches.

A lot of the video you'll see on the Redgate University site and YouTube etc. are actually using VM based SQL Server Databases anyway (apart from the ones that explicitly call out they're using PaaS alternatives or different RDBMS')