Hi, This is Ryotaro
I want to know about ”Migration-tools ".
We are migrating DT 5.6 to DT 6.5.
The size of the dtma file acquisition using the migration tool is too large. (3GB)
We want to reduce the file size, so I have three questions for the migration.
Q1. There are multiple agentres.jar files under "server / lib", "collector / lib",
but could I delete non-required Agent-Versions of the files?
Q2.When I get dtma file from old version,
could I exclude Collectors configuration file by using option of the migration-tools?
(In this environment we will install the collectors newly.)
Q3.When I get dtma file from old version,
could I get only Server configuration file by using option of the migration-tools?
Solved! Go to Solution.
Can you go into detail why 3GB is too large for you? The tool should handle files of this size fine.
Ad Q1: Yes, you can a cleanup, but please mind the following:
Ad Q2: It is currently not possible to "collect only server data" - always all data will be collected during step 1 from install -> dtma. However once you have the dtma, when running dtma -> target, the migration tool should automatically check if the target is a server-only installation and will not migrate the collector files, but only the server files then.
To get the dtma file size down, you can also use the "-noclasscache" option, if the notes in section "Migration without class cache" here are acceptable during the upgrade for you.
Ad Q3: As mentioned in Q2, if the target installation is already a "server-only install", no collector files will be migrated by default. But you can also force with the "-migrateInstances defaultServer" option.
We are aware of the issue with growing installation size due to the old agent versions. These files being migrated and not being cleaned up automatically currently has very good and complex reasons, that we are hoping to address with the version following 7.0.
You can also use any other drives / mount points / (usb drives?) that you may have available, it should be handled fine by the tooling.
Thank you for your answer.
Reducing agnetres*.jar files will be best plan to decrease dtma file-size.
The version of agents which is active right now are the same version, so we may be able to reduce
agentres*.jar files from $DT_HOME/server/lib and $DT_HOME/collector/collector/instances/collector0?/lib.
By the way, I have checked dtma file from the customer environment, and there are the all version of
agentres-*.jars under $DT_HOME/server and $DT_HOME/collecoter/*/collector0?. Total 28 agentres*.jar files and amount to 2.3GB.
In our test environment, agentres*.jar files are only lattest version and the original ( agentres.jar).
Does the dynatrace-migration.jar creates every version of agentres*.jar files, althogh the all agents are
the lattest version only?
(The customer environment are first dynatrace 5.5 was installed, and then migrated to 5.6 and fix pack
Regarding agentres-*.jars under /server/ and /collector/
this is normal. The Server and Collector have their own directories in the DT_HOME and don't share files in most cases like here.
You can apply the same procedure to the /server/ and the different /collector/ directories. Be sure to check that some of those collectors can connect to different servers and that therefore different versions of the agentres may be necessary to keep.
Eg: Agent version X -> collector 1 -> server 1 = keep X
Agent version Y -> collector 2 -> server 2 = keep Y
for all agents that may connect to the collectors and/or servers.
"Does the dynatrace-migration.jar [copy] every version of agentres*.jar"
Yes, it has to. Also the server or collector cannot decide this, because there could always be an old agent running somewhere that is not connected to the collector or server and that may reconnect at any time and require the agentres.
Therefore this is something that the user has to perform - or at least confirm, that this agent version is not needed anymore.
I would like to ask one more question.
If I use the option "-noclasscache" getting archive file(dtma), do I have to stop dynatrace server and
collectors at the current prod-server?
( We just want to get configuration files like system-profiles,dashboards,etc, becoause theNew server has aleready installed and has been set upped.)
It is always necessary to stop all servers, collectors etc when working with the migration tool on a specific installation directory. So if you use -sourceDTHome X, then all servers, collectors etc in X have to be shut down. Same is true for targetDTHome. This applies even more to configuration files. Otherwise you may get a corrupt copy of the files being retrieved (happens rarely, but still possible).
If the problem is only getting corruped files, I wold like to try getting archive file(dtma).
I am going to use -migration -sourceDTHome x -noclasscache -targetArchive Y.
This operation doesn't effect the running dynatrce processes, does it?
I only need system profile and dashboards from the archive in order to import them to a new dtserver.
And the customer doesnot allow us to stop dtserver and collectors only for getting archives..
It may sounds like getting support archive. so it is very hard to stop servers..
getting corrupt files can be a serious problem. Your targetDTHome may not start up - use at your own risk and note that this process is unsupported. You may also need the "-skipRunningCheck" parameter if you really want to go down this road.
Note that there are a lot of other files to be migrated besides dashboards and system profiles - like users, permissions, stored passwords, etc..! If certain files are omitted, this can even cause agent crashes in certain special cases.
Also note that you will not be able to migrate to 6.5 directly, but have to migrate to 6.2 first, see here.
The usage of the migration tool can affect running servers, the scenario with running components is not tested.
It is not like getting a support archive, because this function and the migration tool is not integrated into the server, therefore it does not coordinate file reading / writing with the server, collectors etc and thus all components need to be shut down.
I can only strongly recommend to follow exactly the upgrade and migration guide and shut down the components for the upgrade. If you encounter issues during the upgrade without shut down, we will likely ask you to perform the upgrade again with the components shut down.
Note that this only refers to the AppMon components (AppMon Server, Collector etc) - it is not necessary to shut down any monitored application!
We understand that it may be difficult to get a downtime in, but the upgrade is a big process - feel free to file any requests for enhancement in the other forum here.
I am not sure why I am getting this error but i get it when I run smae exact command given in instructions
java -jar dynatrace-migration.jar -migration -sourceDTHome "x" -targetArchiveDir "C:\Users\ankit.a.jain\Downloads/x.dtma"
The option sourceDTHome doesn't define a Dynatrace Server or Collector install d
Hello @ankit j.
What type of error message you received?
Make sure all source or target installation components such as the Server and Client must be shut down before running the Migration Tool. This is necessary because files like the Collector class cache are constantly changing, and files may also change while the tool runs. This can result in corrupt files.
Create a migration archive:
java -jar dynatrace-migration.jar -migration -sourceDTHome "<DT_HOME_OLD>" -targetArchiveDir "<ARCHIVE_DIR>"
<DT_HOME_OLD> is the old AppMon installation path. A
<MIGRATION_ARCHIVE> file named
<Server_name>_<creation_dateTime>.dtma is created in
sourceDTHome must point to an appmon installation directory, eg:
-sourceDTHome "C:\Program Files\dynaTrace\Dynatrace 6.5"
Note also the targetArchiveDir must point to a directory, so eg "C:\Users\ankit.a.jain\Downloads".
If you want to give the full archive name, use "-targetArchive C:\Users\ankit.a.jain\Downloads/x.dtma"
See also examples here:
I Just want to explain you this to make sure you are clear. The command which you are executing is for migrating the data like configuration, system profiles, users details etc, from one version to another version. Say, if you have Dynatrace AppMon version 6.5 installed already and you are using and want to upgrade the environment to 7.0 for which you can use this command.
Consider these points before you execute the command
1) Migration file: The directory/path from where you are executing should need to have the dynatrace-migration.jar file - Verify the location 7.4 DT upgrade\ has the file or not - since, you have executed the command from here as per snapshot.
2) Source path: Since you are migrating the data from one version to another version. So, source file location here is mandatory and it should be mentioned correctly. What is your previous version installed directory/path.. ? mention that
3) Destination path: - You have to make sure the path provided in the command as destination exists or not - Also you should have installed the new version of the Dynatrace AppMon on which you are going to migrate your prev AppMon version data
In the error message, it is said that the source directory does not exist.
It seems to me that source directory and archive directory are concatenated and interpreted.
I think that the last "\" in the directory path is disabling double quotes.
I hope this would be some of help.
I could see target directory which you mentioned in above as "C:\Useres\ankit.a.jain\Downloads\".. is the new version of AppMon installed in this folder Downloads.. ? If not choose the correct path, or if you have folder name like Dynatrace-7.0 please add that at the end if it is Downloads folder and no need to mention the slash \ at the end of the path
If you are still facing the issue, please paste the snapshot of path of previous version and new version AppMon installed directory.
Took some time to troubleshoot this, I have tested creating the migration file on both windows and Linux flavors. on Linux server I didn't faced any issues while creating the file.
While doing the same on Windows, I got a error pop up as I have mentioned the source directory as the client installation path wrongly.
Post correcting my source path file, I was able to successfully create the migration file.
So, I say the problem is with the source directory which you have mentioned and also check the migration jar file which you are using, download the newfile from the dynatrace and try it.
Note: There is no problem with the "quotes" or "\" slash which you have used in the command. Follow my snapshot for the better results.