Why Healthcare IT Is Turning to Database DevOps

The COVID-19 pandemic placed extraordinary pressure on healthcare IT teams in 2020. With budgets constrained, staff stretched thin, and demand for remote patient services surging, engineering organizations were forced to accelerate digital transformation faster than originally planned. According to Redgate Software’s 2020 State of Database DevOps Report for the Healthcare sector, one clear response to this pressure was a measurable increase in DevOps and database DevOps adoption.

The need to rapidly develop and deploy telehealth platforms, provide reliable access to electronic health records (EHR), and maintain strict compliance with data protection regulations pushed healthcare IT teams to standardize processes and lean on automation. Database DevOps — extending software delivery best practices to include the database layer — emerged as a practical answer to these challenges.

Key Findings from the 2020 Healthcare Report

1. DevOps Adoption Is Outpacing Other Sectors

The report found that 70% of healthcare respondents had adopted DevOps across all or some projects, or had a Proof of Concept (PoC) in place — slightly ahead of the cross-industry average of 68%. More significantly, 41% had moved beyond the PoC stage, compared to 36% in sectors such as government and financial services. This suggests that healthcare organizations are not just experimenting with DevOps — they are operationalizing it.

2. Healthcare Leads in Database Automation Adoption

The healthcare sector ranked ahead of other industries in adopting automation across the database development lifecycle. Survey respondents cited the following as the top three drivers for automation:

• Freeing up developer time — cited by 27% of respondents
• Increasing speed of delivery — cited by 22%
• Reducing the risk of data loss — cited by 13%

The emphasis on data loss prevention is notable given the sensitivity of patient health data and the strict regulatory environment healthcare organizations operate in, including requirements under HIPAA in the United States.

3. Cloud Adoption Is Growing but Still Maturing

42% of healthcare respondents reported using cloud infrastructure in some capacity. While this figure is comparable to other industries, Redgate’s analysts noted that cloud adoption in healthcare is likely to accelerate as remote service delivery becomes the norm and DevOps practices make cloud-native deployment more accessible to teams that previously relied on on-premises infrastructure.

4. Version Control Is Becoming Central to Compliance

58% of respondents reported having version control measures in place for database code. Version control for database schemas and scripts enables automated builds and deployments, and serves as a foundational component for compliance auditing. When database changes are tracked in source control, teams can demonstrate repeatability, traceability, and the elimination of ad-hoc manual changes — all of which are critical requirements in regulated industries.

In practice, this means treating database migrations and schema changes with the same rigor as application code: committing changes to a repository, running automated validation, and deploying through a controlled pipeline rather than applying changes directly to production databases.

5. Database Deployment Frequency Is Increasing Significantly

51% of healthcare respondents reported deploying database changes daily or weekly in 2020, a significant increase from previous years. Among North American respondents specifically, 55% said they deploy database changes daily, weekly, or on demand — a figure that points to the rapid adoption of Agile and continuous delivery practices to support frequently changing clinical and operational applications.

“What’s surprising this year is the way North American respondents are surging ahead, with 55% saying that they deploy database changes daily, weekly or even on demand. This indicates that they’re embracing Agile practices to better meet the needs of doctors, patients and remote services like telehealth that rely on these databases each day.”

— Kendra Little, DevOps Advocate, Redgate Software

What Database DevOps Means in a Healthcare Context

For most engineering teams, “DevOps” primarily refers to application code pipelines: continuous integration, automated testing, and continuous deployment. However, the database layer is often excluded from these pipelines, becoming a bottleneck where changes are applied manually by a DBA, are difficult to roll back, and are poorly audited.

Database DevOps addresses this by bringing the same practices to the data tier:

• Source control for schemas: Database objects (tables, stored procedures, views) are stored in version control alongside application code.
• Automated schema comparison and migration: Tooling compares the target database state with the desired state and generates safe migration scripts.
• CI/CD pipeline integration: Database changes are validated and deployed through the same pipeline as application changes, ensuring consistency across environments.
• Drift detection: Automated checks identify when a live database has diverged from its source-controlled definition, a critical capability for compliance.
• Rollback capability: Because changes are scripted and versioned, rolling back a bad deployment is planned for rather than improvised.

