Create application baselines

Cloud migrations can take many forms. Some companies choose to port their applications directly from their data center to the cloud (a “Lift and Shift” migration) while others focus on completely re-architecting their applications to take advantage of benefits available only in the cloud. No matter your approach, there are three primary questions you want to answer after your migration:

  • Has my application gotten slower?
  • Is my application less stable than before?
  • Am I losing customers due to either of the previous questions?

To answer these questions, start by performing some black-box testing to establish a baseline for the performance and availability of your systems. A baseline is a measurement of the current performance and availability of your application, which you then use as a comparison after your migration to validate your business case. In some cases, you may change a baseline when you perform migration acceptance testing. You can also use a baseline as a comparison point during your migration to make sure that you are on track.

1. Identify components

Before you begin a cloud migration, identify all the tiers of your entire application stack. List all of the components (applications, services, etc.) that you want to migrate. Segment the application stack as follows:

  • Application (backend/microservices/cron jobs)
  • Dependency services, such as the message queue
  • Database
  • Website
  • Underlying server and infrastructure

Make sure that you have access to applications and instances before you start creating application baselines. Engage your application owners, DevOps engineers, and product managers for access.

Example: List of components

Here is an example of the list of components in an application stack:

Component Name Owner Language Stack Accessibility (Internet/Intranet) Operating System
Service 1 John Doe Java Internet RHEL 6
Service 2 Maya Wiz .NET Intranet Win2003 R2
ActiveMQ John Doe Java Intranet AIX
Website Maya Wiz Classic ASP Internet Win2000
MS SQL Dave Z NA Intranet Win2003 R2

2. Determine compatibility

Once you identify the applications that you want to migrate, it is time to verify which application tiers to monitor with the New Relic platform. Work with stakeholders in your organization to determine the amount of instrumentation that is possible–or allowed–within your organization. This is an important step and one that will pay off, as the more you can instrument, the better your baselines.

Here are the New Relic products to use for baselining, depending on the components that you identified:

Example: Components matched to New Relic products

Match the components that you identified with their corresponding products:

Component Name Tier Owner Language Stack Accessibility (Internet/ Intranet) Operating System New Relic Products
Service 1 John Doe Java Internet RHEL 6 APM, Infrastructure, Synthetics
Service 2 Maya Wiz .NET Intranet Win2003 R2 APM, Infrastructure
ActiveMQ John Doe Java Intranet AIX APM, Plugin
Website Maya Wiz Classic ASP Internet Win2000 Synthetics
MS SQL Dave Z n/a Intranet Win2003 R2 Infrastructure, On-host Integration

3. Deploy monitoring

Based on the component-product matches you made, deploy agents or monitors across your architecture:

Deploy New Relic APM

Install the APM agent on your application stack. The steps to install the APM agent are different based on language.

Deploy New Relic Infrastructure

After reviewing the requirements for New Relic Infrastructure, follow the instructions to install the Infrastructure agent on your hosts:

Deploy Infrastructure on-host integrations

To gain extended visibility into applications that your code depends on, deploy on-host integrations. Available integrations include Apache, MySQL, NGNIX, and others.

Create New Relic Synthetics monitors

New Relic Synthetics is a suite of automated, scriptable tools to monitor your websites, critical business transactions, and API endpoints. To get started add a monitor.

Make sure to verify that your website URL is accessible from the public network. You may also need to whitelist New Relic IPs.

4. Gather metrics

After you deploy the agents and monitors, identify which metrics are the most important to your business and use these metrics to define your KPIs. Some recommendations include:

  • Response time: Time taken to respond to a request.
  • Throughput: Number of requests that came in through the application.
  • Requesting queuing (Apache, IIS, NGNIX): Duration of time taken for a request to reach your application.
  • Database call duration: Duration of time taken to complete a database call.
  • DB call counts: Number of calls made by application code to the database.
  • Error rate: Percent of errors reported.
  • Apdex score: An industry standard to measure user satisfaction with the response time of web applications and services.
  • DNS setup timing: The time it takes to connect and receive data from DNS.
  • SSL setup timing: The time it takes to establish an SSL connection.

For more detailed information about navigating, interpreting, and using New Relic APM, check out these New Relic University’s tutorials: Overview Dashboard Tour, Transactions Dashboard, and Understanding Apdex

Some of those metrics can be found in Service Maps, as well as on APM and Browser Overview pages.

screen-service-maps.png > Service maps > (select a map): Use service maps to understand the connections between different parts of your architecture.

5. Set up Insights dashboards

After you define your KPIs, it is easy to visualize them in New Relic Insights. Insights is a single location to view all the data that New Relic products gather. Insights data consists of events, and each event has an event type, a timestamp, and key-value attributes. For more information about events, see Data collection.

Default event types for New Relic products include:

You can locate your KPIs and business metrics data in New Relic using the data explorer and the NRQL query language. You can also build Insights dashboards to track the performance of those KPIs:

screen-insights-kpi-catalyst-dashboard.png > (select a dashboard): Custom Insights dashboards let you focus on the KPIs that are most important to your migration plan.
Example: Component performance compared against baselines

Continuing the examples from above, this table illustrates the maturity of your application performance over a period of time based on deployment milestones. Each milestone will serve as a new baseline for your applications:


Milestone 1

Milestone 2

Milestone N


Component Name

Response Time



Response Time





Service 1

1.5 secs



1.5 secs



1.4 secs


Service 1

0.9 secs



0.9 secs



0.7 secs


Service 2

0.7 secs



0.7 secs



0.85 secs


Service 2

0.6 secs



0.6 secs



0.5 secs

A custom Insights dashboard illustrates this progress:

screen-cloud-migration-kpi-baselines.png > (select a dashboard): A custom Insights dashboard can help illustrate performance in your KPIs after completing a cloud migration.

After your migration, compare these baselines against your migration acceptance testing baselines.

Expert tips

If you find that you need data that is not captured by default instrumentation, New Relic makes it easy to capture custom data:

For more help

Explore the New Relic Platform.

Recommendations for learning more: