Business Decision – Why and what to move to the Public Cloud?


Migrating to AWS or Azure

Organizations have begun moving applications and workloads to public cloud at an increasing rate. According to Gartner, the worldwide infrastructure as a service (IaaS) public cloud market grew 31% in 2016 to total $22.1 billion1. In 2016, Amazon AWS had the No. 1 market share of 44.2%, Microsoft Azure 7.1% of the market and Alibaba 3.0% of the market.

Organizations are relying on the public cloud for a successful digital transformation. Many organizations have established a cloud strategy and business plan for moving workloads and applications to public cloud infrastructure, but are still working to determine the migration plan to support that strategy. But not all workloads and applications may be suitable for public cloud infrastructure services.

According to ESG Research, 91% of organizations expect to have substantial on-premises infrastructure deployments for the next five years. Most, but not all, applications and workloads can be migrated to public cloud. But just because you can migrate workloads and applications to public cloud doesn’t mean you should. As indicated, most organizations will have hybrid IT environments for the foreseeable future.

3 Essential Steps for Migrating to AWS or Azure Public Cloud

Step 1: Take inventory

The first step in a migration to public cloud is understanding the applications you have, the on-premises infrastructure resources supporting them, and the workload interdependencies. The best way to accomplish this is by using a discovery tool that automates the discovery and dependency mapping process. A discovery tool should provide an accurate inventory of infrastructure that includes:

  • Servers (physical and virtual, hypervisor, OS, CPU, RAM, disk)
  • Software (+EOL), databases, web sites
  • Network devices (switches, load balancers, etc.)
  • Storage (devices, but also their logical partitioning)

Discovery tools will collect server specification information, server to storage relationships, performance data, and details about running processes and network connections. Use the learnings from the discovery tool to help establish a migration sequence, minimize downtime and assist in test plans.

Step 2: Evaluate applications

Not all applications and workloads are well suited for public cloud. When developing a migration plan, it is essential to evaluate the workloads and applications that are candidates for moving to the public cloud. The considerations must be measured against the goals of your cloud strategy and the potential business risk. The key is to examine all applications and workloads under a consistent framework – not on an ad hoc basis.

When assessing the readiness for running applications in the public cloud, all the options need to be considered – from retaining as is, to replacing.


Redeploy an application to a cloud-based platform without modifying the application’s code. The reason for doing a lift and shift can be to quickly scale in order to meet a business need. Established applications that were not designed for efficient use of infrastructure will most likely cost more to run in a public cloud. Because of this, a simulated migration is recommended for rehosting applications to prevent cost surprises.


Refactoring/rearchitecting involves making modifications to the application, application framework or runtime environment. This can include making application code or configuration changes to attain some tangible benefit from moving to public cloud platform without making major changes to the core architecture of the applications.

For example, you may swap out a database server for a cloud service equivalent to reduce the amount of time you spend managing database instances. The goal is to get some optimization benefit from public cloud service with very little code change to the application.


For applications that you wrote, redesigning and rebuilding a cloud-native application on a provider’s PaaS may be worth the investment. This typically provides better performance and lower costs (if done correctly). This may be the right choice for applications that are business-critical, but not designed to take advantage of the services offered on a cloud platform. In addition, non x86-based applications, like mainframe and midrange applications that rely on operating systems other than Linux and Windows will need to be rewritten. This is the most expensive option, but the investment to rewrite an application may be worth it if looking to boost agility, reduce costs and improve business continuity.


For commercial, on-premises applications, replacement with a SaaS offering may be the best solution. Many vendors offer both SaaS and on-premises solutions now. And even if the preference is to run on-premises, many ISVs have upgraded their applications to better run on cloud platforms and it could be a matter of upgrading the application to a more current version.


Running applications on-premises is always an option. It may make good business sense to keep some applications on-premises. Lower costs and better security and compliance are strong considerations for doing so. Not every application benefits from a cloud platform. Applications that have static workloads with no agile demand, and that are running on stable systems, are good candidates to be retained on-premises.

The application evaluation phase also provides an opportunity to identify applications and workloads that are no longer needed or lack the business justification to warrant the ongoing cost to support them. This is a great time to rationalize your portfolio.

Step 3: Analyze cost

Migrating applications to public cloud platforms is a business decision that requires both financial and technical assessment. This is particularly important if the migration includes rehosted or refactored applications. If a preliminary assessment of the cost difference for running these applications on-premises vs. in a public cloud is not done, you will most likely get a big cost surprise later.

In a recent BMC survey, 40% of respondents stated they are unclear of their costs associated with cloud – even though lower cost was the primary driver (45%) for moving to public cloud.

Every IT organization should have a history of resource usage and workload patterns for their applications, along with the unit cost of infrastructure resources. Many organizations gather this information routinely and use it for chargeback or showback for IT infrastructure costs. If you do not have this information, you can still gain cost insights – they just won’t be as accurate. At a minimum, you need a unit cost for on-premises infrastructure resources and compute, storage and network resources for the workloads and applications you want to migrate. Otherwise you have no costs to compare.