In healthcare specifically, these capabilities support compliance frameworks by ensuring that every database change is documented, reviewed, and reproducible — reducing the risk of audit failures or data integrity issues that could compromise patient safety.

The Compliance Dimension

Healthcare organizations must navigate complex regulatory environments. In the United States, HIPAA mandates strict controls over how protected health information (PHI) is stored, accessed, and modified. In Europe, GDPR applies. Many organizations are also subject to additional industry-specific standards.

Database DevOps practices directly support several common compliance requirements:

• Audit trails: Version control history provides a complete record of who changed what and when.
• Access control: Pipeline-based deployments remove the need for developers to have direct write access to production databases.
• Repeatability: Automated deployments are consistent and deterministic, reducing the risk of human error that could introduce vulnerabilities.
• Data masking in non-production environments: Tooling can ensure that sensitive patient data is masked before being used in development or test environments, so PHI never leaves the production boundary unprotected.

Telehealth as a Forcing Function

The rapid expansion of telehealth services during the pandemic created an immediate engineering challenge: systems that were designed for in-clinic use had to scale for remote access, often with little lead time. Backend databases supporting appointment scheduling, patient records, billing, and clinical workflows suddenly needed to handle greater load, more frequent updates, and integration with new front-end applications.

Teams that had already adopted database DevOps were better positioned to respond quickly — deploying schema changes to support new features, adding indexes to handle increased query load, and integrating new data sources through controlled, automated pipelines rather than through emergency manual interventions.

About the Research

Redgate Software has published its State of Database DevOps Report annually for over four years. The 2020 edition gathered responses from developers, database specialists, and IT leaders across multiple industries and company sizes globally. The healthcare sector findings represent a subset of that broader dataset, enabling sector-specific comparisons against cross-industry benchmarks.

For the full healthcare sector findings, refer to Redgate’s official report publications at red-gate.com.

About Redgate Software

Redgate Software, headquartered in Cambridge, England, develops tools for database development and DevOps, with a focus on Microsoft SQL Server environments. The company’s tooling is used by IT professionals across organizations of all sizes to automate database deployments, enforce version control, and maintain compliance. According to Redgate, its tools are used by more than 100,000 companies, including a significant proportion of Fortune 100 organizations.

Too many IT workers operate under a cloud of fear and frustration. The 2017 congressional testimony from the former Equifax CEO — in which he pointed to a single IT employee as the cause of one of the largest data breaches in history — illustrated exactly why that culture persists. The DevOps Enterprise Summit (DOES) 2018 offered a very different picture: one where engineering teams are empowered, data-driven, and increasingly willing to challenge long-held assumptions. Here are three substantive lessons from that event.

1. Legal Teams Can Be Engineering’s Ally in Legacy Modernization

Anne Bradley, Nike’s Chief Privacy Officer, and Courtney Kissler, Nike’s VP of Digital Platform Engineering, delivered one of the conference’s most memorable sessions. Their topic: how to kill legacy systems that the business has been unwilling to retire.

Their approach was counterintuitive. Rather than building a purely technical case for decommissioning aging infrastructure, they framed the problem in legal and financial terms. Anne Bradley introduced the concept of negative ROI — calculating the expected cost of regulatory fines if a non-compliant legacy system remained in production. Modern data privacy regulations (such as GDPR and similar frameworks) create real, quantifiable financial exposure for organizations running systems that cannot meet current compliance standards.

Courtney Kissler used that legal and financial analysis to build an executive-level business case for shutting down the offending systems. The retirement was celebrated with an Irish wake, a cake, and poetry — a cultural signal that ending a system’s life is worth acknowledging, not mourning.

The practical takeaway: Engineers often fail to retire legacy systems not because the technical argument is weak, but because they fight the battle alone. Partnering with legal, compliance, or risk management functions transforms the conversation. When a legacy system carries a potential fine measured in the hundreds of millions of dollars, decommissioning it stops being a technical debate and becomes a straightforward risk decision. Look for allies outside your team when you need to drive modernization.

2. Databases Must Be Part of Your DevOps Transformation

Dr. Nicole Forsgren and Jez Humble from DevOps Research and Assessment (DORA) presented findings from the 2018 State of DevOps Report. One of the more noteworthy additions to that year’s research: the role of the database in DevOps performance.

