What Did Healthy Look Like? If you're a DBA, you've probably sat in this meeting. Someone senior puts up the strategy slide. We're moving to the cloud. There's a reason (usually cost, sometimes a data center lease that's running out), a logo or two, and a cutover date. Everyone nods. And you're sitting there with a list growing in your head. Linked servers. Agent jobs nobody has touched in years. Logins, and every permission that came with them. The SSIS packages someone wrote before they left. The app that still needs an old compatibility level. Backups, maintenance, monitoring, and who's on call the weekend it happens. That list is the migration. Every item on it is something you have to find, script, test and carry across, usually while keeping the current system running. It's a big enough job that it fills every hour you've got. I rarely get to help a team before the chaos starts. I usually arrive in the middle of it, once the holes in the plan have started to show. And there's one hole I see more than any other: nobody captured what healthy looked like before the move. How long the jobs take, where the waits are, which reports have always been slow. It's rarely on anyone's list, and it's the one that comes back to you. A couple of weeks after cutover, the ticket arrives. "Everything feels slower since the migration." And it lands on your desk. Maybe it is slower. Maybe the instance is undersized, or the storage isn't what the old hardware was, or a setting didn't come across. Or maybe the month-end report has always crawled at 4pm, and you know that, but you can't prove it. So you're stuck saying "I don't think so" when someone asks whether the move was a mistake. I get why it drops off. Skipping it doesn't break anything on the night. Everything else on your list does. Or maybe you never had that visibility to start with outside of your experience with the server. What I've seen help is getting it onto the plan itself, as part of the cutover criteria, so it has a date and an owner like everything else and isn't one more thing you're quietly doing in the evenings. A few weeks of wait stats snapshots, CPU, I/O, and the run times of the jobs and reports people actually complain about, with a month end inside the window. It pays off before the move too. You size the new server on what the system actually does, you know which jobs to watch on cutover night, and you know what the numbers should look like when you check the new server the next morning. Then when the ticket comes in, you've got something to point at. So, for the DBAs who've been through one of these: what do you wish you'd captured before the old server was gone? Laura Copeland Join the debate, and respond to the editorial on the forums | 
