Separate what is known from what still needs verification

Database health, in a business context, means whether the data store underpinning your system is reliable enough to support whatever you plan to do next. That might be adding new features, connecting to another application, migrating to a modern platform, or simply continuing to run the business without unexpected outages. It is not a single metric. It is a judgement formed from several observable characteristics: structural integrity, data quality, performance patterns, backup reliability and access security.

The assessment itself is a read-only diagnostic exercise. Nobody should be writing to or altering the database during this stage. The goal is to understand what you are dealing with before committing to a modernisation route, a vendor takeover or a new integration. Without this step, cost estimates and timelines for any downstream work are essentially guesses.

Who conducts the assessment depends on what is available. If you have an internal technical team or a retained DBA, they can run the queries and interpret the results. If not, you will need a supplier or contractor with direct experience of the database engine in question — whether that is SQL Server, PostgreSQL, MySQL, Oracle or something less common. The business stakeholder's role is to define what matters: which tables hold critical commercial data, which processes depend on which views or stored procedures, and what tolerance the business has for downtime or data loss.

Access is often the first practical barrier. The current supplier or internal IT function may restrict direct database access, offering only exported reports or an admin panel instead. A meaningful health assessment generally requires read-only access to the database instance, access to error logs, and visibility of the backup regime. If these cannot be obtained, that limitation itself is a significant finding.

When an Assessment Is Needed

The most common trigger is a planned change: a legacy system is being modernised, a vendor is being replaced, or a new integration requires direct database access. Assessments are also useful when performance has degraded noticeably, when a system has been running unattended for several years, or when compliance obligations require you to demonstrate data integrity and retention controls.

What to Examine

Schema and structural integrity. Check that foreign-key relationships are enforced, that there are no orphaned records, and that the schema matches any available documentation. Discrepancies between the documented schema and the actual schema are common in long-running systems and suggest uncontrolled changes.

Data quality within critical tables. Look for null values in mandatory fields, duplicate records, date fields containing impossible values, and inconsistent formatting in fields used for matching or reporting. Focus on the tables that matter to the business, not every table in the database.

Performance indicators. Identify the largest tables, check index usage statistics, and look for tables or indexes with high levels of fragmentation. Review slow-query logs if available. Performance issues do not always mean the database is unhealthy, but they indicate where stress will appear if workload increases.

Backup and recovery posture. Verify that backups are running, that they are stored separately from the live environment, and — critically — that a restore has been tested within a recent, defined period. A backup that has never been restored is an untested assumption.

Access controls and active accounts. List all database users, their permission levels, and when each account was last used. Shared accounts with broad permissions are a common finding in legacy systems and represent both a security and an accountability risk.

Undocumented logic. Stored procedures, triggers, and scheduled jobs can contain business logic that is invisible from the application layer. Catalogue these and flag any that appear to perform critical operations, as they will need to be understood and replicated or replaced during modernisation.

Working With the Current Custodian

If another party currently manages the database, agree in writing that the assessment is read-only and non-destructive. Request a designated point of contact who can explain anomalies the assessment uncovers. Ask specifically about any known issues, recent changes, and whether any tables or procedures are no longer used. The answers — and any reluctance to provide them — are useful data points in their own right.

Common Mistakes

Confusing data quality with database health. A database can be structurally sound and performant while containing poor-quality data. Conversely, clean data in a badly indexed, under-backed-up database is still at risk. Both dimensions need separate attention.

Assessing only the happy path. Checking that core queries return results is not sufficient. You also need to understand what happens when records are deleted, when transactions fail partway through, and when concurrent users access the same records. Error logs and transaction isolation settings reveal this.

Skipping backup verification. It is tempting to confirm that a backup job exists and move on. The only meaningful check is a recent, successful restore to a separate environment. If this has not been done, flag it as a risk regardless of what the backup logs say.

Treating the assessment as a one-time event. Database health changes as data volumes grow, as queries change, and as the underlying infrastructure ages. If the modernisation timeline extends over months, reassess at key milestones rather than relying on a single baseline.

Ignoring the application layer's role. Some database problems are actually application problems: poorly written queries, missing connection pooling, or excessive read-write cycles. Distinguishing between a database that is inherently unhealthy and one that is being used badly affects what you fix and where you assign responsibility.

What this work cannot prove on its own

An assessment conducted against a production replica or a recent backup may not reveal issues that only manifest under live load. If you cannot observe the database during peak usage, note this as a gap. Similarly, if you lack access to application-level logs, you will not be able to correlate database errors with specific user actions. The assessment produces a snapshot, not a guarantee.

Some database engines provide richer diagnostic tooling than others. A modern PostgreSQL instance will expose detailed statistics through system views that an older proprietary system might not. Adjust your expectations and document what could not be checked as well as what could.

Key Checks to Prioritise

  • Can a recent backup be restored successfully to a separate environment?
  • Do the largest tables have appropriate indexes, and are those indexes actually being used?
  • Are there active user accounts with more permissions than their role requires?
  • Does the schema enforce referential integrity, or are there orphaned records in key tables?
  • Are there stored procedures or scheduled jobs that nobody on the current team can explain?
  • Have any tables grown significantly in the past twelve months, and is there a projected capacity limit?
  • Are error logs being retained, and do they show recurring failures?

Leave the next team with verifiable evidence

The output of this assessment should be a written record of findings, ranked by risk to the business. That record then feeds directly into decisions about modernisation approach, vendor negotiations and migration planning. Without it, those decisions are being made on assumption rather than evidence.