The DORA research found that organizations actively incorporating database practices into their DevOps initiatives — version-controlling schema changes, automating database deployments, and treating database changes with the same discipline as application code — showed a positive correlation with overall IT performance.

Equally important was a finding about universality: database practices were described as non-differentiating in terms of where an organization sits on its DevOps maturity curve. Whether you are just beginning your DevOps journey or are already operating at an elite level, addressing your database practices produces measurable benefit.

The practical takeaway: Database changes are frequently the last piece of an otherwise automated delivery pipeline to remain manual. Schema migrations applied by hand, change scripts stored outside version control, and database deployments requiring a separate approval window all introduce risk and slow down releases. If your CI/CD pipeline handles application code but still treats the database as a special case, that is where your next investment should go. As the familiar saying goes: the best time to plant a tree was twenty years ago; the second-best time is today.

3. External Change-Approval Processes Hurt Software Delivery Performance

Nicole Forsgren’s book Accelerate (co-authored with Jez Humble and Gene Kim) attracted significant attention at DOES 2018. One distinguishing characteristic of the book is its foundation: years of empirical survey and analysis data, rather than anecdotes or vendor-sponsored case studies. None of the three authors worked for a technology vendor at the time of publication, which reduces the usual conflicts of interest found in this genre.

One of the most striking findings — discussed in detail in the book — concerns the approval process for software releases. The DORA researchers asked organizations to self-identify which of the following release approval models they used:

• All production changes must be approved by an external body (such as a manager or a Change Advisory Board)
• Only high-risk changes (for example, database changes) require external approval
• Changes are managed through peer review within the team
• No formal change approval process exists

The data produced a result that directly contradicts decades of received wisdom in IT operations: teams that required approval from an external body achieved lower software delivery performance across key metrics including deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate.

This does not mean that governance and oversight are unimportant. What the data suggests is that concentrating approval authority in a committee or manager external to the delivery team creates bottlenecks and does not provide the safety benefit commonly assumed. Teams operating with peer review — code review by colleagues who understand the system — consistently outperformed those relying on external change advisory boards.

The practical takeaway: If your organization runs a Change Advisory Board that reviews and approves every production deployment, the evidence suggests this process is slowing you down without meaningfully reducing risk. A more effective model invests in automated testing, deployment pipelines, and peer code review so that quality is built into the process rather than checked at the gate. External approval can be reserved for genuinely high-risk or regulatory scenarios rather than applied uniformly to all changes.

Key Takeaways

• Find non-technical allies when driving legacy modernization. Legal and compliance teams can make the business case that engineering teams alone cannot.
• Extend your DevOps practices to the database. Version control schema changes, automate database deployments, and treat database migrations as first-class artifacts in your pipeline.
• Rethink change approval. Peer review within the team produces better outcomes than external change advisory boards. Invest in automated testing and code review instead.

The themes from DOES 2018 — modernization, database inclusion in CI/CD, and evidence-based governance — remain as relevant today as when they were first presented. The DevOps community continues to accumulate data that challenges assumptions baked into traditional IT operations, and the organizations willing to act on that data are the ones pulling ahead.

DevOps Is a Leadership Challenge, Not Just a Delivery Model

Many IT leaders treat DevOps and agile practices as a better way to run software projects — faster sprints, shorter release cycles, automated pipelines. While all of that is true, viewing DevOps through this narrow lens misses the point. DevOps represents a fundamentally different way of thinking about IT, and it demands a fundamentally different leadership model.

The traditional IT organization was built around control: controlling project delivery, managing handoffs between IT and the business, and enforcing gates at every stage of development. DevOps replaces that model with cross-functional collaboration, shared accountability, and continuous feedback. For IT leaders — particularly CIOs — the implications go well beyond tooling or process. Four of the most entrenched concerns in IT leadership get turned upside down.

Four Core IT Concerns Through a DevOps Lens

1. Build vs. Buy

