Research Hub closure offers lessons for IT

Research Hub, the collaboration and file-sharing platform run for four years by Information Services & Technology (IST), has been retired. The closure, spurred by budgetary constraints, came as an unwelcome surprise to Research Hub users across campus. Anticipating the disruption that would be caused by the shutdown, IST funded a team of staff to help Research Hub users migrate to new technology and services.

The Research Hub retirement provided an opportunity for IST to learn to better manage change in the services it provides. Given rapid developments in technology and ongoing budget pressure, IST sees service changes and closures as inevitable. The challenge for IST is to budget and plan for the services it provides in a way that takes this reality into account while recognizing the importance of familiar tools and processes to the campus community that uses them. 

Seven stories from the abatement project illuminate the burdens imposed on faculty, staff and students by a move from one system to another, and the obligations faced by a campus information technology (IT) provider as it responds to a changing environment. Bridging all seven stories is the theme that IT support occurs in the context of a partnership between technology staff and the people we serve. 

Lesson 1. IT change costs campus members time and money

The announcement of Research Hub's closure was made to campus at the end of the day on July 28, 2014. By 6:30 that evening, Associate Vice Chancellor–IT and Chief Information Officer Larry Conrad received an email from an angry faculty member:

I am deeply disturbed by the decision, just announced, to retire Research Hub, after investing considerable time (not to mention RA [graduate student research assistant] money) in setting up several research sites on the hub. … I have little faith left in any UCB technology initiative supporting research or instruction having seen platform after platform retired after a relatively short run...

