Practical .NET

Moving to the Cloud: A Piecemeal Strategy

• By Peter Vogel
• 05/01/2018

I was teaching a course in cloud computing (with, of course, a focus on Azure) for Learning Tree International when I got The Question: "How should my organization migrate from our on-premises applications to cloud-based applications." I told them what I tell my clients and, now, what I'm telling you.

One warning: As you read through this, you'll see that I'm also trying to brainwash you. Moving to the cloud isn't a trivial task (though it's certainly doable). If you're going to take on this task, you can do it one of two ways: replicate your existing data center as a set of virtual machines in the cloud ... or embrace the cloud and make your applications truly cloud-based.

I'm voting for the second option because I think it's smarter to add a little more pain to the conversion process and end up with a genuine cloud-based solution (a "cloudier" solution). However, I can see the sense behind the "Let's just get to the cloud and start saving a ton of money" approach. If that's the way you want to go, I'm not here to judge you (<cough>wimping out</cough>).

If you are taking the "let's just get to the cloud" approach, the strategy I recommend is also designed around doing the easy stuff first. This lets you build up knowledge and experience, which you can use when you start tackling more complicated problems.

It's All About the Data
The obvious place to start is by moving your Web applications to the cloud. The reason people begin there is that is that it's stupidly simple to deploy a new ASP.NET application to Azure. That doesn't, unfortunately, mean it's simple to migrate an existing application to the cloud.

The reason it's hard to move your application is because of the data (among other things). So, while your application may move to the cloud, it won't do you any good unless that application can access your data. So I recommend ignoring your Web applications and move your data to the cloud first. In my experience, moving your data to the cloud will probably be the easiest step in your migration (note: I didn't say easy, I just said easiest). If you're using SQL Server as your database, you have multiple options for moving your data the cloud.

Data Alternatives
When picking among those options, the single biggest decision will be whether you're moving to Azure SQL (Microsoft's cloud database) or to a SQL Server database running on some VM you've created in the cloud. My personal feeling is that, if you're going to the cloud, stop thinking about servers and move to Azure SQL. In the long run, you'll want to move to a true cloud database server (that is, Azure SQL) because it will simplify your management tasks and reduce your costs. Since those are, after all, two of the main reasons you're moving to the cloud, it makes Azure SQL a compelling target for your migration.

However, I recognize you can simplify some of your conversion by (1) creating a VM in the cloud that duplicates your existing database server and then, (2) moving your data into that cloud-based database server. This process is even more attractive if you're already running your database server in a VM on some on-premises server: You can just copy your VM from your datacenter to the cloud.

Choosing to go to a VM instead of Azure SQL isn't an irrevocable decision: You can always make the conversion to Azure SQL later after you've picked up more real-life cloud knowledge and experience. I just think the extra cost of moving to a cloud-based data server is sufficiently small that it should be included in your first migration plan.

Once your data is moved, you can change the connection strings in your datacenter applications to point to your cloud-based database server and see what breaks. With ADO.NET and/or Entity Framework, it should be "nothing."

The reality is that you'll have a period where some applications are updating your on-premises data and some applications are updating your cloud data. To deal with that, you'll need to set up a data pump that moves data between the two sets of data. For that, you might want to look at Microsoft's SQL Data Sync (though it's still in preview as I write this).

Migrating Your First Application
You're now ready to pick one application to use as a migration pilot project. As I tell people in that Learning Tree course I mentioned at the start of this article, there are two primary criteria for picking that first application.

Getting the application to the cloud shouldn't be "mission critical." There are two reasons for this. First, you may not succeed in getting this application to the cloud. You don't want to crash your organization because you're new to the cloud. Second, even if the pilot application does get to the cloud, it will probably arrive later than you originally scheduled because you don't (yet) know what you're doing. You'll have enough problems moving to the cloud without the pressure of attempting to meet what turns out to be an unreasonable schedule.

It also shouldn't be a "toy" application. Again, there are two reasons here. First, if you're not moving an application that matters to your organization then it doesn't matter if you succeed. Second, you need an application that reflects the kind of application you'll be moving after you complete the pilot project. That implies a level of complexity similar to your other applications.

And, as that second criterion implies, you may need multiple pilot projects: one for each kind of application you'll be migrating.

Perversely, I suggest that your pilot project be a desktop application. I recommend that you gradually "hollow out" your desktop application by moving the non-UI related functionality to the cloud as into App Services. This allows you to make fine-grain decisions about what actually needs to be in the cloud, rather than the large-grain decision of "the whole darn application."

You can also more easily target the deployment of a desktop application than you can a Web-based application. If you inflict the cloud-based version of your desktop version on two users, you limit your damage to those two users. It's more difficult to limit the users of a Web-based application.

Adopting the Cloud
You also gain a lot of flexibility by creating services in the cloud from your desktop application. For example, once you've started creating services, you can decide whether you want those services to be accessed from other server-based applications, from JavaScript running in the client, or by third-party applications created by your business partners (vendors, customers and so on). It would be nice to think that you're providing some new value when you move to the cloud and not just recreating your server farm.

After you've gained some knowledge/experience/scars moving desktop functionality to the cloud, you can start thinking about moving your Web applications there. Again, I recommend "hollowing out" your Web applications by moving non-UI related functionality into services. As you work your way through your inventory of applications you may find that the application you're currently converting already has a service it needs in place, in the cloud.

And, of course, if you're already living in a service-oriented environment, ignore everything I've said and move your services first. The applications that use those services can follow them.

You'll also need to recognize that not all of an application's data is necessarily in your database. A Web application that, for example, saves uploaded files to the Web server may need to be rewritten to run in the cloud. This isn't a problem with your desktop application because you can leave the file-system part of the application on the desktop.

Here, again, you have alternatives: You can rewrite your code to use either Azure File storage (which looks more like the Windows file system) or Azure Blobs (which looks less like the Windows file system). Again, Blob storage is the cloudier solution so it's my recommendation. But this may be another point where you may prefer to simplify your conversion.

Eventually, you'll end up with some Web applications that have been completely hollowed out and are nothing but a UI. Those applications really are, in fact, trivially easy to move to the cloud, especially with the knowledge you've acquired migrating the earlier applications. Again, rather than moving them to a VM running IIS, I recommend to go "full cloud" and move them to App Services. By this point, you'll have a lot of experience with App Services thanks to creating services there.

Where You'll End Up
When pundits discuss cloud-based applications they often use some categorization scheme to organize the various kinds of cloud applications (for example, "private cloud," "public cloud" and so on). Every one of those categorization schemes includes a category called "Hybrid." I suspect that the reality is that most cloud solutions fall into the "Hybrid" category.

The reason is, as you move your applications to the cloud, you'll find that there are some applications that aren't worth moving (or even hollowing out). Even if there is some value in moving those applications they still won't be moved -- there will always be something more valuable for your organization to do.

In the end, these applications will be moved to the cloud ... but not because they provide any value by being there. They're moved because it's time to close your datacenter. Given these applications' low value, you'll migrate them with few (or no) changes. But, by the time you do those wholesale migrations, you'll be really, really good at moving to the cloud. These are the applications that you may move to VMs in the cloud simply to reduce the cost of migrating them.

In other words, by then moving to the cloud really will be stupidly simple for you.