When we migrate business software like CRM, Accounting, Fundraising, Student Information, Collections Management, Content Management, or anything else to the Cloud or to SaaS (which is probably on some Cloud–so I’m going to use the terms interchangeably in this post), we accrue a lot of benefits. Remote access is easier, and you don’t need any special client software to be installed, just a browser, so your staff can get access on any computer nearby, and probably on their phones, too. Another less commonly understood benefit is the savings in labor and specialization-related costs.

What do I mean? In basic terms, you’re trading ownership, management, and maintenance of system software and on-premise infrastructure for a monthly fee. That monthly fee is probably high compared to what you’re used to–SaaS versions of business systems are usually more expensive than locally-hosted versions. But you’re saving on administration costs. Your IT staff have less to buy, manage, and maintain, and they have less to know, meaning they can focus more on those subjects most specific to the institution. 

The problem, of course, is that looks like extra money a lot of the time, because, while you appreciate the value of not having the local infrastructure, you’re not usually able to maximize that savings by cutting back on IT staff and power users. Especially in nonprofits, where there’s still a little bit of an unspoken contract, matching the lower salaries to better-than-average attention to employee morale and job security. Or maybe your employees are good and you don’t want to lose them.

But that’s the thing. Here’s what’s going on. Server management is much cheaper, per server, when you’re managing a lot of servers than a few. And user support is much cheaper, per user, when you’re supporting many users all using similar systems, than a few. We can’t compete with the hosting companies and software companies; they have an economy of scale we don’t have. We’re better off taking those good internal resources and devoting them to tasks and responsibilities that are specific to the institution than to jobs that anybody could do. So let’s not get rid of them, let’s put them on tasks that drive institutional strategy forward. Like teaching the users new things, or building integrations between all those business systems.

There’s another issue worth mentioning. System migration is never easy on the technical, and if you’re moving from on-prem to SaaS, chances are there are big changes to how the software works, which means difficulty on the user side, too. So a SaaS migration is probably a good time to reevaluate what software is best, too, so you don’t have two big migrations ahead of you.

---

When I arrived at Curtis Institute of Music as CTO in 2017, I had a unique opportunity. At that time, and for the prior eight years or so, Curtis’s tech had been handled by an outside team whose primary work was running IT for the Philadelphia Orchestra. They were more than competent, but any strategic advice they gave fell mostly on deaf ears: there was nobody at Curtis with the experience to know good strategic technology advice from bad. So nothing had really changed in about eight years. Curtis had entirely on-premise servers and software, a lot of it very old. And there were quite a few business systems for an institution of its size (about $30M/yr annual budget). They included:

• Scheduling (ADE–on prem)
• Orchestral planning (OPAS–on prem)
• Fundraising (Blackbaud Raiser’s Edge–on prem)
• Accounting/Financial Planning (Blackbaud Financial Edge–on prem)
• Student Information (Blackbaud Education Edge–on prem)
• Dining (Blackboard Transact–on prem)
• Learning Management (Moodle–on prem)
• Asset Management (ResourceSpace–on prem)
• Web Content Management (EpiServer–on prem)

None of these were inessential; Curtis is a small but very complex institution. It’s a school AND a performing arts organization, and needs systems to support all the functions of both. My task was to update them all, simplifying as much as possible. Ironically, we were in a better position to do so than many organizations because of the relationship with the Philadelphia Orchestra–as we built our own internal technology teams, we could reduce our reliance on the outside team and hire new staff without worrying about outdated skills like server management, instead focusing on delivering value via integrations and excellent tech support.

Five years later, we had:

• Scheduling (Asimut–SaaS)
• Orchestral Planning (OPAS Next–SaaS)
• Fundraising (Blackbaud RE:NXT–SaaS)
• Accounting/Financial Planning (Blackbaud FE:NXT–SaaS)
• Student Information (Blackbaud Education Management–SaaS)
• Dining (Transact Campus–SaaS)
• Learning Management (Canvas–SaaS)
• Asset Management (ResourceSpace–SaaS)
• Web Content Management (WordPress–hosted at WPEngine)

The most difficult transition involved the Blackbaud products. The selection wasn’t complicated–while a committee I led put significant effort into evaluating many products, ultimately only Blackbaud offered an integrated system providing all three essential CRM functions at Curtis. Students in the SIS become Vendors in the Accounting system (performers at concerts) and Alumni and Donors in the Fundraising system, so the integrated system afforded the possibility tracking the full lifecycle of our constituents. Other providers of CRM and CRM-like systems did not offer the Student Information piece (Salesforce, Patron Manager, etc.). Nonetheless, the migration affected every staff member at Curtis and many years of data, so the preparation, planning, and training were all very big tasks to manage and complete.

Scheduling was probably the biggest success. Class and lesson schedules came from the Student Information System; performance schedules came from OPAS. ADE, the earlier scheduling system, was unable to handle performance information so students had multiple places to look to find their daily schedules, and the registrar and orchestra managers ran weekly meetings with 11 people to prevent and resolve double-bookings. It was also desktop-only–it had no mobile interface–which meant that students couldn’t check their schedules while on the move (and Curtis has several buildings). Asimut, its replacement, is built especially for conservatories and is meant to contain and present both class/lesson schedules and performance schedules–and has a fully functional mobile interface.

Other important improvements:

• ResourceSpace, which we used only for ephemeral marketing-related digital assets, offers free hosting for small installations, so we replaced an aging server and software with a free, online service that took almost no administration effort. The transition cost only a few thousand dollars of a database developer’s time.
• Transact Campus, a separate company that span off Blackboard’s dining hall system (also called Transact), was actually cheaper to run hosted than on-prem. Primarily that was due to the ease of support; their support team could easily access and help configure the hosted software, but struggled to communicate the same changes over the phone, or to provide on-site support.
• WordPress is a much simpler CMS than EpiServer (which isn’t bad). We already had instituted distributed editing of the site; WordPress made that much easier to maintain because it was so much easier to train new staff in using it (we had coded the editing interfaces to be as easy as possible). Also, WPEngine, for about $100/month, takes on all server-management responsibilities, including backup, restore, staging management, redirects–you name it. Just the time to handle those tasks would cost well over $1000/month just in person-hours, even without the necessary hardware and systems.

In the end, my team and I migrated every system to SaaS, except the security-related (security cameras and ingress/egress) systems. Those systems inevitably have a significant amount of on-site hardware (the cameras and the gates/card readers at the doors), so the vendors are a bit behind in providing SaaS capabilities.

How much did we save? Our bill with the outside providers went from $11K/month to about $5K/month over the five-year period, and the increase in software costs (about $30K annually) was roughly similar to what we saved on hardware and related costs (like server room space). So let’s say $72K/year. But that leaves out some extremely important parts:

• Every single one of these systems went from either difficult or impossible to access remotely, to just as easy to use wherever our staff were. Curtis staff are still remote-preferred workers and Curtis is selling one of its office buildings, for another savings of hundreds of thousands of dollars per year, plus the $5M or so sale.
• In the process, staff gained a sense of ownership of their systems. We included them fully in the process of selecting and implementing every system. The vendors found us exhausting, but we made sure people got what they needed.

Digital transformation is much more of a ground-up process than many institutions understand. It happens when the entire staff sees technology as a way to get more and better work done, rather than as an irritant. What we achieved was a new Curtis that is prepared for the next tech revolution, whatever it may be, because they can now focus on delivering value, not on maintenance.