What indicates an incomplete qTest upgrade after a failed migration?

When a qTest upgrade is interrupted, administrators must decide whether the environment can be safely used or requires a rollback to the pre‑upgrade database backup. The upgrade guide describes stopping services, applying patches with qtestctl, and restarting services, but it does not define a concrete signal that confirms the migration finished without partial schema changes. Teams often rely on log inspection or manual testing, yet it remains unclear which specific indicators—such as version tables, stored procedure states, or qtestctl exit codes—reliably distinguish a clean upgrade from a failed one.

Which database objects or version metadata should be examined to verify a complete qTest schema migration? Does the qtestctl tool return a distinct exit code or log entry that unambiguously indicates upgrade success versus failure?