dynaTrace 5.6 upgrade

I'm wondering if I can get anyone to quickly browse through my dynaTrace 5.0 to 5.6 migration plan, and if you see anything in there that looks like trouble please let me know.  Also, for anyone looking at making this same migration this may serve as a good example that's a little more concise than the general process found in the migration guide.  Not trying to re-write the migration guide, just trying to create a working example as an adjunct to it.  (Since I have to document what I do anyway.)

dynaTrace upgrade 5.0 - 5.6

First, there are some non standard puculiarities to deal with.

Our Compuware consultant who originally advised on this installation did not use the standard directory location of /opt/dynatrace-<major.minorVersion>. Instead we have /opt/dynaserve03/dynatrace-5.0.0. DT_HOME is set to this value in the init.d/dynaTraceServer script.

I'm hoping the statement made in the migration guide that "The installer will default to /opt/dynatrace-<major.minorVersion>.0." implies I can also override that location somehow. I'm assuming this installation will allow me to create /opt/dynaserve03/dynatrace-5.6.0 and will install a new instance of everything, as opposed to modifying things in /opt/dynaserve03/dynatrace-5.0.0.

The collectors were not installed to any sort of version named directory whatsoever. For example, /opt/dynacollect06 and DT_HOME is set to same in the init.d script. Once again, for upgrade, I assume I should create a new directory like /opt/dynacollect06/dtcollect-5.6.0.

We also have a 'common' dynaTrace analysis server with both our QA and prod installation connecting to it. So the plan is to disconnect the dtanalysis server from QA, leave production connected to it. We will not upgrade the analysis server nor connect QA to it until we do the production environment. From the 'Analysis Server Configuration' doc:

"Upon post-processing of a memory snapshot the dynaTrace Analysis Server is automatically used if it is reachable. If it is not reachable and you are not running a production installation, the snapshot is post-processed by the dynaTrace Server."

So what we want to do is make it 'unreachable', meaning remove the configuration from the 'Services' section of the QA. Unfortunately, the server settings wouldn't let me just remove it. It requires something be there, so I changed it to a nonexistent host and port.

There is a lot of talk about "bootstraped" agents being able to automatically update when they connect to version 5.6 collector, but I could not find a clear description of how to tell what is and what is not a "bootstrapped" agent. As all our agents were installed with version 4.2 or later (most with 5.0) I think they should all be a "bootstrapped" type. Even if so, it is not clearly stated wether or not a restart of the application is necessary before the agent is upgraded.

The exact sequence of dealing with the 5.6 license is at first unclear. It gets clarified a little later in the migration guide, so I believe the sequence is I have to deactivate the 5.0 license while the dT server is running. Then import and activate the 5.6 lincense after migration. Presumably it will let me start the server without an active license in place?

From what I read I understand an older collector can report to a newer server. So to minimize changes and simplify the upgrade I would like to upgrade the server, then restart and confirm operations before upgrading the collectors, which I can then do one at a time.

Upgrade steps for QA:
We have routine daily backups of all components so we should be able to recover to time of last backup. For QA this is acceptable so no additional or specific back ups will be done.
(Note: All operations are run as root user via sudo.)

1. Verify system requirements. The 5.6 version is stated to require 20 - 25% more memory. What we find, however, is that in practice dynaTrace will use whatever memory you give to it, so this does not imply the existing system memory, at 96GB in this case, is inadequate given that it is already 90% utilized. We did increase the number of file handles (ulimit -n).

2. We downloaded a new 5.6 license file for our QA installation.

3. We made the dynaTrace Analysis Server unreachable from QA.
Had to do this by giving the QA service configuration a phony host/port combination. Don't like this, but couldn't find another way.

4. Stop the QA collectors.
There is one local and one remote.

5. Disconnect the performance warehouse.

6. Deactivate the QA lincense.

7. Stop the QA dynaTrace server.

8. Install the 5.6 version. As root user run the following.  This is where I don't see an option to specify the destination folder of the new version.  Hopefully it prompts for it.
java -jar dynatrace-5.6.0.5802-linux-x64.jar

9. Run dtmigration per instruction in migration guide.
java -jar dtmigration.jar -migration -sourceDTHome "/opt/dynaserve03/dynatrace-5.0.0" -targetDTHome ""/opt/dynaserve03/dynatrace-5.6.0"

10. Manually modify the .ini and configuration files with entries from the 'toBeMigrated' files as specified in the migration guide.

11. Start the new server, import and activate the new license and connect the performance warehouse.

12. Start the dynaTrace collectors. Because the dT server hostname and listener port(s) have not changed, and because the 5.0 collector should be compatible with the 5.6 server, everything should work.

13. Repeat this process for the collectors.