The Self Hosting Readiness Checklist for Test Case Management

A QA lead we will call the usual case: a team of eight, a Kiwi TCMS or TestLink instance someone spun up two years ago, and a Friday afternoon where the login page returns a 500. Nobody in the room knows which of the three people who touched that server still works there. This self hosting readiness checklist exists so that conversation happens in a planning meeting instead of during an incident. It will not tell you whether self hosting is right for you. It will tell you, in about ten minutes, whether you are actually ready to try it.

Consider a smaller, more common version of the same story. A team of five picks Kiwi TCMS because it is free and the feature list looks complete. Someone spins up a container on a shared VM on a Tuesday afternoon. It works fine for eight months. Then the VM's disk fills up during a company wide backup job, and the instance goes read only. Nobody notices for three days, because nobody owns monitoring for it. That gap between "it works" and "someone is accountable for it" is exactly what this checklist finds before it costs you a release.

How to use this checklist

Answer every item below with a name or a number. "The DevOps team" is not a name. "We would sort that out" is not an answer, it is a no. Go through the six sections in order. Tally the honest answers. Read the last question before you decide anything.

The infrastructure items

Three things need a concrete owner before you install anything:

• Where does it run: a specific VM, a Kubernetes namespace, a laptop under someone's desk (this happens more than teams admit)
• Who patches the host operating system, and on what schedule
• What database backs it, who owns its version upgrades, and how much disk headroom it currently has

If any of these three map to "IT will handle it" without a named person, that is your first honest no. Write the name down now, not the department. A vague answer here is usually a sign the other five sections will be vague too.

The continuity items

This section is about what happens after something breaks, not before.

• What is the backup schedule, in hours or days, not "regularly"
• Where do backups actually live, and is that location outside the same host that could fail
• When was a restore last actually performed, not just a backup file confirmed to exist
• How long does a full restore take, timed, not estimated

A team that has never restored from backup does not have a backup. It has an untested file. That distinction is what turned a Friday evening outage into a lost weekend for the team in our opening example.

Nobody had ever pulled the backup down and rebuilt the instance from it. So the first real restore attempt happened live, under pressure, with three engineers guessing at the process.

The lifecycle items

Software needs upgrading, and upgrading is where self hosted installs quietly drift years behind.

• Who decides when to upgrade, and how often does that decision actually get made
• Is version pinning available, so an upgrade can be scheduled rather than forced
• What is the rollback step if a new version breaks something on a Tuesday morning

If the honest answer to the second question is "whenever someone remembers", write that down. It matters later. It usually surfaces around the time a security patch is six months overdue.

By then nobody wants to be the one who finally applies it untested. So it slips another quarter.

The access items

Access control questions surface fast once you actually sit down with them.

• How do people sign in: SSO, local accounts, something improvised three years ago
• What is the actual, tested process when someone leaves the company
• Who holds the admin credential, and what happens to that answer if that person is unreachable

A surprising number of teams discover, mid checklist, that the answer to the third question is a single engineer who left for a new job last spring. That engineer never handed off the password manager entry, and nobody noticed until the next admin task came up.

The data items

Self hosting is often chosen for data control, so this section should be the easy part. It usually is not.

• What data actually leaves your network, including any AI powered feature and where that call goes
• Has an export carrying full run history ever actually been tested, not just assumed to work
• Who has verified that export opens cleanly outside the tool itself

An export that has never been opened is the same problem as a backup that has never been restored. Traceability and audit evidence only count if you can pull them out under pressure.

A regulator or an auditor asking for six months of run history on a Thursday afternoon is not the moment to discover the export script was broken since March.

The last item, and the one that actually decides it

Every section above is infrastructure. This one is not. Name the specific person who gets called when the instance stops responding at 6pm on a Friday. Not a team. Not a rotation that has never been tested. A person. Now confirm they know that is their job. If you cannot answer this one cleanly, the rest of the checklist does not matter yet.

This is the question that separates teams who merely installed a tool from teams who actually run one. The infrastructure exists to make this one answer boring and reliable. So do the backups. So does the upgrade cadence.

Without a named person on the other end, all of that groundwork is decoration.

It is fine to fail this checklist

If you counted more no answers than yes, that is a useful result, not a failed exercise. Self hosting a test management tool is a real, ongoing operational commitment. It sits on top of the testing work you were trying to get to in the first place.

Choosing a hosted option because your team does not have a named person for Friday evenings is not giving up. It is an accurate read of your own capacity. It is a decision worth making on purpose, instead of by accident eighteen months in when the first real outage hits.

The teams that regret self hosting are rarely the ones who failed this checklist honestly and chose hosted instead. They are the ones who never ran a checklist like this at all. They installed the free option because it was free, and found out about the gaps during the incident rather than before it. Whichever way you land, a test case management tool should make its own hosting story boring, not add a second source of on call risk to a team that already has one.