This is part 2 of a two part post on calculating cloud migration costs. In part 1 we broke down the key components of the move that need consideration. We also linked to and described all of the public cloud cost calculators to help you estimate expenses. In this post, we’ll take a closer look and discuss why you need to distinguish between CapEx and OpEx expenses.

Finding Your Current IT Operations' Costs

The actual costs involved in migrating to the cloud depend largely on the nature of your current IT operations. In general, you can break migration costs down into the following basic categories:

Rehosting with Minor Changes 

This includes "Lift and Shift" as well as moves that involve limited adjustments. Existing applications and resources are moved to the cloud with minimal changes - databases may be relocated as-is, and applications may be moved to virtual machines.

Rehosting with Major Changes

This includes moves from a legacy to a modern database as well as migrations in which existing legacy applications cannot be easily moved to a VM and have no near equivalent in the cloud. It also includes in-house applications which require significant code changes before they can be moved to the cloud.

Refactoring Monolithic Applications 

Very often, simply rehosting an application will be sufficient, even if it requires major changes to the application's code. There are times, however, when it makes sense to refactor a traditional monolithic application into container-based microservices, making it effectively fully cloud-native. Such refactoring typically requires major redesign and can represent a significant investment of both money and time.


It pays to look closely at the tradeoffs before deciding to refactor, keeping in mind the potential advantages in terms of cost. These include greater granularity; the breakdown into microservices allows you to deploy applications with a smaller infrastructure footprint (and lower costs) than would be the case for the equivalent monolithic application.

Synchronization During the Move

You will probably need to continue to use at least some of your applications and databases during the migration process. Typically, you would do this by keeping the versions on your local servers live until the moment of changeover. At that point, the cloud-based applications and databases would go live, and the local databases would synchronize by transferring updated records to the cloud versions (containing pre-migration data snapshots).

For any of these processes, you may need to bring in outside consultants; when this is the case, both the cost of the consultants and the probable time, effort, and expense saved by using their services should be included in your calculations.

CapEx vs. OpEx

As described above, many of the key hardware-related direct costs arising from on-premise IT fall into the category of capital expenditures. Cloud-based IT, on the other hand, consists largely of ongoing services, so its costs are typically treated as operating expenditures.

This difference can have a major impact on both accounting and taxes. Capital expenditures are generally amortized, with deductions spread over the amortization period and determined in part by depreciation. Operating expenditures are fully deducted during the year in which they are incurred.

A business environment with rapidly-changing technology tends to strongly favour OpEx over CapEx, since technology-dependent capital expenditures are likely to be subject to rapid depreciation, while technology-as-a-service (i.e., the cloud) operating expenditures shift the responsibility for dealing with hardware depreciation to the service provider.

It is also generally much easier to get approval for recurring or ongoing operating expenditures than it is to guide a major, one-time capital expenditure through the approval process. This can make it possible, for example, to incrementally upgrade cloud-based IT in a much shorter time (and with less trouble) than would be the case for the equivalent on-premise hardware upgrade.

Further considerations: post-migration costs and difficult-to-quantify benefits

Finally, there are a variety of other, less quantifiable factors to consider when looking at both the costs and benefits of moving to the cloud. A considerable amount of support, for example, may be included in your cloud-service contract, along with such things as automatic application and infrastructure updates (and possibly version upgrades). Your hardware maintenance costs and responsibilities will largely be limited to on-premise routers and end-user devices (a major change for most IT teams), and you are likely to experience minimal downtime.

On one hand, you may encounter intermittent costs as you add capacity and services, but these will come without the added time and expense required to make the equivalent upgrades to in-house servers. The flexibility that is built in to the cloud makes it easy to rapidly update and scale not just applications and storage capacity, but also basic infrastructure.

GitOps workflows for cloud native automation

Also note that while on-premise IT is actually designed for a world with very low levels of automation and waterfall (or similar intermittent) development and deployment cycles, automation is native to the cloud (and to a large degree, the cloud itself is native to DevOps). Tools for continuous integration (CI) and continuous delivery (CD) are built in, making it relatively cheap and easy to move to GitOps for fast, efficient automation practices.


Calculating both the true costs and benefits of migration to the cloud is an essential step not just in making the choice of whether or not to move to the cloud, but also in mapping out the process of migration. Know where you're going, know how to get there, and know what it takes; when you do this, you will find that the journey is much easier.