You have a database nobody decided to keep. It started as a side project. Someone in a department needed a quick answer the main systems would not give them, so they built a small thing. A few tables. A form. A report. It worked. People started relying on it, then more people did. Today a real part of the business runs through it. It sits on a server nobody patches, backed up by nobody in particular, owned by a person who may have left.
If a database stopped on Monday morning, would the room be able to name who owns it, what stops, and whether it can be brought back.
Here is the part worth being honest about with yourself. Nothing went wrong to get here. No bad decision was made. The thing grew one reasonable step at a time, and each step was too small to flag. That is exactly why it is dangerous. A risk that arrives in one big move gets noticed. A risk that arrives in twenty small ones gets a desk and a coffee mug and becomes part of the furniture.
You are the manager who can already feel this. You do not need convincing that the side database is a problem. You need the words to take it upstairs, because the answer you will get is the answer you always get. It has worked fine for years, why spend money on it now. So name what “fine” is hiding. It works because one person knows how it works. It works because it has never been tested. It works the way a ladder with a cracked rung works, right up until weight lands on the wrong spot.
Frame it for the people who control the budget, and frame it as ownership, not technology. Ask three plain questions out loud. If this database stopped on a Monday morning, which part of the business stops with it. Who, by name, is responsible for it today. When did anyone last confirm it could be brought back. If the room cannot answer those quickly, you do not have a database problem. You have an accountability gap that happens to live in a database, and that is a sentence a board understands.
Then make the ask small and specific, because a small ask gets a yes. You are not asking to rebuild anything. You are asking to find out where it actually sits, who depends on it, whether it is backed up, and whether that backup has ever been brought back to life. With that, you can re-home it on purpose. Give it a real owner. Give it a real backup and a real place to live. The same system, decided on rather than drifted into. The cost of doing this on a calm Tuesday is a fraction of the cost of doing it during the outage that forces the question.
If you want a clear-eyed read before you make the case, that is the easy part. We will run a free, read-only health check on the SQL Server in question. Fifteen minutes, no changes to anything, no obligation, and no sales call chasing you afterwards. You get back a plain-English report, graded, that says what is solid and what is quietly holding the weight of a department it was never built to carry. Take that into the meeting and let it do the arguing for you.
Want to know if this is sitting in your estate? We run a read-only check and hand you a graded report in plain English.
Get your free health check