First Time? Consider "The Business" side

[AUDIO LOGO] Hey, Julie. Listen, Clay. Types of database migrations-- is there anything you could point me towards? I'm guessing there's three-- Big Bang, trickle hybrid. Are there other types of database migrations? Well, I mean, it's a spectrum. It's a complete spectrum. It's not just what are you migrating. I've heard people refer to migrations going from the same database platform on prem to the same database platform in the cloud. They call that a migration. I've heard. But if you're changing platforms, if you're changing intent, if you've looped in other scope as part of the migration, maybe you're doing some normalization of the database or even some data cleanup, then that changes everything. So it's a spectrum. It's as little as you want or as much as you want. And I've heard people also just call patching migration. I'm applying a bunch of patches, but I'm migrating from one version to another, migrating to this patch or whatever. That's going to take 12 months. So Yeah. Oh, yeah. That's totally true. I've heard the same thing where they say, we're migrating the database. I get myself up for a big meal of a conversation and they're talking about just updating to a new version, which is not nothing. But I wouldn't put it in that migration category. So it's all about how you tackle that word in that effort. Is there anything that you would point me towards to book? Is there anyone? Clay, I'm guessing. Clay is a fountain of knowledge. Is there anything you can point me towards to help me out here? Read the friendly manual-- seriously, all the manuals you've got. I mean, upgrade notes, upgrade release notes-- anything and everything you've got. Read it. Read [INAUDIBLE] and inwardly digest the manual. That's going to be the main wealth of information. And then also Quest has a bunch of blogs on migrations and data movement and things like that can help you. But the big thing is the manual and particularly the release notes for whatever you're doing. And that's on the technical side, which I totally agree with. But then from the business side, what I always say is, what are you trying to accomplish, what are your priorities, how big are how small is your scope. Scope creep is so real in every aspect of life, unfortunately. So clearly delineate what your goals are. Are you trying to move to the cloud? If that's your number one priority, then pick the simplest way to get there if possible. And then do other projects to do database changes or new requirements on functionality, et cetera, so what are you trying get to. Write it down, write it down. Write it down, and say it often. Start every meeting, just to remind people why you're here. Do you think the business sees a database-- they don't call it a database migration. Do they just call it as like, we're getting a new app, or they're migrating something. Do they just see one thing? I think the business in particular sees whatever they want to see, which is kind of the problem if it's even in front of them. So there might be a migration. It's like, hey, we're migrating over the weekend so you won't be able to get into your services. And they even know about it. It's just something that tech is doing. It's an update, or it's a move. But if it's something that the business is involved in, like, hey, we're migrating. And therefore, we need your input, then they're going to be involved in it. And you have to keep them on focus. You have to keep them into the priorities because they can dreamscape a whole new world, which is we're wont to do when we have conversations. And so you just have to keep them, well, our number-one goal is to get to the cloud. So let's just lift and shift over to the cloud exactly as is. And then everything else we can put off to later, or we have a little bit more bandwidth, a little more time. We can actually make some improvements along the way, that kind of thing. Or maybe you're migrating to a whole new version of an application, and the business is expecting all sorts of bells and whistles and new features and things like that. So [INAUDIBLE]-- An application migration. Yeah. Either one, yeah. OK. I was thinking about just in the back end, but Yeah, from the front end, they have all their dreams and hopes pinned to that new version. It depends. Yeah I think that Julie's statement to begin this off from a business perspective is why are you doing it. Because I think it's going to inform a lot of it because you need to do that analysis up front, at risk of sounding like a broken record, because there's a lot of different ways to do that. And you're going to make those decisions based on what's driving it. So why are you doing it, what's the net result. As you said, if it's a whole new application, if we're taking an application and doing things in a whole new different way and we want that way there on day one, then we may have to do a certain amount of work in order to get there. Or can we just migrate the data to the new platform and then start working on it? Again, it's the why and [INAUDIBLE]. And what are the constraints? So maybe we're moving because we want to change our licensing agreement, and there's a deadline on that. So we can only accept so many requirements. We have to get there by October 1 because the other thing is going to get turned off, whatever it is. So understanding those front and center. I would not include any change requests if you're on that time frame. That's just