Conventional IT wisdom says: buy off the shelf whenever possible, build only when no suitable product exists. This logic made sense in a world of long procurement cycles and even longer development timelines. In a DevOps context, the calculation changes. Building a capability in-house can enable a user-centric, fast-feedback, incremental delivery process — one that continuously adapts to real user behavior rather than locking in assumptions made during a requirements phase. The right answer is not always “buy”; the right question is which approach best enables continuous learning and rapid iteration.

2. Enterprise Architecture

Traditional Enterprise Architecture (EA) functions as a standards body: defining approved technologies, constraining team choices, and enforcing consistency across the organization. In an agile, DevOps organization, architecture is no longer handed down from above — it evolves through the work of empowered teams. This does not mean EA becomes irrelevant. It means EA must shift from a policing role to an enabling one: facilitating reuse, identifying patterns that emerge from team work, and guiding the organization toward a flexible, evolvable architecture rather than a rigid blueprint.

3. Governance

Most IT governance frameworks operate at the granularity of projects or programs: approve a project, fund it, track it to completion, close it. But DevOps enables teams to work in single-piece flow — essentially delivering and learning one increment at a time. At that level of granularity, the project construct starts to break down. When development and ongoing maintenance become indistinguishable, what does it mean to “complete” an initiative? Governance must evolve from a formal approval process into an active, ongoing discipline — one focused on generating and steering initiatives toward specific business outcomes rather than simply approving or prioritizing proposals.

4. Risk Management

IT has historically treated risk as something to be eliminated or, at minimum, mitigated. DevOps does not eliminate risk — it makes risk visible and manageable through fast feedback loops and small, reversible changes. The more productive framing is to treat risk as something to be deliberately accepted and acknowledged, with the goal of earning a risk-based return. This is how product organizations and startups think about risk. It should be how technology leaders think about it too. The CIO’s job is not to avoid risk but to actively determine the appropriate level of risk and pursue it with confidence.

What This Means for IT Leadership

Each of these four shifts points to the same underlying change: IT leaders can no longer be passive recipients of business requirements. They must take active responsibility for business outcomes.

• From order-taker to co-owner: Rather than accepting requirements from the business and delivering against them, IT leaders must participate in defining what the business should be trying to achieve in the first place.
• From service provider to strategic partner: The CIO’s goal is no longer to provide excellent customer service to internal stakeholders. It is to work alongside other parts of the business to accomplish shared objectives.
• From risk avoider to risk manager: Instead of minimizing all risk, the CIO should determine what level of risk is appropriate given the organization’s strategic goals and actively target that level.
• From project governor to outcome driver: Governance becomes a proactive, generative process — identifying and launching initiatives that advance business goals — rather than a reactive approval gate.

Cross-Functional Teams and the Journey of Discovery

DevOps, understood properly, is an approach in which cross-functional teams use fast-feedback loops and continuous adjustment to accomplish organizational goals. Technical staff are not a separate function that receives specifications and produces output — they are members of a business team engaged in a shared journey of discovery, testing hypotheses and adapting based on what they learn.

This changes the nature of accountability. Teams can be given ownership of an outcome — improve customer retention, reduce onboarding friction, increase transaction throughput — rather than a fixed set of requirements and a hard deadline. They can experiment, measure, and iterate. They share accountability for results, not just delivery.

The Outdated IT Mental Model

The idea that IT is merely responsible for delivering what the business says it wants is increasingly outdated. In a digital-first organization, technology is not a support function — it is a primary means of creating and delivering value. That repositioning has real consequences for how IT leadership must think and behave.

It is not far-fetched to suggest that in a mature DevOps organization, IT should be as likely to generate requirements for the rest of the business — surfacing data insights, identifying technical opportunities, proposing product changes — as it is to receive requirements from it. That is a significant shift in posture, and it requires CIOs who are willing to step up, engage at a strategic level, and take genuine accountability for driving corporate outcomes.

Key Takeaways

• DevOps is not just a delivery methodology — it requires a new leadership model for CIOs and IT leaders.
• Build-vs-buy, enterprise architecture, governance, and risk management all need to be rethought in a DevOps context.
• Cross-functional teams with shared accountability for outcomes replace siloed handoffs between IT and the business.
• IT leaders must shift from passive service providers to active drivers of business outcomes.
• Risk should be managed deliberately to earn a return, not simply minimized.
• Governance should generate and steer business initiatives, not just approve project proposals.