The Customer

Prospera Credit Union (Prospera) is built on more than 80 years of service across British Columbia. They’re a community-based, purpose-driven organization that offers a full range of financial products and services through a network of 24 local branches.

As one of the largest credit unions in British Columbia, Prospera has more than 115,000 members and holds over $9.3 billion in assets under management. Their primary lines of business are Personal Banking, Business Banking, Wealth Planning and Leasing.

Jeff Belloch, Enterprise Architect at Prospera, works across operations and architecture with a small development organization of around a dozen developers. As Jeff explained, the team does not have dedicated DBAs in the traditional sense. Instead, they rely on a mix of developer knowledge, some database specialists focused on BI workloads and operational tooling to maintain availability and performance.

Their core banking database supports a wide range of connected systems and channels. The estate extends beyond production, including disaster recovery, a production-like staging environment, six separate QA environments and training. Individual developers also run SQL Server locally for development work.

In total, Prospera runs well over 120 SQL Server instances across servers and desktops. The organization has also migrated four physical data centers into Azure, with the majority of workloads running on Azure VMware Service, treated operationally as on-premises infrastructure hosted off-site.

The Challenge

For Prospera, uptime and predictable performance of their database estate are non-negotiable. But without a dedicated DBA function, they needed a way to identify developing issues early and diagnose them quickly when something did go wrong.

Prospera relied on Microsoft System Center Operations Manager (SCOM) for monitoring their estate. This system could flag infrastructure-level concerns such as disk space but offered limited, database-level clarity when performance issues emerged. Supporting and administering this heavyweight platform properly meant maintaining multiple management packs across different SQL Server versions, polling systems via scripts and dealing with the overhead that came with agent-based monitoring. Jeff summarized these issues as “We used Microsoft SCOM, and I quickly realized that it’s really, really complicated, and not very helpful. It’s such a beast that required a significant amount of administrative overhead. It told us when there was a problem, but it was just very messy, clunky and disorganized.”

The result was a largely reactive workflow. When alerts triggered, Jeff and the team often had to assemble several developers to investigate, supported by custom scripts and online research to narrow down likely causes. That pulled people away from feature work and extended the time-to-resolution for operational problems. “The best time to deal with the problem is before it happens,” Jeff said, recognizing that reactive firefighting was an unsustainable approach for a financial institution.

Coverage gaps made the situation harder. Because SCOM agents were costly and time-consuming to manage, many non-production SQL Server instances were not monitored in the same way. That increased the risk of issues appearing in QA or staging without being spotted early, then emerging later under production load.

This created several operational risks:

• Slow diagnosis under pressure when performance degraded
• Reactive escalation, with database issues often surfacing after user impact
• Disproportionate load on a small number of people to triage and explain issues
• Limited visibility into non-production environments where problems first emerged
• Extra strain and uncertainty from running ad hoc diagnostic queries on live systems

Jeff wanted monitoring that would reduce noise, provide clearer starting points for investigation and make it easier to separate database behavior from application behavior. In other words: database-specific signals that helped the team focus efforts in the right place, fast. “That was really the catalyst for implementing Redgate Monitor, extending my capabilities and alleviating a loss of people.”

The Solution

Having experienced the value of Redgate solutions in a previous role, Jeff championed the implementation of Redgate Monitor. His core requirement was a specialized tool built by database experts that could provide clear, early signals without adding operational complexity.

Crucially, Redgate Monitor offered agentless deployment, meaning it could be added with minimal impact on target systems. Prospera deployed Redgate Monitor across production and disaster recovery, then expanded coverage to staging and QA, providing a consistent, end-to-end view of database health across environments. As Jeff outlined, “I don’t want Redgate Monitor just on prod. When you have six separate QA environments and different teams working on them, having that more expansive view, and being able to compare a QA box to prod and looking at the different stats. That was a big benefit to us.” This enabled the team to track how different code features affected database behavior in non-production environments, catching problems before they ever reached live servers, and critically impacting members.