The first step for determining cost of on-premises vs. public cloud costs is to identify the resources needed in public cloud. You can start by identifying the closest type of VM instance and configuration needed in public cloud. For AWS, this will be an EC2 instance and for Azure, a Windows VM. AWS has over 90 different types of VMs to choose from, and each type has multiple configurations from which to choose, and multiple locations or regions. Azure also has similar choices.

Once you have identified the compute resources, you must determine if you want to pay an on-demand price or a 40-60% discount price that you can get with one or three-year service commitments. AWS refers to these discounted VMs as Reserved Instances. If you have not yet selected a public cloud provider, you will want to compare costs across providers. Without having an automated tool to do this analysis for you, this effort can take weeks, depending on the number of applications and workloads you are analyzing.

There may be special storage, database or network resources that you need to identify and factor in as well. Once the analysis is completed, you should view it as a snapshot in time. IT environments are naturally dynamic, so costs will change over time. An ongoing cost management practice is essential to regulating operating and capital expense for a hybrid, multi-cloud environment.

Moving forward

Developing a migration plan takes time and a dedicated team. To streamline the effort and reduce time, you can use a solution like BMC Discovery to automate the discovery and dependency mapping work, and TrueSight Cloud Cost Control to automate the public cloud resource selection and pricing options evaluation. Once you are ready to begin migration, both AWS and Azure offer tools to help you move workloads and applications to their platforms.


Migration is just the first step of incorporating public cloud into your IT environment. To keep costs under control, you will need to establish a capacity management practice to ensure you are optimizing the use of public cloud and on-premises resources. And because of the change from capital expense to operating expense associated with this move, you will need to have an ongoing cost management practice to ensure that you adhere to both capital and operating budgets and maximize your IT infrastructure investment.




Strategize and plan workload migration to Public Cloud


Closer look at Cloud Migration

Organizations conviction in moving to the Public Cloud is getting stronger day by day. IT teams of all Enterprises today agree that cloud is becoming a key part of their IT Investments. But when it comes to the planning for the migration of the workloads from on-premise to cloud, unfortunately there is still a lot of confusion about what to move, how to move it and the best practices to follow to ensure smooth migration. A successful migration is possible only if there is a clear vision and plan for the migration defined.

Regardless of your current IT environment or your vision for migrating to the cloud, numerous strategies exist that can accommodate your cloud-migration approach. Fortunately, this range of options allows you to proceed with caution while making progress toward your ultimate objective.

Top Five Cloud Migration Strategies

  1. Re-hosting

Sometimes referred to as “lift and shift,” re-hosting simply entails redeploying applications to a cloud-based hardware environment and making the appropriate changes to the application’s host configuration. This type of migration can provide a quick and easy cloud migration solution. There are trade-offs to this strategy, as the IaaS-based benefits of elasticity and scalability are not available with a re-hosting deployment.

However, the solution is made even more appealing by the availability of automated tools such as Amazon Web Services VM Import/Export. Still, some customers prefer to “learn by doing,” and opt to deploy the re-hosting process manually. In either case, once you have applications actually running in the cloud they tend to be easier to optimize and re-architect.

Re-hosting is particularly effective in a large-scale enterprise migration. Some organizations have realized a cost savings of as much as 30 percent, without having to implement any cloud-specific optimizations.

  1. Re-platforming

This strategy entails running applications on the cloud provider’s infrastructure. You might make a few cloud-related optimizations to achieve some tangible benefit with relative ease, but you aren’t spending developer cycles to change an application’s core architecture.

Advantages of re-platforming include its “backward compatibility” that allows developers to reuse familiar resources, including legacy programming languages, development frameworks, and existing caches of an organization’s vital code.

An unfortunate downside to this strategy is the nascent state of the PaaS market, which doesn’t always provide some of the familiar capabilities offered to developers by existing platforms.

  1. Repurchasing

This solution most often means discarding a legacy application or application platform, and deploying commercially available software delivered as a service. The solution reduces the need for a development team when requirements for a business function change quickly. The repurchasing option often manifests as a move to an SaaS platform such as or Drupal. Disadvantages can include inconsistent naming conventions, interoperability issues, and vendor lock-in.

  1. Refactoring / Re-architecting

This solution involves re-imagining how an application is architected and developed, typically using the cloud-native features of PaaS. This is usually driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.

Unfortunately, this means the loss of legacy code and familiar development frameworks. On the flip side, it also means access to world-class developer’s tools available via the provider’s platform. Examples of productivity tools provided by PaaS providers include application templates and data models that can be customized, and developer communities that supply pre-built components.

The primary disadvantage to a PaaS arrangement is that the customer becomes extremely dependent on the provider. The fallout from a disengagement with the vendor over policies or pricing can be quite disruptive. A switch in vendors can mean abandoning most if not all, of a customer’s re-architected applications.

  1. Retiring

Typically, the initial step in the cloud migration process is the discovery of your entire IT portfolio. Often, this discovery process entails application metering to determine the actual usage of deployed applications. It’s not unusual to find that anywhere between 10 to 20 percent of an enterprise IT estate is no longer being used. Retiring these unused applications can have a positive impact on the company’s bottom line; not just with the cost savings realized by no longer maintaining the applications, but by allowing IT resources to be devoted elsewhere, and by minimizing security concerns for the obsolete applications.