The Five Critical Steps to Take Before Implementing in the Cloud

By the time that an institution deploys a new system on premises or in the cloud, the value of that investment may have already been determined for the most part. The most critical stage has already passed – the planning stage.

Did we account for all of the integrated systems across campus?  Did we include the right stakeholders in the decision-making process? Did we migrate more than we needed, or not enough? This takes on even greater magnitude when we consider migrating systems to the cloud, where the industry’s standards for data integrity, reliability and efficiency are much higher.

With this in mind, here are five critical steps that institutions should consider before implementing in the cloud.

Identify all systems across the enterprise.

Higher education CIOs struggle to account for every legacy integration point spanning campus operations and at their institutions. By contrast, cloud providers must account for all systems and data on their platforms and networks to optimize efficiencies and meet the higher service levels and security standards for their customers.

The first step for any cloud migration is to track down shadow systems across the institution, from core and adjunct systems to “rogue” servers that have been running under someone’s desk for the past 10 years. The goal is to inventory all systems, look at the data that they contain and determine the value and viability for moving them to the cloud.

Every system, integration and workflow that you take to the cloud is metered in some fashion, so creating a comprehensive inventory of existing systems will help to eliminate redundancies and mitigate costs. Failure to do a comprehensive inventory beforehand will be more costly down the road, plus highly visible in terms of replication, maintenance and potential security vulnerabilities.

Assess the value and cost accordingly.

Evaluating legacy systems in higher ed to decide what stays and what goes to the cloud, as well as what gets unplugged, is never a simple or straightforward process.

For example, you may have found a cloud-based HR system with all of the features and functionality that you need. It’s probably clear to everyone, perhaps even documented, that the new solution must interface with your student information system and financials back-end. Are you done? Not really, you may be just starting. Those same integration patterns may be replicated, with undocumented differences, for multiple operational applications across campus. Your legacy HR solution may be integrated with another HR instance in your medical center, with your residential life system or multiple recruiting applications, all of which have value and ongoing support costs that must be considered.

Cross-system workflows, extensions and integrations must be mapped out in advance of any successful cloud migration—otherwise it will be impossible to build a project plan that reflects the true costs and benefits of your cloud implementation against your long-term business objectives.

Define your core processes, and identify process owners.

Setting protocols and expectations are more critical to cloud-based solutions versus on premises, because they are built on an expectation of centralized or shared governance. Implicit in migrating to the cloud is the acceptance of standardized business processes and forgoing future customizations. Instead of turning to IT to deliver user-defined items (e.g., reports, workflows) post-implementation, departments need to identify their strongest business expert—who may not be the person who has been around the longest—to develop best practices and drive adoption with counterparts across the campus.

Successful cloud migrations are led by the business units that are partnering with IT, as they implement the solution and provide guidance on new tools and operating models. Therefore, business owners and executives play a critical role in driving broader adoption across departments and the institution.

Institutions should also establish an executive governance body that will empower the business users, while setting expectations for the outcome. Ultimately, it must own and communicate any business impact to the campus.

Gain insight through analytics and dashboards versus ad hoc reports.

Today, institutions are justifying cloud migrations to drive discipline, cost efficiencies and security, while providing better operational insight. Yet, migrating thousands of reports over to a new architecture or the cloud creates a monster akin to customizations.

Modern cloud-based systems visualize data via dashboards and business analytics packages that staff can use to drive operational tasks. Administrators and executives alike should be able to transform that data into real-time business intelligence without calling IT and waiting for a custom report. If there is still a need for a one-off report, they should be able to review the data and create results in standard reporting tools like Excel.

Institutions typically have far more reports than they need for 90 percent of what’s necessary for ongoing decision analysis and regulatory compliance. Data is now being recognized as a strategic asset, and the cloud is the ultimate aggregator of that data across the institution. Institutions should take the opportunity to wean their cultures away from the dependency on reports that are delivered by IT and promote a “real-time data” culture instead.

Practical discipline: define and validate the desired outcome.

Departments and users will embrace cloud-based systems if they are confident that they will deliver the business objectives that are set by the executive sponsors. That does not mean replicating exactly what the legacy system did, which will be the default assumption if left to their own devices.

A practical way to help overcome this is to create structured test cases in advance of user acceptance testing, with scenarios that don’t directly reference the legacy system. Creating test case scenarios for process outcomes shifts the focus to the business objective, versus avoiding perceived disruption. Once users are confident that they can perform key tasks, execute with similar success in the test environment and confirm the outcome, they will be more likely to embrace the migration. You can then start automating the execution of those basic scenarios, freeing up your users to take greater ownership through ad hoc “expert” testing.