Migration Project Plan - Risks

[MUSIC PLAYING] I'm working on a bit of a project here. I wanted to give this-- you've seen this before, this project plan that I'm working on. Yeah. And what I've done is I've collected risks, put them into a chart. I wanted to ask you a quick question on all of these risks. There's only a few of them. Quick fire buzz around. How likely are these to occur? OK. So probability of occurrence. You can see high, medium, low. OK? Now, there's no caveats because I know what you're going to say. You're going to say, Mike, if you do spend enough time and planning, the likelihood of these occurring is low. OK. So you can't say that. [LAUGHTER] OK? On your experience, in the projects that you've been involved in, OK, you can use that. You can use that. Yeah. OK. So it's not advice. It's not future advice. This is from your past. Sure. Yeah. So data loss or corruption, how many times has that happened? How likely is it due to occur? Oh, I think that's pretty low. I mean, even the simplest copies or things like that are going to have some checking and things like that. And of course, CrowdStrike notwithstanding, but yeah, I think that's fairly low. That's not going to happen all the time or very often, I don't think. OK. I think the risk of impact is very, very high. Oh, yeah. Yeah, absolutely. [LAUGHS] Again, CrowdStrike, right? All right. Yeah. Downtime overruns. I'd say that's a given. Probability of occurring. [LAUGHTER] OK. That's a given. It's high. It's going to happen. Somewhere you're going to do that. I've only seen one or two projects that came in under the downtime. And even in that case, it was a case of well, OK, we think we're going to take four hours of downtime. Let's tell a user we're going to take six. [LAUGHS] And then we overran the four by 15 minutes, but so what? The user was expecting six and we told them, oh, here you are. You're an hour and 45 minutes early. OK, great, but that's a case of managing expectations, right? Good. You're good. So. [LAUGHS] Right. Right. OK. The actual overrun is always going to happen. Performance-- yeah. Right. Performance degradation. I'm told that this will always happen. Post-migration, there's so many levers within the database, that it's impossible to catch. What's your experience? I disagree. Well, I mean, OK, I guess it depends on your definition of performance degradation. Significant performance degradation, I'd say, is probably a medium probability of occurrence. OK. And the risk could be medium to high. But again, if you've done your testing and you've done your testing right, you'll know that ahead of time and you will have mitigated-- No, you're not allowed to say that. --any big things. [LAUGHS] Clay, you're not allowed to say that. [LAUGHS] Yeah, I know but [LAUGHTER] Budget overruns. Probability of occurring? In your experience. Low to medium. OK. Low to medium. All right. Again, if you plan right. Yeah. Yeah, yeah, yeah, yeah. I remember that. Incompatibility of new database, in your experience in the past, probability of occurring. [LAUGHS] I'd like to say low, but the reality is it's high. I mean, again, if you've done it right-- the one I remember and I bring up all the time is, getting data out of an Oracle Database into a SQL Server database and-- definition in the Oracle Database was a number with two decimals, right? You know, 8.5 or 8.51 or something like that. The DBA says, oh, no, I know that field. That field is always going to be an integer. Don't worry about it. Five minutes after the conversion starts, somebody puts a 1.5 in the field. The target database chokes and says, wait a minute, you just told me put a floating point number in an integer field. I can't do that. Or a vendor, they're taking their own application and they're porting it from Oracle to SQL Server. Well, they built the SQL Server side and they did the right thing and they said all these columns have got to be not null because, oh, yeah, there's got to be data in there, got to be data in that field, got to be data in that field. So they got all these columns with not null. So we go make a copy. First time we make a copy of the data from the Oracle Database to SQL Server database, SQL Server database chokes. Wait a minute, you're telling me to put a null value in a field that's supposedly not null. And this was a vendor where the database was supposed to be the same database, right? Come on. You know? [LAUGHS] Yeah. Yeah. But that goes back to lack of proper planning and lack of testing. [LAUGHS] Would you argue modeling? Yeah. Yeah. Would modeling have fixed that? Oh, yeah. Yep. Oh, yeah. There you go. So, Clay, your top three tips for successful data migration is holding, OK. Security vulnerabilities. Probability of occurring. 100%. [LAUGHS] I mean-- Really? Really? Yeah. Oh, yeah. I mean, nobody is perfectly patched. Or if you are perfectly patched today, you're not going to be perfectly patched tomorrow. The bad guys are always going to come up with something or some really wild-- That's true. --esoteric workaround that nobody's thought of before. Again, you mitigate the risk. You apply all the latest patches. You do all those things ahead of time and the probability of it biting you is fairly small. The risk can be minimized, but-- OK. Project delays. --it's going to happen. Project delays. I'm going to assume high. Yeah. Oh, yeah. Again-- But no, you can't say planning. [LAUGHS] In your experience. Well, no, because there's always things you can't plan for. Somebody gets sick at the last minute. There's a rainstorm and the streets flood and