Unlock Cloud Savings, A Rehost Migration Playbook (Part 2: Assess – Build a Business Case)

This blog post is the second in a four-part series to provide you with 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.

Figure 1: Rehost Migration Cost Activity Overview by Phase

In the previous blog, we discussed the Assess phase by defining the cost components and steps to analyzing your on-premises environment. In this post, we will explain the component of building a directional business case by using the AWS Migration Portfolio Assessment (MPA) tool.

An AWS business case is a data-driven analysis generated by the tool that outlines the potential cost savings, operational benefits, and business agility gains an organization could achieve by migrating their on-premises workloads to the AWS cloud, providing a compelling justification for the migration project based on their specific IT infrastructure and application portfolio typically on an annual basis. The business case will be published as a cost saving objective across your portfolio or organization as a Key Performance Indicator (KPI) of your Rehost migration.

AWS MPA is a web-based application for performing the portfolio assessment and business case analysis during the assess phase of your migration. Through the assessment, AWS MPA helps build a complete picture of the feasibility, effort, and cost needed to migrate your applications to AWS.

In this section, we will perform a walkthrough of one of the components of MPA; how to calculate the server level cost for your Rehost migration business case.

1. Prerequisites

To conduct this lab using AWS MPA, you should meet the following prerequisites:

• Your technical server metadata elicited in part 1 of this blog series, or sample metadata as inputs to the portfolio assessment.
• Be an AWS Partner or AWS employee. The tool is available for use by AWS employees and AWS Partners, independent from the AWS console, and does not require an AWS account.
  Note: If you are an AWS customer, you can provide the technical metadata elicited in part 1 to your AWS Account team. They can then conduct this AWS MPA lab on your behalf and share the results with you for review.

2. Conduct the AWS Migration Portfolio Assessment

2.1. Log in to AWS MPA

1. The URL to access the tool is: https://mpa.accelerate.amazonaws.com/
Log in with your AWS Partner Central ID or with Midway for Amazon Employees.

Figure 2: AWS MPA Log In

2.2. Create Portfolio

2. Select the Create Portfolio button to create a portfolio using sample data or with your data elicited in part 1 of the blog series.

Figure 3: AWS MPA All Portfolios

3. Enter a Portfolio Name to identify your portfolio.

4. To create the portfolio using your data, within the Portfolio Data section keep the default selections of Initial dataset > No data and Data classification > Customer Data.

5. Within the Customer account settings section the Portfolio must be associated with the respective Salesforce Customer account by selecting Select customer account from Salesforce.

6. (Optional) Within the Portfolio tags section you can add up to 50 tags to differentiate this assessment.

7. Review and confirm the customer data agreement checkbox.

8. Select Create a New Portfolio.

Figure 4: AWS MPA New Portfolio

2.3. Prepare the Data Set

9. From the Manage Assets screen, on the Servers tab of your portfolio select the Import from file button.

10. From the Import File screen, select the template files link. The link will initiate the download of a Microsoft Excel workbook file, Import-Data-Set-Template-Excel-V2.xlsx to your local device.

11. Open Import-Data-Set-Template-Excel-V2.xlsx in Microsoft Excel.
Within the Server tab, import all the on-premises server level technical metadata collected in part 1, section 2.1, for the following columns.

Figure 5: Description of Fields in Import-Data-Set-Template-Excel-V2.xlsx

Figure 6: Sample Template in Excel with server metadata

2.4. Upload the Data Set

12. Once the respective fields are populated in the Server tab of the Microsoft Excel file, then Save and upload the file from your local device.

Figure 7: AWS MPA Import File

2.5. Validate the Data Set

13. After uploading the file, validate the header mappings are correct. This mapping cannot be modified later. Within the recommended header mapping, select the units of measurement based on the type of unit in the import file.
For example, if the Server-Usage (%) Uptime is %, then select Percentage (0.00 -100.00).

Figure 8: MPA Recommended Header Mapping

14. Validate the optional header mapping fields.

Figure 9: MPA Optional Header Mapping

15. Remove all duplicate values.

Figure 10: MPA Remove Duplicate Values

16. Preview the uploaded data and select Confirm Import.

Figure 11: MPA Import File

17. The tool will redirect to the Manage Assets screen, Servers tab enabling you to review the imported data.

Figure 12: AWS MPA Review Servers

18. Once all the data is reviewed at a high level, before calculating the cost, the tool provides us the opportunity to make some high-level assumptions for calculating the estimates. Select TCO > Adjustments within the left-side menu.

Within AWS server recommendation. we can review default values and apply override assumptions for all servers.

• We can exclude certain instance types from our analysis by assigning them in the Do not recommend these EC2 instances.
  (This would be in cases when certain instances are not available in a particular region or if there are compatibility constraints with applications)
