What Did Healthy Look Like? (2026-10-24 DBW)

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

The next competitive advantage in enterprise AI has less to do with which model you choose than with what you build around it. That’s an important shift. For the...

Bob Ward recently posed an interesting question on...

At the end of 2025, we launched DAX Lib, a public ...

When I started hammering Azure SQL again, I had a set of scripts to run and tried to figure out what was happening. For most databases, I could explain the results, but some didn’t make sense.

Before any VM, Azure needs a network: a VNet, subn...

I’m back from a great vacation. I had the chance...

If you are migrating a data warehouse, there is a ...

Fabric hands you an entire toolbox, but using all ...

Why the Version Store won’t clear if any databas...

The Perils of Secondary Metrics in SQL Server Chap...

A PostgreSQL superuser can read any file on the se...

Restore to the moment before the disaster using eight parameters that answer where replay stops, which timeline to follow, and what to do when you get there. (I consult...

Please enjoy the slides and transcript from Tuning Postgres for Analytics at PostgreSQL Conference Europe (PGConf.EU) in Valencia, Spain on 20 Oct 2026. I'll add a link to...

When I split the GROUP BY content into two posts (...

Part four of ten. Search used to mean matching wor...