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 basic 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
RabbitMQ 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, NGINX, 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 add New Relic IPs to your allow list.

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, NGINX): 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.

You can find some of these metrics in service maps, as well as on APM, and Browser overview pages.

For more detailed information about navigating, interpreting, and using New Relic APM, check out these New Relic University’s tutorials:

5. Set up Dashboards

After you define your KPIs, it is easy to visualize them in New Relic Dashboards. Dashboards provide a single location to view all the data that New Relic products gather. Dashboards 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 and Default events for New Relic products.

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 Dashboards to track the performance of those KPIs:

Example: Component performance compared against baselines

Continuing the examples in this document, the following 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

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:

You can also learn more about APM custom instrumentation with the New Relic University Custom data tutorial series.

For more help

If you need more help, check out these support and learning resources: