Migration & Modernization

Unlocking Cloud Savings, A Rehost Migration Playbook (Part 1: Assess – Explore Cost Components)

Many AWS customers performing large-scale migrations opt for a Rehost migration approach as a way to quickly unlock initial cost savings. The Rehost pattern serves as a high-velocity migration pattern to move to the cloud. However, this pattern also negates the cost advantages of the cloud if proper cost optimization strategies and controls are not implemented throughout the migration process. This blog post is the first in a four-part series to provide customers a step-by-step guide on how to optimize costs throughout an AWS Rehost migration, specifically:

  1. Exploring your cost components and on-premises environment.
  2. Building an accurate business case during the assess phase.
  3. Understanding and controlling cloud spend during the mobilize phase.
  4. Optimizing costs to realize the planned financial savings during the migrate phase.

Rehost Migration Cost Activity Overview by Phase, highlighting Assess, Explore Cost Components.

Figure 1: Rehost Migration Cost Activity Overview by Phase

1. Define the cost components

To accurately build a business case you must first identify and account for each cost component of your hosting infrastructure. The primary cost categories are hardware, software, facilities, and people. The cost components are server costs, storage costs, network costs, and migration costs. Figure 2, is a table listing the cost categories as rows, and cost components as columns. The cells are specific cost elements that must be accounted for in the business case.

Hardware Software Facility People
Server Costs Server, Rack Server OS and Virtualization Space, Power, Cooling Data Center Admins
Storage Costs Storage Disks, SAN Switching Storage Backup Software Storage, System, and Virtualization Admins
Network Costs LAN Switching, WAN Switching Network Monitoring Software Network, and Security Admins
Migration Costs Migration Tooling Migration Services Interim Parallel Environment and Lease Penalties Migration Project Resources

Figure 2: Hosting Cost Categories by Cost Component

 1.1. Hardware Cost Category

Hardware costs comprise the physical infrastructure in your data centers, including servers, racks, storage arrays, and networking equipment such as Storage Area Network (SAN) and Local Area Network (LAN) switches. These costs also extend to the secure disposal of outdated hardware and data erasure services, often performed by specialized vendors.

1.2. Software Cost Category

Software costs include licenses for server operating systems, virtualization, backup, applications, and network and security management tools.

1.3. Facility Cost Category

Facility costs are the costs associated with the physical real estate and operating cost of the data center. This includes the power and cooling of the physical servers, storage, and network hardware within the data center. Facility costs can be inadvertently overlooked by organizations performing costing exercises. This is because the facility cost is usually represented as an aggregated cost, without the granularity of facility cost applied per unit of hardware. However, facility cost must be accounted for in building your business case because comparatively AWS costs include the costs to operate the underlying hardware on your behalf.

1.4. People Cost Category

People costs are the costs of all the operational, technical and leadership personnel required to operate your technical infrastructure and data centers.

1.5. Migration Cost Component

The migration cost component spans each cost category (hardware, software, facilities, and people), and exists explicitly for cost estimation, forecasting, and tracking of your migration program.

  • The Migration Tooling element involves any third-party tools or appliances used for application discovery and inventory within the data center during migration planning.
  • The Migration Services element consists of the AWS services utilized to plan and execute your Rehost migration, such as AWS Migration Hub, or AWS Application Migration Service (MGN).
  • Interim Parallel Environment, “migration double bubble”, refers to temporary dual environments (on-premises and AWS) that exist during the migration execution.
  • Lease Penalties are any contractual fees associated with your data center footprint reduction or exit due to the migration.
  •  The Migration Project Resources element is the total cost of the migration project’s resources. These resources may consist of internal, AWS Professional Services, AWS Partner Network (APN) resources, or a mix.

2. Analyze your on-premises environment

With an understanding of the cost elements of a traditional on-premises hosting infrastructure, we will explore how to gather the technical metadata of these data elements for use in your business case.

2.1. Infrastructure Inventory

Identify the sources that have the metadata about your environment. Configuration management databases (CMDBs), hypervisors, and change management systems are common sources of metadata. It may be appropriate to employ a tool to assist. AWS provides access to Discovery, Planning, and Recommendation migration tools that perform with automated discovery and technical planning.

Regardless of the data gathering approach you use, to perform an accurate analysis for your Rehost migration business case you must account for each cost element, as defined in Figure 2.

An example of 27 common technical metadata outputs from a sample customer CMDB and hypervisor is provided in Figure 3. The metadata will vary based on your inventory source and by cost element. Some of these elements will be explicitly required as inputs to the AWS MPA assessment per the lab in part 2 of this blog series.

