You have made a list and checked it twice, and figured out what apps are naughty and nice. Now it is time to actually make the move from Servers to Services. The key to this final step is a well thought out migration (and fallback) plan.
A clean install is best
Unless you cannot re-install server applications properly or there is no plan to use the server for more than six months, do a clean install. The benefit of a clean slate install cannot be overstated when it comes to reliability and security. Older servers end up with thousands of unneeded random files and updates on them which do not belong in a new Azure cloud environment!
A clean install also gives you the opportunity to get all the applications installed and tested while keeping the local production servers running. As of this writing, Windows Server 2008 is supported in Azure, but not locally. If you have applications that will only work on Windows Server 2008 this is the only path to keep these applications running.
When you cannot get rid of local Active Directory
No matter how much you want to get rid of local Active Directory, sometimes it is simply not feasible. First, we would push back on this need and explore other alternatives to these applications or workflows, but for now let's assume it has to stay.
The first step is to build a clean Active Directory server on latest Windows release. This will ensure that you have a functioning AD controller in Azure that is not part of the migration and will allow applications to function properly for testing. Typically we setup a simple Site-to-Site VPN for connectivity and AD replication and once the migration is finished just turn it off.
Ideally the AD server is ONLY needed in the Azure cloud for legacy needs and you can proceed with decommissioning all the on-premise local AD controllers/servers once the migration is complete. If this is not the case, give us a call and we can figure out why this is. Typically we end up back at the fact the workstations are using the local AD controller for authentication….and this should be changed!
Remote Desktop Gateway to the rescue
Any client (workstation) installed application that talks to a server should be running on a Remote Desktop Server (know to many as a Terminal Server). Moving all the server applications to Azure and then having to support VPN connectivity from all the workstations is a support nightmare. The setup of a Remote Desktop Gateway for easy web-based connectivity (no VPN needed) to all these client applications will save your support team a lot of time.
Additionally, the management of software updates, remote connectivity, and backups also become centralized in the Azure cloud. A win-win for sure. Often the setup of the RDS environment goes hand-in-hand with your server migration and that makes sense.
Moving from Servers to Services is the best way to modernize and secure your business technology. Working with an experienced partner to plan and execute this as part of your overall Technology Roadmap will give you the highest return on investment, and least risk.