Changes -- whether mandated by budget, or by realignment of campus business processes; or resulting simply from the desire to provide better and less expensive services -- deeply affect campus users, frustrating them with a recurring need to retool. This cost to campus at the end of the service lifecycle suggests that IT service managers should always take the long view when preparing a service for release. They must be realistic about the benefits of the new service, meticulous in validating the change with the people who will be affected, and tireless in communicating the need for the change to campus. Perhaps most importantly -- because change in technology is a given -- IT service managers must budget for the expense of moving campus from any given service to its eventual replacement. (More on this in lesson #3, below.)

Lesson 2. Communicate clearly and honestly

By 9:40 the following morning, Larry Conrad replied:

I share your frustration with the history. I inherited several areas where there are recurring expenses, but there is not recurring funding to support. Research Hub is unfortunately one of those.

IST is facing a nearly $10M structural deficit in FY2015-2016. Requests for additional funding have been denied. We have been supporting Research Hub with our reserves, but those will be depleted by the end of this fiscal year, and I have been directed to find areas to reduce or cut altogether. I am painfully aware that members of our campus community are dependent on every service we provide, so any reductions or eliminations will cause disruption and difficulty.

The AVC/CIO’s immediate, plain-spoken response struck a chord with the professor, a recent department chair all-too-familiar with budget cuts. It engendered a spirit of cooperation, setting the stage for a smooth working relationship over the following months. It also set the tone for a “town hall” meeting held in October 2014 at which IST directors spoke directly to people affected by the shutdown. David Greenbaum expressed the project’s intent to work with Research Hub users to reach a suitable solution for each. Bill Allison announced efforts to guarantee support for the bConnected services -- which have recently been expanded to include bDrive, Box, CalShare, and bCourses project sites -- for at least three years, with an expectation that users will be notified at least two years in advance of a service's retirement.

Lesson 3. Budget to do change right

In July of 2014, in preparation for closing the service, IST created the Research Hub Transition Project, allocating funding for project management, communications and change management support, and dedicated staff time. Transition staff would work with Research Hub users, identify gaps in the feature sets of the campus-supported options, provide guidance on the strengths and weaknesses of those options for users’ particular needs, and develop mechanisms to speed the work of migration. The Research Hub abatement marked the first time that IST had set aside additional money to close a service. The subsequent success of the transition reinforces the importance of this lesson.

Lesson 4. See change through the users’ eyes

In the days prior to announcing the service’s retirement, Research Hub’s help-desk staff met one-on-one with a dozen of the service’s most active users. These initial conversations were intended to cushion the news for those most dependent upon the Research Hub. The visits were a courtesy, so the service’s power-users wouldn't learn of the closure through an impersonal email, or via the rumor mill. In the event, however, the customers began immediately to articulate their needs and wishes, and to ponder aloud what their next steps might be. Their initial responses -- unrehearsed and not without anger -- provided a valuable starting point in matching the needs of all Research Hub users to available options.

Conversations resumed during fall semester as the transition team convened a Research Hub users working group. Members provided input on user requirements and shared their knowledge about the capabilities of alternative services. In addition, the working group setting allowed the transition project to help key users select, then migrate to, replacements for their Research Hub sites, building transition staff experience with each step of the process.

Lesson 5. Use data to know (and help) even more users

Beyond high-touch interaction with a small base of Research Hub’s biggest customers, the transition team needed to develop strategies for assisting all of its users. To do so, the team turned to Research Hub usage data for insight. 

The team assessed internal data about Research Hub sites, analyzed web activity logs, and reviewed the service’s history of support tickets. It identified four categories of users. One category consisted of two museums that were the largest, most institutional users of the service. (More on this in lesson 7, below.) Another included departmental site account holders (users who had paid for additional storage) and groups who had worked closely with Research Hub support staff to develop their site. Heavy users, as measured by the amount of stored content, the number of site members, and active traffic during the previous school year, comprised a third. The final category contained the managers and members of the long tail of smaller, less-active sites, many of which appeared to be abandoned.

With this information, the team created its communication plan. Staff personally contacted customers from the first three categories. In addition, a series of emails was sent automatically to the managers of every site. 
The data were helpful even beyond their usefulness in shaping a communications strategy. Knowing the contours of a site's usage, team members could recommend to individual users where best to begin their search for a replacement. The data also helped the transition team determine how to prioritize its efforts to automate or mechanize the various steps in the migration process. Recognizing the widespread use of wiki pages and blogs, the team developed a means of archiving those pages in a form that could be viewed on any web-based system. Seeing the relative lack of use of tags and special permissions across Research Hub sites, the team opted against purchasing an expensive tool to export those configurations.

Mining data served to illuminate patterns of use that had been indiscernible through one-on-one conversation and accrued experience. It extended the transition team’s familiarity with Research Hub users from the few to the many. With a clearer understanding of how people relied on the service, the team made better decisions about how to support the transition from it.

Lesson 6. It takes patience, trust, and a village

After the town hall meeting, as attendees chatted with transition team staff, Je Nell Padilla of  Residential and Student Service Programs (RSSP) was introduced to Michael Leefers of IST’s CalShare team. Je Nell was responsible for two Research Hub sites, and over a period of years had actively shaped her unit’s work processes to take advantage of Research Hub features. Because CalShare, Berkeley’s implementation of Microsoft SharePoint, is hosted on campus servers, Je Nell identified it as the most appropriate replacement option. She had doubts, though, about managing the complexity of CalShare.

Of the campus-supported options to Research Hub, CalShare is the most similar. But, where Research Hub presented users with a tailored set of useful choices, CalShare allows maximum configurability -- far more than Je Nell needed. The trick to making CalShare work for RSSP would be to use the features that supported established processes and ignore the others (at least at first).

The CalShare team’s timetable for a scheduled upgrade to SharePoint called for development and testing during Fall and Winter 2014, with a switchover to the new system in March 2015. The upgrade promised performance and ease-of-use improvements but presented a serious calendar issue for RSSP. Je Nell’s ace-in-the-hole technologist -- Gabriela Gerinska, a student employee -- would lead the effort to port the Research Hub sites to whatever came next. But Gaby would be away over winter break, and busy with school work in April and May as spring semester ended. The window of time to make the switch was small; the timing, inopportune.

With these concerns, Research Hub transition staff studied a test CalShare site created by the upgrade team, and spun up a “subsite” for RSSP to explore. Je Nell and Gaby began reproducing their Research Hub sites on this temporary host to evaluate fit. Over the course of months, bugs were reported, enhancements suggested, and fixes put into place in collaborative exchange between RSSP, the Research Hub team, and the CalShare team led by Michael Leefers. Je Nell persevered, despite a steep learning curve and technical documentation that often assumed a knowledge of computers beyond her comfort. Gradually, she grew confident that CalShare would be suitable … if Gaby could begin to recreate the RSSP production sites before coursework pre-empted her availability.

Michael and his team delivered on schedule. On Monday, March 9, CalShare went into production running SharePoint 2013. By early April, Gaby and Je Nell had finished building the sites, as well as roles and permissions governing access and privacy. In early May, after migrating content from Research Hub, RSSP went live with CalShare.

Je Nell’s decision to switch to CalShare was a sound one, but required time to implement, and flexibility to accommodate a key team member’s availability. If taking on CalShare required a leap of faith on Je Nell’s part, it’s equally true that the success of the transition depended on many people working in close, collaborative consultation. 

Lesson 7. In the aftermath, now what?

Just as it was for every campus user, moving off Research Hub was a responsibility thrust upon the staff of the two largest users of Research Hub -- the Phoebe A. Hearst Museum of Anthropology (PAHMA) and the UC Berkeley Art Museum & Pacific Film Archive (BAMPFA) -- at a pace not under their control. For the museums, as for RSSP, the timing was fraught. BAMPFA, for example, was in the midst of preparing to move to a new building and switching to a major new piece of collections management software.

The museums each had more than a terabyte of content in Research Hub. Staff from both museums used Research Hub regularly in the course of business: to produce program guides, to arrange and chronicle exhibitions and events, to store images and documents, and to make materials available to researchers and others. Varied and complicated daily workflows had been adapted to incorporate Research Hub. After evaluation, neither museum found Box, bDrive, or the other options suitable to support their work.

Pressed though they were, museum staff began to explore the feasibility of switching to a professional digital asset management system (DAMS), like those used by their peers. The budgetary issues that forced the closure of Research Hub meant that IST could not afford to host and maintain a DAMS. The two museums would need to turn to an out-of-house vendor. To afford such a product, they agreed to pool their resources and negotiate a discounted price.

Though IST could not afford to manage and maintain a DAMS for the museums, Research Hub abatement funding did enable transition team staff to assist the museums during the search for, and later, the switch to, a new product. Transition team staff helped assess technical requirements and review product specifications. Once the winning product was procured and in place, the team worked closely with the vendor and the museums to assure that files and their metadata were successfully mapped and migrated from Research Hub to the new system. These efforts benefitted from the participation of team members Glen Jackson, Chris Hoffman and Ian Crew, each of whom brought to the task years of experience -- more than 20, in Glen’s case -- providing support to the collections. The partnership between the museums and IST was enhanced by the team’s familiarity with the museums’ staff, their business processes and their data. Work progressed at a rapid clip. 

In June, after months of configuration tweaks, metadata cleaning, and migration tests, the museums’ files were loaded into the DAMS. The migration project had been completed on deadline. More work remained to make the new platform fully functional, but the museums had successfully turned the page on the old one. With the last of its users relocated to a new home, the Research Hub could be shut down. The service was off the books as the new fiscal year began.

Happily, the Research Hub’s closure created an opening for the museums to acquire a tool that fits their needs. In adopting a third-party product, though, the museums have taken on the role of service manager with respect to their users. Museum staff, when they can carve out time from other critical duties, are trying to tackle these new responsibilities. 

We have seen in the stories of Research Hub’s closure the difficulties inherent in guiding a service through the course of its life, including the eventual exit. With no more transition funding, and no longer a service offering to support, how involved should, and can, central IT staff be in the museums’ efforts to adjust to a new technology? IST service managers know the real costs of technology and the secrets to overseeing change. Can that expertise be shared with the museums to help them budget and plan realistically? Can the technical familiarity that produced such successes during the transition be drawn upon again to work out the remaining kinks in the system?


The success of the Research Hub abatement -- and by most accounts, it was a great success -- would not have been possible without funding allocated to the transition team by IST. Change costs money, and IST recognized and fulfilled its obligation to provide those funds instead of “externalizing” the full cost of transition to users. The clear lesson: to successfully manage technology change, service funding needs to include a sunset component.

As importantly, the Research Hub transition succeeded because of the working relationships fostered through honest communication, responsiveness, and inclusion. Those relationships built upon existing partnerships developed over the Research Hub’s lifetime, and even preceding it.

Directions change, budgets contract, technologies go out of date. But the unavoidable pain of technology transition can be mitigated when managers budget for it, and support staff take the time and care to assist users with their particular needs. Perhaps assuming these two responsibilities is the place where the success of any transition begins.

The author was Research Hub support lead and a member of the Research Hub transition team.