Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Few questions on Upgrade to 6.5



we want to upgrade our environment from dynatrace 6.2 to 6.5.

question 1.Our server is in "x" host and collector instances with load balancing in " Y" and "Z" hosts each contain 6 instances.when i run the migration tool to upgrade dynatrace server(X host) it worked.But when i run dt migration tool in collector hosts(Y and Z) it was not copying all the collector instances(6 instances) to 6.5.can someone suggest,Am i missing something here.Do i need to manually copy and do changes.I followed documentation and used these 2 steps.

File Collection
java -jar dynatrace-migration.jar -migration -sourceDTHome "<DT_HOME_OLD>" -
targetArchiveDir "<ARCHIVE_DIR>"

File Migration

java -jar dynatrace-migration.jar -migration -sourceArchive "<ARCHIVE_DIR>

question 2.

There are some files left, which have to be migrated manually:
\dtanalysisserver.ini -> edit and integrate custom settings from old \dtanalysisserver.ini.toBeMigrated
\dtcollector.ini -> edit and integrate custom settings from old \dtcollector.ini.toBeMigrated
\dtfrontendserver.ini -> edit and integrate custom settings from old \dtfrontendserver.ini.toBeMigrated
\dtserver.ini -> edit and integrate custom settings from old \dtserver.ini.toBeMigrated
\server\selfmonitoring\dtselfmon.ini -> edit and integrate custom settings from old
Do NOT re-use the old files, this may cause components not to start!

Do we need to change anything in server.ini,collector.ini from dtserver.ini.tobemigrated,dtcollector.ini.tobemigrated after upgrade.

question 3.

I have disconnected the performance warehouse in client before upgrade.Do we need to perform any activities for upgrading performance warehouse or directly after upgrade we need to just click on test connection and connect.

Appreciate your help.



Dynatrace Pro
Dynatrace Pro

Hi Tarun,

Question 1 -> So, you have a host which is running 6 collector instances and that is where you are having issues? And you were running the migration on the host? You might need to run the migration tool on each instance instead.

Question 2 -> That issue happens when you make custom changes to your .ini files. Compare the two (the .ini and the .toBeMigrated) files for each case and see if there any major differences? If not, you can delete the .toBeMigrated file and keep the .ini file. If there are differences, be sure to make those changes to the new .ini files and then delete the .toBeMigrated files.

Question 3 -> You just need to click test connection and connect. When you do that, it will automatically make the required changes to the DB and you should be good to go.

Hope this helps,



Hi Tarun,

Hopefully these answers sort out your questions

Question 1) I'm not sure why your usage of dynatrace_migration.jar isn't taking the instances - the default behaviour of the tool should be to take everything.
have you checked "<DTHomeNew>/collector/instances" to see if there is a folder for your instances? These should have been migrated accross.

if they weren't you could try manually specifying to migrate collectors using the -migrateInstances Collector Instances option


java -jar dynatrace-migration.jar -migration -sourceArchive "<ARCHIVE_DIR> /<MIGRATION_ARCHIVE>" -targetDTHome "<DT_HOME_NEW>" -migrateInstances CollectorInstances

It is worth checking if the instance folders are there as I suspect the instances may have been migrated, just the services are not registered in windows?

Question 2)

After the upgrade compare your new dtserver.ini to the dtserver.ini.toBeMigrated.
This is to make sure you had no custom options that were added to the old .ini files that the migration jar may not have known about, such as custom memory settings or debug flags.
If there are any additional server options or debug flags in your .toBeMigrated file then you should add these manually to new file.

Question 3)

When the performance warehouse is reconnected, the schema will be updated automatically for you.
However this makes it hard to rollback beyond this point as you would need to do a db restore from a backup if you wanted to fail back to the old version of AppMon for whatever reason so it is recommended to check that the new version is working as expected before reconnecting the performance warehouse.

After you connect the performance warehouse it will be upgraded to the new version 🙂

Best regards


Sorry for the duplicate answer, you obviously type faster than me Ari 😉

Haha I did have a 5 minute head start 🙂 Your answer to his first question is better than mine anyway

Thanks Ari for your was helpful

Hi Henry,

I checked "<DTHomeNew>/collector/instances there are collector instances migrated from old instance but when I checked in the init.d folder to start those collectors I am seeing only default collector.

By the way it was in the Linux.


Hi Tarun,

The init.ds wont be copied by default, you will need to either update your existing init.ds to point to the new installation, or adapt the init.d script from the new installation for each of your collector instances,

e.g. copy the default /init.d/dynaTraceCollector to /init.d/dynaTraceCollectorInstance01 (or whatever you want to call it 🙂 )

then add these lines:

DT_OPTARGS="-instance instance01"

These steps are detailed in our docs on this page:
under "Install Extra Collector instances" and then "Linux / Unix"

Best regards,

Dynatrace Champion
Dynatrace Champion


See section 5.4 on registering/auto-starting the instances.

And you should apply the latest Update before you reconnect the DB to minimize the number of schema updates.