Metadata Name Metadata Description
Application ID A unique identifier for each application in your inventory.
Host Name* The name of the server or virtual machine where the application is hosted. This must be a unique value.
Disposition The desired status or state of the application or server post migration (e.g., active, retired, decommissioned).
Environment* The environment in which the application is hosted (e.g., Production, Staging, Testing, Development).
Edge A boolean flag indicating if the application or server is part of an edge or peripheral network (e.g., A server or application located closer to the end-users for lower latency).
ERP Indicates if the application or server is related to an Enterprise Resource Planning (ERP) system.
Unique ID / ServerID A globally unique identifier for each entry in the inventory. (For input to the MPA tool lab in section 3, the asset must be a server)
Is Physical* A text string indicating if the asset is “Physical” or “Virtual.”
Location The physical location or data center where the server or application is hosted.
Primary vCenter location The name of the cluster or group to which the server or application belongs.
Primary Data center The name of the data center where the primary cluster is located.
OS Name* The operating system (OS) name installed on the server or virtual machine.
OS Version* The operating system (OS) version installed on the server or virtual machine.
Legacy Operating System (OS) A boolean flag indicating if the OS is end of life or not supported.
Number of CPU* The number of CPU cores or processors available on the server.
Note: For VMware, you capture the number the vCPU’s.
CPU Utilization* The 30-day average and peak CPU utilization percentage for the server.
RAM* The amount of RAM (in gigabytes) installed on the server.
RAM Utilization* The 30-day average and peak RAM utilization percentage for the server.
Disk GB* The total disk space (in gigabytes) available on the server.
Disk Utilization* The disk utilization percentage for the server.
Application Name The name of the application hosted on the server.
Database Name The name of the database associated with the application (if applicable).
Database Type and version The type of database (e.g. MySQL, PostgreSQL, Oracle) associated with the application.
Application Owner The name of the person or team responsible for managing the application.
Application Owner Email Address The email address of the application owner.
IP Address The IP address of the server or virtual machine.
Shared Storage Indicates path of shared storage used by the given server or application.
* Denotes a field required as an input to the AWS MPA assessment in part 2 of this blog series.

Figure 3: Technical Metadata from CMDB

2.2. Utilization Metrics

The server utilization metrics of the workloads in-scope for your Rehost migration will be required for right sizing purposes. For workloads hosted on an on-premises hypervisor record the: CPU, memory, disk input/output (I/O), network ingress, and network egress utilization from this environment for the last 30 days.

Often network or system administration teams have observation tools that record and retain these data by application for use in their course of operations and maintenance. These tools may include built-in solutions like VMware vCenter, scripting tools such as PowerCLI, third-party monitoring software like Zabbix or Datadog, cloud-specific services like AWS Migration Evaluator, or open-source platforms like Grafana with InfluxDB or Prometheus. The utilization metrics and application trends will be inputs into the business case in part 2 of this blog series.

2.3. Software Licensing

Software licensing, including Operating System (OS) and database licenses needs to be accounted for in your Rehost migration, for legal compliance and financial impact.

Running workloads in AWS can require fewer instances and licenses due to the elasticity of the cloud. AWS Optimization and Licensing Agreement (AWS OLA) is a complimentary program that helps you reduce costs by identifying opportunities to maximize your license efficiency, avoid over-provisioning, and explore flexible licensing options like Bring-Your-Own-License (BYOL) and license-included instances. For workloads that will run for one or more years, investigate Compute Savings Plans and Reserved Instances (RI) to reduce operational costs.

2.4. Hardware Divestiture

If your Rehost migration involves a complete data center exit, you will need to divest all the data center hardware. However, even if the migration is limited to a subset of your on-premises workloads the data center footprint will still be reduced, contributing to your cost savings.

You have several options to consider for divesting the impacted data center hardware from your current IT spend:

  • Sell the hardware: If the hardware is still in good condition, you may be able to recoup some of the initial investment by selling it. This can help offset migration costs.
  • Repurpose the hardware: Assess if any of the on-premises hardware can be repurposed for other uses within your organization, rather than leaving it idle.
  • Decommission the hardware: If the hardware is end-of-life or no longer useful, plan to decommission it properly as part of the migration process.
  • Donate the hardware to non-profit or charitable organization: if the hardware is not fully depreciated, you may be able to deduct the undepreciated value.

For leased hardware, it is important to time the migration to coincide with the end of the lease term, if possible. This allows you to avoid early termination fees, lease penalties, and minimize the waste of unused on-premises hardware.

2.5. Compliance, regulatory, and security requirements

The AWS Compliance Program provides reference to the compliance, regulatory, and security controls in place within the AWS cloud. An important aspect of meeting your organization’s specific requirements is understanding AWS’s Shared Responsibility Model, This model delineates between AWS and customer responsibilities. In short, AWS is responsible for the “security of the cloud,” while you, the customer, are responsible for the “security in the cloud.” Figure 4 depicts this shared responsibility model from the perspective of a Rehost pattern.

AWS Shared Responsibility Model for the Rehost Pattern, depicting responsibility between an On-premises environment and Rehost pattern on AWS.

Figure 4: AWS Shared Responsibility Model for the Rehost Pattern

By mapping your compliance controls to the shared responsibility model, you can succinctly and definitively determine which requirements will be offloaded to AWS, and which will remain the responsibility of your organization.

2.6. Summarizing the on-premises environment analysis

The detailed analysis of your current on-premises environment, including: infrastructure inventory, utilization metrics, software licensing, hardware divestiture, and compliance requirements, provides the inputs for building a business case.

3. Conclusion

In this blog post we began our Rehost migration cost optimization journey in the assess phase by: 1. Defining the cost components, and 2. Analyzing your on-premises environment.

Blog Series

Every two weeks the next blog post in the series will be released with direct links added as follows:

About the Authors