Question about SaaS Upgrade Assistant and 'successful' configurations

[TomLichti]

I just watched the Youtube video on the new SaaS Upgrade Assistant app, and it looks amazing! I do have a question/concern though. It looks quite easy to see what items failed, and how to potentially fix them. What I would like to know is about the items that were 'successful', but didn't actually import, for example as shown in the video, dashboards that were owned by admin, and the ownership had to be updated and then re-run the upgrade. These types of 'failures' (I use quotes because it was not highlighted as a failure) are the worst kind to try and figure out, as they appeared to be successful. How do we figure out what items were successful, but actually failed? I think in the dashboard specific case, it should fail, so it can be identified and remediated, like the issue with the synthetic monitor. Why does importing a dashboard with an invalid owner work, but importing a synthetic monitor with an invalid activegate fail? 

We can probably come up with more items that could successfully fail, but if there is a tool, should the tool be able to do that for us? Don't  get me wrong, this is going to make upgrades significantly easier, but devil is in the details as they say.

[Radoslaw_Szulgo]

Thanks, @TomLichti for positive feedback and improvement suggestions. 100% agreement from me and my team. Within Dynatrace configurations, there are "soft" and "hard" dependencies. Hard dependencies just fail on the REST API level, for example: a synthetic location and AG ID or network zone - alternative network zone. A soft dependency doesn't block the creation of a configuration, for example: dashboard ownership. 

We're still developing the app and we plan to notify on wrong ownership of dashboards - the prerequisite is to check what users are already added in the SaaS identity management. Moreover, we'll try to pull out Managed users and automatically update ownership if possible.  

I'm not aware of any other "soft" dependencies. If you've found some - let us know, please!

[TomLichti]

Hi @Radoslaw_Szulgo , as I said, I think this is an amazing tool, and thanks to you and your team for building it! I can't think of anything off the top of my head that might fall into the 'soft' dependency category, obviously anything owned by a user would be a candidate, but other than dashboards, I can't think of anything else that is owned by a particular user.

I have not been able to test an upgrade yet using the tool, but I know in the past Monaco had limitations with key service requests, and also non-global service request naming rules. Are those still an issue?

Tom

[Radoslaw_Szulgo · Accepted solution]

We’re actively working on covering whole configuration by Monaco to make it available in the app. Recently we’ve added network zones, soon we will have RUM missing configuration incl. key use requests, and others.

[TomLichti]

I thought of another potential ownership issue, access tokens. If they included in the export and upgrade, how is the ownership managed for those items? If they aren't, that is a gap.

[Radoslaw_Szulgo]

Tokens and other configurations that include passwords are not exportable currently due to security reasons. Currently they must be recreated manually. We’re thinking how to solve this in future.