What Did I Forget?! Top 5 Non-Implementation Issues to Think About During a Cloud Application Transition

After living through three generations of technology that have swept through higher education administrative systems over the last 30+ years, I have added the unique experience of stepping out of the institutions and into my role as an industry analyst. Thinking about my own experiences as I listen to many of you talk about what’s happening at your institutions, it occurs to me that the transition to SaaS is quite different than the transition to client-server. There are some significant items to consider that may not be obvious when you begin.

1. The IT Transformation

The role of your applications, infrastructure, project management, training, change management, and leadership teams all change significantly in the move to SaaS applications. If your institution considers IT just a facilitator or implementor of this change, you have missed a significant opportunity to transform how you partner and deliver services to your campus. Not only is IT typically the facilitator of the changes, but it is also fundamentally changing itself at the same time. Why?

First, the hard line between IT skills and business skills gets further blurred. When the primary maintainers of your system are business analysts who configure the functionality, the center of gravity has radically shifted. How these teams are formed, managed, and tied to business areas is new. And these new roles have IT responsibilities that need to be added to their jobs and their management chains.

In addition, core system support has been outsourced, and IT cannot go “just fix it” anymore.  They need to understand and partner with their SaaS vendors to ensure service availability. These are new skills as well. Some core IT roles, from data center management to system administrators, will no longer be involved in maintaining these critical systems.

2. Continuous Change

Though this is part of SaaS applications’ sales pitch, it isn’t easy to envision what it might mean to the organization. When these systems are in production, they change several times a year, and there is no ability to pause. Institutions need to manage this change by being prepared, communicating, being flexible, and testing critical components to ensure service continuity. Some platforms change code every week for minor fixes. Institutions need to focus on upcoming changes to reduce risk, make any required process or technology changes (which should be very few), and communicate to the campus.

Massive upgrade projects will no longer be the primary way to make process changes. As institutions become more agile, they need to focus resources on taking advantage of new functionality and accommodating more frequent business processes and organizational changes. Change will now be incremental and regular, not massive projects aligned to intrusive and expensive upgrades. This year has provided many examples of leveraging SaaS systems to make quick business changes to react to a new reality, such as mid-term changes to course grading and term schedules. There is clear anecdotal evidence that institutions on SaaS platforms were able to change faster and with overall less effort than those on legacy platforms.

Not only is the new system you are trying to roll out a very different experience for users, but you are also likely changing business processes significantly with your implementation. After this exhausting transition, you will be presenting these users with continuous change¾forever.  This is the new model, and it sounds terrific until your users cannot find the button or field they need on Monday morning. Institutions must consider the impact of this reality on the community and proactively work together to reduce the stress. Change management needs will persist well beyond your deployment.

3. Loss of Control Over the Technology

Customizable, on-premises technology puts the majority of the responsibility and control on the institution’s IT department. Even if the intent in buying vendor packages was to transfer that responsibility to the software vendor, the fact that the institution could change the code meant that when the issues were critical, they would. Very few higher education organizations had the discipline to stay out of the code on these platforms, so they quickly became the owners. With SaaS, if it can’t be configured, the institution cannot make the change, regardless of the criticality. Though vendors are offering PaaS extension capabilities, institutions cannot modify delivered code from the vendor. This change in control has many effects. It frees IT from the task they should not have had from the beginning¾customization. This is balanced by the ability to configure the system to accommodate the institution’s needs. But it also means that when things go poorly¾think outage¾there is very little, if anything, the institution can do to help restore service.

4. Business Ownership in Systems

SaaS systems reduce the technical requirements for the institution and bring control of functionality closer to business users. Finding the balance between IT and business organizations requires a new kind of partnership for most institutions.  Embracing the need to find a new model will help create a community around these systems. Institutions need to consider the pace of change, institutional risk, audit concerns, interdependencies between business areas, and overall costs in coming up with a new model that will work for their campuses. Many institutions are initially locating the SaaS support organizations within the business units, not IT. Though this is more challenging with enterprise platforms, the reason for it is clear: Technically-savvy business analysts can manage much of the platform without significant IT assistance. Integrations can even be managed this way for some organizations with the right iPaaS platform. There are, however, critical skills that IT brings to the table that are required to manage a large SaaS application, even beyond integration. As multiple systems are implemented, a hybrid model is becoming more prevalent, where the support organization has some form of dual reporting to IT and the business leaders they support.

5. Managing Institutional Data

Moving significant systems of record to the cloud creates new dynamics to consider in managing institutional data that is now spread across physical data centers. Finding the right mix of strategy and technology to ensure data is accessible to those who need it for operational, analytics, and integration work is not a simple task.  Institutions must also consider how to make historical data accessible to those who require it.

Tambellini recommends that in preparation for moving major systems to the cloud, institutions formulate a data management program, encompassing reporting and analytics, data repositories (i.e., data warehouses, data lakes, and data fabric), integration strategy and tools, and data governance.

Institutions felt significant organizational and technological impacts when implementing vendor administrative systems in the ’90s and 2000s. The impacts after moving to SaaS are even more profound. They fundamentally change the relationships and responsibilities across the organization, both in core business functions and support organizations.

All of these impacts should be considered before beginning the implementation process. Each affects the outcomes of the implementation, from the ongoing cost-benefit calculations to organizational dynamics. And all of these changes offer the potential to help institutions become more efficient and more reactive to their environment.