Time to upgrade! NAM is scheduled for end of support. It's time to move to Dynatrace our all-in-one software intelligence platform.

Managing and migrating legacy report server farm

In earlier releases, a number of slave servers analyzed and reported to a single master server. This legacy concept differs significantly from a currently supported farm-cluster-node hierarchy.

Note on product and component renaming
DC RUM 2017 and older NAM 2018, NAM 2019
RUM Console NAM Console
Central Analysis Server (CAS) NAM Server
Advanced Diagnostic Server (ADS) Advanced Diagnostics on Demand feature of NAM Server
Agentless Monitoring Device (AMD) NAM Probe

The current NAM Console is able to read and display the legacy farm definitions, but, because of the new farm concept implementation, legacy farm components are converted and their place in farm concept is changed.


To take full advantage of the new farm-cluster-node hierarchy and any automatic configuration features associated with it, you should consider a database reset when migrating a farm deployment from a previous version to the current version. While it may be possible to migrate from the previous farm structure to the new hierarchy without a database reset, the definitions, configurations, and historical data may not be compatible with the new scheme.

Migrating legacy report server farm

The preferable upgrade procedure involves upgrading the following components in this order:

Upgrade the NAM Console.

Upgrade all of the report servers participating in the farm.

Upgrade all of the data sources participating in the farm.

If needed, add all of the components to the device list in the NAM Console.

After upgrade, there is no need to perform any post upgrade reconfiguration. The upgrade applies the new farm concept in the following way:

Legacy Farm Definitions Current Farm Definitions
Master NAM Server server arrow right Primary node in a primary cluster
Slave NAM Server server arrow right Primary node in a secondary cluster
NAM Server failover server for master NAM Server arrow right NAM Server failover for a primary node in a primary cluster
NAM Server failover server for a slave NAM Server arrow right NAM Server failover server for a primary node of a secondary cluster

Logical conversion of legacy master-slave concept

Farm migration

While all of the legacy farm definitions will upgrade to the new farm-cluster-node hierarchy automatically, some upgraded farm deployments should be restructured to take advantage of the new farm concept.

If you have used the legacy farm master-slave concept to load balance the report servers, the upgraded farm will contain single node clusters that are using identical configurations. To receive a valid configuration with the proper farm hierarchy, consolidate all single node clusters with the same configuration into one cluster. The clusters that will be converted into nodes will balance the workload and acquire their configuration and settings from the cluster primary node.

Consolidation of the nodes into one cluster involves removing a node from a single node cluster and adding that node to the load balancing cluster. This involves a step where you can select a database reset for the node that you are adding. If the new node has different site and user option settings from the primary node's settings of the edited cluster, that node will be automatically marked for a database reset in the Clear nodes database screen of the wizard. Since this action is required, the marked option will be disabled. Both, Site options and User options of the NAM Server Configuration must be matching the primary node. If you are tracking user IP addresses from selected ranges and, these ranges differ between the primary node and the node being added, we recommend that you remove the User IP address ranges in the configuration options of the node that is being added. For more information, see NAM Server Configuration.

Post-upgrade reconfiguration

Migration reconfiguration


In your legacy deployment, if you were using the client and server range settings or application and service names or to load balance the incoming traffic, we recommend that you review these settings, as they may cause a portion of incoming traffic to be ignored.

Failover report servers migration

The legacy farm concept permitted the assignment of multiple failover nodes to a single report server. The current farm concept permits only one failover node per node within the cluster. Upgrade of multiple failover nodes for a single report server is not supported. If you have such a deployment, detach all additional failover nodes from the report server, leaving only the one failover node that you want to be included in the upgraded farm structure.


If you leave multiple failover nodes attached during migration, the upgrade will complete properly but the upgraded farm hierarchy will contain only the failover node that was listed first in the configuration database. This automatic upgrade does not give you the ability to select a specific device that you want to use as a failover node in the upgraded farm.