Transition from RUM Classic to RUM
- Latest Dynatrace
- Explanation
- 1-min read
If you already monitor your web and mobile frontends with RUM Classic, upgrading to RUM is straightforward. Learn how RUM relates to RUM Classic and how to activate it.
Upgrade to RUM
Upgrading from RUM Classic to RUM requires only a configuration change. The following guides outline the necessary steps.
Relationship between RUM and RUM Classic
RUM currently relies on certain RUM Classic functionalities. Here’s what this means for you.
Dependence on RUM Classic
You can turn on RUM only if RUM Classic is active. At this time, deactivating data ingestion into RUM Classic and fully migrating to RUM are not possible.
Configuration
Most configuration settings for RUM are based on those already used by RUM Classic. This means that:
- Changes made in RUM also apply to RUM Classic.
- Conversely, if you modify settings in RUM Classic that are also available in RUM, those changes will apply there as well.
Event and session properties are an exception—they have a separate configuration from user action and session properties in RUM Classic.
Monitoring traffic
When RUM is active, RUM beacons in a new format are sent alongside RUM Classic beacons to the same endpoint.
Infrastructure pass-through requirements
RUM largely relies on the same HTTP headers and cookies as RUM Classic. If your firewalls and other infrastructure components are already configured to comply with the infrastructure pass-through requirements for RUM Classic, you only need to take care of the following additional requirements to comply with the infrastructure pass-through requirements for RUM.
Do not alter the beacon URL query string
In RUM, the beacon URL query string's integrity is verified using a checksum. Your infrastructure must therefore ensure that the beacon URL query string is not altered in any way—this includes the modification, removal, or reordering of parameters.
Identify issues caused by an altered beacon query string
If you followed one of the guides in Enable RUM, but 
Experience Vitals shows no data or less data than expected, check whether your infrastructure is modifying the beacon query string.
Identify beacons of the new format
To identify RUM beacons, open the network tab of your browser's developer tools and look for requests with the URL path /bf or requests where the last URL path segment starts with rb_. Then check their query strings—beacons in the new format include the query string parameter pv=4.
Check the beacon response
Beacon requests of the new format rejected by the beacon endpoint return a JSON response with the field status set to ERROR.
They also include the fields errorCode and errorReason. If the query string was altered, you will see one of the following combinations:
3014—Query string CRC mismatch3001—Parameter ty missing
Let the W3C trace context pass through
In RUM, the W3C trace context headers traceparent and tracestate are used for frontend-backend linking. Since RUM Classic did not use these headers, you may still need to configure your infrastructure to let them pass through.
Built-in metrics
RUM provides numerous built‑in metrics. Due to its different underlying data model, these are not direct equivalents of the RUM Classic metrics. Still, many metrics have functional replacements, which are listed in RUM metrics upgrade.
Frontend-backend linking
RUM uses a different approach for frontend-backend linking than RUM Classic. Wherever this link is established out of the box in RUM Classic, it is also established in RUM—and for backends instrumented with OpenTelemetry, RUM goes beyond what RUM Classic offers.
You need to set up frontend-backend linking for the following scenarios, which also require setup in RUM Classic.
Cross-origin XHRs and Fetch requests on web frontends
In RUM Classic, you can link cross-origin XHRs and Fetch requests either by adding the x-dtc header through a regular expression or by using credentialed requests, as described in Link cross-origin XHR user actions and their distributed traces in RUM Classic. Neither configuration can be migrated automatically, because RUM uses the W3C trace context instead, and adding it without the corresponding CORS configuration would cause CORS errors. To set up the W3C trace context for cross-origin requests, see Add the W3C trace context to cross-origin requests.
Use of custom networking stacks on mobile frontends
If you use a custom networking stack on your mobile frontend, RUM Classic requires you to propagate the x-dynatrace header manually to link RUM data with server-side distributed traces; see the instructions for Android, iOS, and .NET MAUI. In RUM, frontend-backend linking relies on the W3C trace context instead, which you also need to add manually in this scenario. For instructions and examples, see Android, iOS, or .NET MAUI.
RUM has no equivalent to the WebRequestTiming object for capturing web request timings. Your code needs to measure these timings and report them as shown in the linked examples.