A key advantage was the speed at which non-specialists could interpret what was happening. With a visual dashboard and clear navigation from overview to deep detail, the team could identify which server or database was under pressure, then drill into waits, queries and resource consumption to narrow down root causes.

Redgate Monitor also reduced the need for intrusive diagnostics, as Jeff explained, “thanks to Redgate Monitor, we don’t have to do ad hoc diagnostic queries anymore. I can’t recall the last time we’ve written a query to do something like that”. Instead of running heavy scripts against production to see what was happening in the moment, the platform continuously collected the data required for investigation, creating a predictable monitoring load.

To broaden its impact, Jeff shared role-based access to the web interface across operations, developers and management. In the network operations center, Redgate Monitor dashboards are displayed on shared screens so teams can see developing issues and health status at just a glance. “The fact that non database specialists can go into Redgate Monitor quickly and have a good idea of the landscape. They can see things like, ‘Oh, this server is really busy, this one’s not, this one has problems.’ In our Network Operations Center, one of the big TVs has Redgate Monitor up on it, they love it.”

Prospera also configured alert thresholds and built custom alerts to match its own environment and priorities. This helped reduce false positives while ensuring the right people were notified when behavior moved outside expected ranges. “It brings it all together. It gives me an interface that allows me to organize my servers so I can see what’s important, drill into queries and understand where issues are coming from,” explained Jeff.

The Results

With Redgate Monitor in place, Prospera shifted from reacting to problems after the fact to identifying and investigating issues earlier, with more confidence and less disruption to day-to-day work.

One of the biggest gains was faster triage, so when a single server behaved differently to otherwise identical peers, Redgate Monitor made that difference visible immediately. That removed entire branches of investigation and helped Jeff and the team converge on the true cause more quickly, “that might be one of the biggest benefits of Redgate Monitor, the reduction in the amount of time absorbed from other skill sets to get something fixed or understood.”

Furthermore, using historical reporting to look back and see when a trend started, Prospera could correlate database behavior with deployments, platform changes and external tooling updates. “I can’t tell you the number of times we’ve been able to figure out a problem by having that ability in Redgate Monitor to look back and see when something started, and what was correlating”. This reduced guesswork and helped the team build repeatable fixes rather than one-off responses.

Redgate Monitor’s estate view allowed teams to see which servers were out of date and track progress during projects such as upgrading SQL Server versions. As Jeff outlined, because the information was available in the interface, management could self-serve status reporting without pulling technical staff into administrative updates. “I love the estate feature. Last year we upgraded all of our servers to SQL 2019, and my boss didn’t have to ping me to find out where I was at in the process, he just went to Redgate Monitor and could see for himself”

The human impact was equally important. By making database health easier to understand, Redgate Monitor was a significant cost saving: the deep visibility and control it provided acted as ‘Tier 2 support’, making the team more efficient.“ Redgate Monitor literally stopped management from hiring a DBA two years ago. Just based on what a good DBA can cost, Redgate Monitor’s already paid for itself.”,” added Jeff.

The impact for Prospera included:

• Faster root-cause identification for database performance issues
• Earlier visibility into problems in QA and staging before they reached production
• Reduced disruption to developers’ day-to-day work during investigations
• Greater confidence during upgrades and platform changes
• Improved transparency for operations and management through shared dashboards and reporting

Looking ahead

Prospera is currently preparing for a merger with a larger credit union, which will introduce a broader mix of database platforms and a much larger overall estate. As Jeff expects, the combined organization will operate across both SQL Server and Oracle and will continue modernizing its Azure footprint.

With Redgate Monitor already embedded as the day-to-day interface for monitoring database health, Prospera is well positioned to extend its database-specific monitoring approach as the environment grows and diversifies. Their goal remains the same, fewer surprises, faster diagnosis and more time spent improving systems rather than chasing emergencies.