This can be done, I'd recommend opening a support ticket with Dynatrace as they can assist you in your transition. You can also transfer settings to new tenants inside of Dynatrace but support can help you facilitate that.
Thank you very much for answering.
They had told me out there that you couldn't take anything from the managed environment to the cloud, that you had to configure everything from scratch.
As you say I am going to ask for support with the support.
I have another query, I am trying to build a Managed environment for personal testing, I ran the installer but it won't let me go without a license.
How could I do it to get me a demo license of about 15 days for Managed environment? Is it possible?
I think while you can get a trial for DT SaaS without any help, for trial of DT Managed you have to contact any sales rep or pre-sales team from Dynatrace.
Also, regarding your migration, I BELIEVE high-level steps would be joining the DT Managed and DT SaaS as a cluster, the wait few days (or few weeks, depending on data retention-policy you have right now) and make sure data-replication has completed. Then remove DT SaaS from the cluster.
But of course, the low-level steps might be more (for example, you might need to use Dynatrace Monaco, you might need to use network zone and/or oneagentctl to change pointing of OneAgent etc etc....)
Anyway, Chad is right: No matter what, in this case you have to reach-out to Dynatrace team or personnel and talk to them about this in a discussion.
It's not that easy to migrate all configuration from Managed to SaaS. In order to do this you need to use:
- REST APIs
- for those parts that are not covered with REST API you need to do it manually or write your own automation
- Convert manually entity IDs if you use them in dashboards, charts, alerting profiles, management zones etc.
Very helpful is project Monaco (monitoring as a code): https://github.com/dynatrace-oss/dynatrace-monitoring-as-code
There's even a fork that deals with entity IDs. Not everything is covered by this tool, but most. We're going to use this internally as well to migrate configuration from Managed to SaaS. You can ask our services solution to help you in that process as well.
Hope this helps!
I've migrated a few environments(tenants) between different setups at large scale. For that I've built an extensive configuration management solution that is able to fetch the complete configuration from one tenant and transport it to another, even considering entity IDs.
You can use this approach to even seamlessly transport configuration from dev to stage to prod Dynatrace tenants. It's irrelevant if this is SaaS or managed, it works with both flavours.
You can find some of the work here: https://github.com/reinhard-brandstaedter/dt-config-mgmnt
Usually fetching and migrating the configuration is just a matter of minutes, its rather straight forward with this solution. It even transports the configuration entity IDs and replicates those to the target tenant so that you don't loose any interdependencies. This is something that other solutions are not doing yet (invented by me, copied by others 🙂
If you need help, let me know!
This is great, great work.
-The migration from one environment to another then is all done through API?
-The destination environment must be completely empty, clean?
-The information of the OneAgent and Active Gates is also migrated?
-If there is a connection problem during the migration, it is interrupted, is it possible to repeat the process?
Thanks a lot.
Hi @Consultor_IT ,
you need to distinguish a few things.
1) Configuration within a tenant: these are all the settings that one would make through the UI usually and where an API exists; this is covered by the solution.
2) The setup of the environment: this is the infrastructure (Active Gates, Oneagents). These you need to deploy/reconfigure (e.g. by running oneagentctl on the installaed hosts to point them to another AG, or by installing reconfiguring AG configuration) - this is not done via APIs
3) Any already collected data stored in Dynatrace: this is a data migration not a config migration, not covered with this solution.
You can migrate configuration and dashboard but not the data. If you still need the data the only way to keep it is to export it via API, e.g. to another time series DB, and keep it there for future reference.
@r_weber Unfortunately the repo https://github.com/reinhard-brandstaedter/dt-config-mgmnt seems no longer available. Has it been moved to somewhere else? I would be very interested in a seamless config migration that is able to handle dependencies on entity ID's automatically....
Hi @Enrico_F ,
yes, I moved it to a different repo, development is now done at https://github.com/360Performance/dt-config-mgmnt
Although we are using this in customer projects actively, documentation is a bit vague to get started with (esp. due to the dependency to the consolidated API service).