Migrating MSSQL Extension to 2.0 Extension - Anyone Done This? Have a Script?

Does anyone have a script that will perform the needed “breaking fix” configuration migrations of the Microsoft MSSQL extension to get to the Extension 2.0 level/schema?

But I was hoping someone has created the needed script that will move the old configurations into the new configuration schema so we don’t have to manually recreate 17 configurations with hundreds of connection definitions contained.

I think it is unreasonable for a vendor to make the customers perform this bulk migration (400+) instances to remain current in the product.
Thank you!
Matt

Are you still running extensions v1 and you want to move to the the v2 extension?

Hi Julius,
We are wanting to update our Microsoft SQL (remote) Extension Version 2.11.8 to 4.0.0 or above - which has the “Breaking Change”. Dynatrace never really provided us a method other than “recreation of your configurations” which we definitely don’t want to hand jam over 400+ instances.
I attempted to vibe code to script this but I am not a developer, nor do I want to have to code a migration of our configurations to stay current with the product. So I figured I’d see if others have already solved this debacle.

Yes, those breaking changes are unfortunate. Are you on SaaS or Managed?

If on SaaS, you could go with dtctl approach, preferably having Claude or Codex do the work with Dynatrace skills.

Understood. I have used DTCTL but not the skills in combination with an IDE and copilot. Has it worked well for you?

I am sure there are many ways to accomplish this, but I was hoping to utilize existing and proven script, rather than trying to develop it ourselves.
Other than the tenant ID and API Token / OAuth keys, this should be pretty portable and easy to leverage in other environments.

Spending time to recreate the wheel doesn’t make sense for customers. We pay Dynatrace licensing and support to develop code for our Observability Solutions. Pushing coding to the customers doesn’t allow us to focus on running the platform itself. Spending time configuring IDE’s, trying to leverage AI vibe coding, isn’t value add for customers choosing to purchase an enterprise monitoring solution platform. Perhaps this is coming in Assist? Maybe Assist, using DTCTL, to build the needed API calls and do configuration based (API only) settings instead of it giving instructions on how to do so? :thinking:

I’d be interested in hearing if other customers have already addressed this bulk configuration recreation, into the new schema, or if some are putting migration off in hopes of an alternate futer path.

We are planning to resolve the breaking changes when upgrading extensions in the first half of next year. It’ll only roll out to SaaS, and I hope that this will be a problem of the past.