Paul Schnackenburg walks through an implementation of public cloud computing for a small business IT infrastructure and shares what lessons were learned along the way.
My articles usually consist of looking at new and improved technology offerings from Microsoft and others, but this time I thought I'd cover something a little different.
In my role as a business owner and IT consultant, I get the opportunity to implement on-premises technologies (Windows Server and associated services), and cloud services such as Microsoft 365 and Azure for businesses. My business is a Microsoft Cloud Service Provider (CSP). Over the last few months I've been involved in a project where we migrated a small business IT infrastructure to Azure and as the migration nears its end, I thought I'd summarize the process and lessons learned along the way.
The Beginning Before Christmas last year a colleague invited me to the first meeting with the client, a small accountancy firm here in Australia -- let's call them Progress Accounting to protect the innocent.
They have just over 10 staff members in a main office, plus two smaller branch offices, and had five servers running in a VMware-based hosting environment in Brisbane (approximately 70 miles away) and Office 365 Business Premium for email and collaboration. Their current hosting company was changing its business model and had asked them to move their servers "somewhere else." There was pressure to do this as soon as possible from the hosting company, but an office relocation forced a few months delay. The hosting company had run Azure Migrate, which is a free service to assess current workloads and the suitability for moving them to Azure, along with specifying equivalent VM sizes in Azure and expected monthly costs. Figure 1 shows a screenshot of the report that we initially started with.
As we started digging we realized that there were only three VMs dedicated to our client and one of those was a Windows client running a line-of-business (LOB) application that they no longer needed access to.
Lesson 1: Always make sure you know exactly what each machine in the client's environment is for.
There was a shared Active Directory infrastructure that we would have to replicate -- either with one (or preferably two) AD domain controller VMs in Azure (an additional cost) or Azure Active Directory Domain Services (also an additional cost of about $ 110 per month).
After careful consideration and the realization that their LOB application and data was already protected with Multi-Factor Authentication (MFA), native to the application, we made the decision to use local Windows accounts.
Lesson 2: The current way of doing identity isn't always the best or only way forward.
This left two Windows Server 2016 servers that needed to be migrated, one that was running Citrix, which we were going to migrate from and convert to a Remote Desktop Services Host (RDSH). All the users were connecting to this server for their day-to-day activities and to a second Windows Server 2016 running SQL Server, which was supporting their LOB applications. There was also a shared file server, but we decided to migrate their file shares to the SQL Server, limiting the number of servers to manage and maintain.
The hosting company offered to do the migration over Christmas for free to speed up the process. We provided configuration details and access to the Azure subscription that we'd set up for the client. After some weeks of silence, we checked in on the progress and found that none had been made, ostensibly due to "lack of time."
Lesson 3: Don't rely on the previous IT provider to do the job right -- or do it at all.
