Before you start reading the article: This is part three of a six-part blog series. If you already know the previous parts, feel free to read on below. Otherwise, let me briefly explain the structure.

Each blog post in the series builds on the last one. The practical examples refer to our fictional company Example Inc.. I described the structure of the company at the beginning of part 1.

Good. Now that you know the setting, let's get started! 😊

Part 3 – How to migrate your on-premises IT to the cloud step by step

Glad you joined in for part 3 of our big Cloud & Hybrid IT special. This time we take a look at the different ways you can migrate your on-premises IT to the cloud.

A cloud migration strategy is part of any solid business strategy. Before we look at a practical example - namely the migration of our demo company's intranet server from on premises to the cloud - I have a bit of theory for you.

If you want to go directly to the practical example, either click here, or scroll briefly over the theoretical content (maybe there is something exciting anyway 🥰).

Select the suitable migration method

For the actual migration, you need the right method. To take some of the complexity out of the whole topic, I'll briefly show you the different methods.

⚠️ Choosing a migration method for one specific use case does not mean that you will treat your entire infrastructure in the same way.

In practice, a lift and shift may be ideal for certain applications, while a full rebuild may make more sense for others. It depends on your individual situation and may differ in every company.

What you should also think about

Migration order

Which of your application areas are most suitable for migration to the cloud? 🤔 It's best to look at each of your systems and assess their suitability for a move to the cloud.

This will give you an overview that you can use to decide which systems to start your migration with. In practice, BI and CRM systems are quite suitable for migration, while ECM systems, for example, often require more complex preparation.

Multicloud

Be sure to think about a multicloud approach up front. By this I mean using multiple cloud and storage services in a heterogeneous architecture.

Spreading your infrastructure across multiple cloud hosting environments spreads your risk, gives you more flexibility and allows you to optimize performance. 📈

In addition, multiple cloud providers often enable you to meet your compliance and data protection requirements in the best possible way.

After the cloud migration is before the cloud-to-cloud migration

In the long run, your journey won't end with your chosen cloud provider. One in three companies with hybrid IT has already performed a cloud-to-cloud migration.

This is where the advantages of monitoring come into play. Monitoring won't make your cloud provider better, but it will help you measure its reliability and decide when it's a good time to switch.

That means: Keep your flexibility 🖖 and don't make your applications and infrastructure dependent on a particular cloud service. Another move is bound to come!

To consider how easy it is, let's look at the case of our Example Inc..

We are migrating our intranet server to the cloud

There are many reasons to move your infrastructure, or at least parts of it, to the cloud. It starts with cost optimization, higher security, and increasing flexibility up to better efficiency, because you can focus on your core business.

In our example, we are migrating our intranet application server to the cloud. For a long time, Example Inc. got along wonderfully with an on-premises intranet.

However, recently applications have started running slowly, and you can almost hear gears creaking each time a request is made. It's time to pick up speed again and host our intranet in the cloud.

The data is kept safe in the cloud, and access is exclusively via an internally reachable VPN. Another advantage is that we have virtually unlimited storage space in the cloud.

Now, let's migrate! This is how the configuration of our on-premises server in PRTG looks like at the moment:

As you can see, the current configuration is running on a physical Dell Server. Now, Example Inc. wants to move its intranet application to the cloud.

In our example, we use Amazon's computing capacity for this purpose. Their solution is called Amazon EC2, an acronym for Amazon Elastic Compute Cloud. You can read more about EC2 at the AWS website.

On our virtual machine in the AWS universe, we install the latest Windows OS with all the necessary updates. Next, we start the installation of our intranet application.

Finally, we move on to the migration of the data. From our on-prem system, we start a data export and import the data to our newly installed cloud-based intranet solution.

In PRTG, we then only need to add the new device and include the necessary sensors. We use the AWS EC2 sensor to monitor the virtual machine itself. For monitoring the application, we use sensors like the SSL Certificate sensor, HTTP sensors and more.

In the end, this is what it looks like in our PRTG Hosted Monitor:

If you compare the screenshots before and after, you will see that the monitoring has remained almost unchanged. Instead of the physical machine, we now monitor the AWS instance. Within the application server, the sensor types remain identical.

If you click on the AWS EC2 Sensor, it provides more information:

The AWS EC2 v2 sensor monitors the performance of an Elastic Compute Cloud (EC2) instance by reading its data from Amazon CloudWatch via the AWS API.

Migration without reinstallation

Assuming your device to be migrated is already a virtual VMware machine, you could even migrate directly to the cloud without reinstalling. Find out how this works with VMware here: VMware Docs - Migrate a Virtual Machine to Cloud

What happens to the old sensors?

That's entirely up to you! 🧐 You can either delete the sensors of the old on-prem device. Alternatively, you can pause the sensors (or the whole device) and keep the historical data of the sensors. This can make sense if you want to check on something later, need historical uptime data from devices or services, etc.

Summary

The migration of an application server was only one example of many. You can map this to virtually any use case. If you can move a device or an app to the cloud, the basic steps are always the same. Whether you migrate your existing installation (including OS) or reinstall the operating system and only port the application depends on your use case.

Most important is to identify the most suitable migration method. In some cases, you're simply moving an old machine to the cloud so it can live out the rest of its life there before it's shut down - here, ideally, you're doing lift and shift.

Other systems start their lifecycle in the cloud from scratch. Here you will probably choose a full rebuild. This costs the most time, but you can be sure that you start with a clean installed system.

To wrap up: 

✔️ We considered the important requirements of a cloud-based monitoring tool.
✔️ After that I showed you how to install Paessler PRTG Hosted Monitor to start monitoring right away.
✔️ Together we migrated a system from on-prem to the cloud and learned about different migration methods.
⏭️ In the next part, we swap the tie for the work gloves, and walk from the office to your OT area. 🧤

Coming up in the next part of our series, I will show that it is really easy to monitor your Industrial environment with Paessler PRTG. 🤩 We will dive back into our Example Inc. where we have an IPC system, an OPC UA environment, MQTT, and a Siemens S7 PLC running on our network.

Thanks for using this guide ❤️, and stay tuned and excited for our next article in the ultimate guide to monitor your cloud and hybrid IT infrastructure!