After the Server/Collector upgrade, the Agent bootstrap upgrades the actual Agent, but the old version Agents run until you restart your applications.
Due to a change of the license handling of .NET and IIS agents in AppMon 6.3 and later, it is strongly recommended to restart all .NET and IIS agents on a host after an upgrade from a version earlier than 6.3 to AppMon 6.3 or later.
You should have a restart plan/coordination for your application tiers.
You can find the Agent version (bootstrap and active part) information in the Agents Overview dashlet.
Yes. For example, if you have a 7.0 Server and 7.0 license active on that server, 6.5 Agents consume the license slots as with a 6.5 Server and license. However, be sure to check the general Agent compatibility.
No for most Agents, because they are bootstrapped and upgrade automatically with a restart. But check if your bootstrap version is still supported. See Upgrade Agents for more information.
No, but it is highly recommended for backup purposes. See the tool syntax for more information.
No. Use your database backup to go back.
Connecting the new AppMon Server to the old Performance Warehouse database updates the AppMon schema. You can check the version of the DB database.
For example, in SQL Server:
SELECT MAX(version) FROM schema_version;
If there is no table
schema_version in your schema (in AppMon 6.3 and earlier), use the following statement:
SELECT * FROM dynatrace70.dbo.version;
Yes, but only the last 10 minutes. Older data is lost.
This depends on the version you are upgrading from and the amount and type of data stored in the database. In general it should be done in a few minutes, but can take up to one hour in worst case scenarios.
No. Submit a request for enhancement if you require this.
No, except only the last 10 minutes of data collected while the migration is running is stored.
Be sure that AppMon is disconnected while restoration. For the restoration, refer to your datyabase vendor documentation on how to restore snapshots.
Not immediately for regular licenses (ecxludes demo and POC). After deactivation, you have a grace period where the license still functions. See license deactivation for more information.
When upgrading from 6.5 and earlier, UEM volume deactivates immediately however and does not have a grace period, as the voucher with the remaining visit counts is already returned to eService. When migrating from 7.0 and higher, the volume deactivates only if it is not part of the standard license (eg vouchers), otherwise the grace period also applies for the volume.
Keep in mind that roll back should be a last resort scenario, first open a support ticket for your upgrade problem. Then open a license support ticket to get an old license.
Collector instances share one single installation directory and are started and installed with the
As these instances share certain files such as
dtcollector.ini, you should shut down all instances when migrating files. The migration tool migrates all files for all collector instances by default, so you don't need any special parameters. But you must make sure all instances are started from the new location using
init.d scripts or installing new Windows services (as described in the guide).
Using the file
dtcollector.ini as an example, migration creates two files in your new installation directory:
<DT_HOME_NEW>/dtcollector.ini: This is the new file from the installer for the version 7.0. It is used by the new collector. Any settings from your old installation are included in this file.
<DT_HOME_NEW>/dtcollector.ini.toBeMigratedis a copy of your old
<DT_HOME_OLD>/dtcollector.iniand stored here by the migration tool for convenience. This file potentially contains settings that you want to keep and integrate into the new file.
You can use a text comparison tool to clearly see the differences. Each entry begin with a dash (-) and ends right before the next dash. Entries can be one-line or two-line. For example:
For each entry that is in
dtcollector.ini.toBeMigrated and not in
dtcollector.ini, decide if you ignore it or add it to
Entries that you should migrate:
- Any entries that you added yourself, either in the file or through the debug options, mostly they should begin with
- Memory configuration lines, which begin with
- Memory and sizing entries: -memory VALUE and -sizing VALUE.
Yes, this is supported, as long as the target operating system is supported by AppMon in general. As part of the migration you move the migration archive from one system to another.
The default paths in the configuration are relative paths, so these work independent of the OS. If you manually changed relative paths to absolute paths, you must change them after the migration.
It is recommended that you do not migrate to another system and upgrade to a new version at the same time, since this makes it more difficult to isolate potential post-migration problems. In these cases, it is recommended that you first follow the guide to migrate to the new operating system, check that everything is working, and then upgrade to the new version.