Leveraging DBA IDEs for Complex Migrations

[WHIMSICAL MUSIC] I know you got to run, right? Yeah. My last question for you is, if you were-- my intent is to try and help people make their migrations easier. Is there a way to leverage DBA IDEs-- clients, DBA clients-- to lift the burden for complex migrations? So with an IDE, what you're doing is you're upping the productivity of that individual, right? That's the point of those tools, to make it easier to do your job. So if you're talking about migration, you need to make sure that your tools are working with your target and your source. right? I mean, that's probably the easiest way that they can uplift you through that process, whether that's versions of the same software on-prem, in cloud, totally different platforms-- you want something that's going to-- you can stay within that tool, and it has a tool set for you for both sides of the equation, so that you're going to get whatever benefits you can from it, or the most benefit. So early on in your project, you should be scoping out software, and in terms of the target, new-- where you migrated to. Yeah. Not only what have I been using, but what can I use on the new thing? Can I use them both in the same tool? There's a lot of options out there, depending on what you need, but you should definitely be looking at that as part of the migration. And again, if you find it all in the same tool, you're going to be so much better off, because again, one tool that you can work with both, it's going to cut time down immensely on your daily tasks. Julie, thank you so much. I know you-- Sure. Oh, yeah. I mean, without a tool and an IDE that's going to work in both-- you got an IDE that works in both environments. Now you know the old and the new, and you can work with it, and manipulate things the same way. It's all going to look the same. Otherwise, now in addition to the migration and whatever learning curve you have because of the migration, you've got a learning curve because now you've got to do all your tools differently. So having the same tool in both environments, if at all possible, is a great thing, or knowing what tools are available. You know, you need to do something, it's nice to know, oh, I use this tool to do that, or know there isn't a tool, so I have to go through the manual steps and figure it out. And again, sort that out ahead of time during your planning, so you know what's happening during your planning. I'm not as familiar and never been as deep into the actual database IDEs, but having spent all the time I have from a data modeling perspective, I think there's a lot of similarities there. And we see the proof in the pudding that the database vendors want us to support their products. And not just the ones that we've supported historically, going version to version, but they want us to support their new database products, or these different vendors that have database products. And it's exactly that, the ability to be able to facilitate and accelerate and assure a migration and taking off one thing off the list, which is learning a whole new way of doing things, once you're there or through that process, has a major impact. So we see that in the data modeling world, where the ability to reverse engineer a schema-- and again, we're not talking about the entire database when we talk about data modeling, but the schema is a big part of it, and all of the different physical objects that are out there that you can model-- the ability to reverse-engineer that, and then use the technology to automate transforming that to a completely different target, or as much as can be done. You know, things like data-type mappings, and stuff like that. All of that is going to take time. And if you can rely on the automation that's been sort of codified in a tool, tested, and proven, then you're going to get to the end line faster for sure. Yeah. Yeah. Huge, huge burden lifted.