Azure Migrate | Keys for Migrating to the Cloud
Anyone in the IT sector has been reading articles for years predicting that the Cloud is the future. In Spain, 26% of companies currently use Cloud Computing services, while the European average is 36% and in some countries it already reaches 70%… (Eurostat, 2021). (Eurostat, 2021) Without going into comparisons between countries, what these results show is that Cloud Computing is not a technology of the future, it is a technology of the present. Not being in the Cloud today, or not having a plan for its adoption, is to delay the inevitable and most likely, to be losing business opportunities and process improvement (or in other words, money).
Infrastructure renewal
I think the readers of this article will agree that there is a lot of fear about making significant changes to the infrastructure. At the end of this year, Windows Server version 2022 will be released, which will allow us to leave behind the last version, 2019. With a year and a half to go before the end of support for the 2012 version, we find customers who are upgrading to this version, which implicitly leads us to admit that they are still using versions such as 2008 or 2003. We have even found some Windows Server in its 2000 version hidden in a Datacenter.
In other words, we already have professionals entering the market who were not even born when these latest versions were released.
Did you feel old reading these last lines? Relax, that’s not the issue; the truly old thing comparing the life cycle of the technology is the infrastructure.
But why does this happen? It is becoming easier and easier to upgrade operating system versions and doing so has many advantages in terms of security, stability, support… However, there are a number of problems. The biggest problem is that the workloads that are running on those servers are too old and currently it appears too expensive to upgrade them. It may be cheaper to develop an application from scratch than to upgrade from very obsolete versions of the Net Framework. But that application may fail someday, and depending on when it happens, it will be really complex to solve the problem that causes the failure and even if there are no professionals who can take care of it. What will be the cost of having that application down for a few hours or a few days?
Benefits of migrating to the cloud
I am aware that I have gone out of the main thread of the article, but it was necessary to give an example of how necessary it is to update our technology from time to time. And that is why many of the new functionalities developed by companies are born in the cloud, using some of the various technologies they offer, we can use containers, Databases, Datawarehouses, Web Apps … These new workloads can have some communication with older applications, which are still on servers in a Datacenter. Therefore, one of the motivations to take our servers to the Cloud is that they are close to the developed applications. Another motivation we may have is the cost savings of moving servers to the Cloud or simply scalability. But at this point, I think the advantages of migrating to the cloud are clear to all of us, so let’s keep moving forward.
Whatever the reasons for deciding to migrate a server to the cloud, it is necessary to find the best way to do it. And the good news is that it is really simple, but there are a number of factors to consider before jumping into migrating servers to any Cloud. With the experience gained at Plain Concepts after migrating more than 1500 servers to Azure as IaaS in various ‘Lift and Shift’ projects, and knowing that the big Cloud providers offer very similar solutions, I think the following points may be of great interest.
How to migrate to the cloud
Foundational Services
The first thing to keep in mind is what we know as Foundational Services, they are the foundations of Azure and like any other foundation if they are not well built from the beginning, we can have many problems in the future. The most basic of the foundational services is how we will organize the resources that we are going to upload.
Will we generate dedicated subscriptions for IaaS machines?
My recommendation would be to generate dedicated subscriptions for each development environment that we have, which will allow us to have a good organization, also taking into account the limit of role assignments per subscription in Azure is 2000 (Microsoft, 2021) If we mix types of resources and environments in the same subscription we may have a problem.
Organization of resources
Another important aspect is to structure the resource groups within each subscription (it is advisable to create rules for their creation). We must follow a strategy that may vary depending on who manages the machines, or some logical grouping that we inherit from On Premises. Whatever it is, it is best to define it before starting to deploy the resources that our machines will need.
Network topology
Finally, we must decide the network topology that we will use for our machines, the most common would be to use a Hub and Spoke or star topology. As it is not usual to migrate all the machines at the same time, we will place the Gateways in the network that will work as Hub, whether we are going to connect to On Premises by means of an ExpressRoute or a VPN connection. If we make this connection well, we will not need to place bastions or Firewalls in the Cloud at first, since all communications will continue to flow to On Premises, where we have our Proxies and Firewalls, Azure machines will not be accessible from the Internet and can only be accessed as we were exposing them before starting the migration, the Cloud will be nothing more than an extension of our networks.
Once we have all the infrastructure migrated and we want to get rid of the On premises datacenter, we can start to deploy the infrastructure that will provide security to the network. Finally, we must take into account certain Appliances such as Backup, if we migrate a machine and the Backup server is still in the Datacenter it will produce a lot of load on the network, it is best to generate another Backup service in the Cloud, either using the same technology or another of those offered by the Cloud to which we are going to migrate. The same would apply to Active Directories, DNS servers…
Azure Migrate Configuration
Azure cloud migration process
Now, once we have our subscriptions and networks configured, it is time to configure the necessary tools for the migrations to take place. Each Cloud has its own tool that offers migration services and even in the market offers third-party alternatives. In our case we have used both in the past Velostrata and today Azure Migrate, both tools use block migration, which assures us that no information is lost during migration. The machine that we will have in the Cloud will be an exact clone of the machine we had on On Premises, although it is true that when a machine starts in Azure the agent changes some parameters of the operating system registry, but do not affect the operability of the equipment. The only change that occurs on a machine when it is migrated is a change of IP, so we will always have to know if there is any static record in our DNS or any of the workloads running against the migrated server have static IPs that we will have to change.
Each company also has its own particularities and will have to develop its own particular migration flow, if we have DNS servers in the Cloud, we will want to change the records on the machine to point to those in the Cloud, and so on with the rest of the technologies we use.
It might seem that this whole process is a bit long and sometimes somewhat complex, but here comes all the complexity, once we have all the above points all that is left is to use the tool you have chosen for the migration and plan a day to upload as many servers as we want. The good part is that when using block migrations normally the downtime of a server is less than an hour, allowing us to maintain an SLA of 4 nines even having moved the server to another geographical area. And these processes are very repetitive, and can be automated in such a way that it is very easy to migrate as many servers as we want. Now you have no excuse to start taking your servers to the Cloud!