• Add a CPU buffer and a RAM buffer.
• Assign a default average CPU utilization(%) and Memory utilization percentage for all the servers in the list.
• Assign a Default average RAM utilization (%) and Default Peak RAM utilization(%) for all the server in the list.
• These additional metrics such as %CPU utilization and % Memory utilization helps us to right size the on-premises server to the corresponding right instance types on AWS during migration.

Figure 13: AWS MPA Modify Assumptions

2.6. Review the Total Cost of Ownership (TCO) Summary

19. The TCO summary page gives a summary report of the total cost of ownership for running those Amazon EC2 instances in AWS.

Figure 14: AWS MPA Modify Assumptions

20. We can modify the assumptions and update the field values such as AWS region, Refreshment period, Analysis duration and recalculate for exploring the various scenarios.

Figure 15: AWS MPA Modify Assumptions

Figure 16: AWS MPA Total cost of ownership

21. The TCO Summary page shows the overall calculated AWS cost and compares it to the On-premises cost. The AWS summary includes server (EC2), database (Amazon RDS), storage (Amazon EBS/Amazon EFS/Amazon S3/Glacier), network, IT labor, and AWS Support costs.

The EC2 recommendation page within (AWS> EC2 recommendations) gives the EC2 recommendations for all 3 scenarios.

• Average Utilization
• Peak utilization
• On-premises capacity

This gives the user a good reference point to the type of instance type to be selected during the migration.

Figure 17: AWS MPA Server Recommendations

22. The MPA tool also has the capability to create dashboards on the imported data. There are default dashboards created within Portfolio data > Dashboards. A user has the ability to create a new dashboard or add a new chart to the existing default dashboard.

Figure 18: AWS MPA Dashboards

3. Create your cost savings objectives

The completed business case provides an understanding of your organization’s Rehost migration cost saving opportunities and constraints. A summary of the business case should be captured and concisely communicated to the broader organization in the form of a cost saving objective.

3.1. What are cost savings objectives?

A cost savings objective or goal is a numerical or percentage value of hosting cost decrease measured at a fixed time interval, written as a brief statement. Saving objectives may be specific to a workload or portfolio, or may be general to the entire organization’s hosting footprint. Some examples cost saving objectives are as follows:

Example 1: Achieve an aggregate 20% decrease in annual hosting costs across the organization.
An organization-wide percentage savings objective and measured annually. Within the organization portfolios or applications could have varying rates of cost savings or even cost increases. This cost savings objective will be met if the aggregate hosting cost is a 20 percent or greater decrease, when measured annually.

Example 2: Reduce the information technologies portfolio hosting costs by $1,500,000 quarterly.
A savings objective specific to the information technology (IT) portfolio and measured quarterly. This savings objective is met if the IT portfolio reduces their hosting cost by at least $1,500,000 when comparing the costs between the quarter proceeding and immediately following migration completion.

3.2 Defining your cost savings objectives

When defining your cost saving objective and deciding between an organization-wide or individual portfolio-specific objective you should consider your migration scope, migration strategy, and your organization’s IT department structure. These variables are illustrated in Figure 19.

• Migration Scope: If your migration is an organization-wide initiative, consider authoring your objective broadly. The singular objective serves as a unifying goal for your organization. If your migration is limited to a specific portfolio, or individual portfolios, consider tailoring a savings objective for each portfolio in scope for migration to make it more directly applicable for the stakeholders within the portfolio.
• Migration Strategy: If the migration initiative is using a single migration strategy, then author a single, uniform objective. If portfolios or applications are using different migration strategies, then the objectives should vary based on the strategy because each has distinct benefits, including cost saving differences.
• IT Department: Each IT department inherently has a unique costing structure and on-premises hosting model that must be considered for accurate accounting and forecasting of cloud cost savings. Thus, if your organization has a centralized IT department, an organization-wide savings objective may be appropriate. Whereas organizations with federated IT departments should consider portfolio-specific savings objectives, aligned with the respective IT departments.

Figure 19: Cost Saving Objective Variables

A concise and crisp cost saving objective provides your organization clear quantifiable success criteria for your migration, and acts as an executive summary for your business case.

4. Conclusion

In this blog post we continued our Rehost migration cost optimization journey during the assess phase by building your business case via the AWS Migration Portfolio Assessment; And by summarizing your business case through Cost Saving Objectives.

Blog Series

• Part 1: Assess – Explore Cost Components
• Part 2: Assess – Build a Business Case
• Part 3: Mobilize – Understand and Control Cloud Spend
• Part 4: Migrate – Realizing Planned Savings

About the Authors