Our vendor, Huron Consulting Group, is sunsetting their current research administration product, and initially announced it will no longer be supported as of October 2031. In April 2026, they extended product support through November 2034, although we do not anticipate any impact to U-M's overall timeline. Their product supports U-M eResearch systems including eResearch Proposal Management (eRPM), eResearch Regulatory Management (eRRM), eRAM, and M-Inform.
All customers using Huron Consulting Group’s research administration portal product, including U-M's enterprise systems for eResearch Proposal Management (eRPM), eResearch Regulatory Management (eRRM), eRAM, and M-Inform, as well as peer institutions nationwide will need to migrate to new solutions.
Through 2026, your day-to-day work in eResearch systems won't change. During this time, the university community will have opportunities to provide critical input by collaborating with project working groups on business requirements, vendor analysis, and feedback. After we engage with our vendor partner(s), we’ll share a timeline for when each module will move to the new system. At that point, some of the ways you do your work will change, and training will be offered to help you learn new tools or processes.
The migration will include transitioning to to-be-determined software solutions, reengineering business processes, building new training materials, reestablishing system integrations – within the eResearch product lines (including eResearch Proposal Management (eRPM), eResearch Regulatory Management (eRRM), eRAM, and M-Inform), and to other enterprise U-M systems, like M-Pathways Financials & Physical Resources System and Human Resource Management System (HRMS) – and rebuilding reporting mechanisms. The scope includes planning to migrate active records to new systems, and ensure historical records are accessible via an archive.
The current eResearch systems including eResearch Proposal Management (eRPM), eResearch Regulatory Management (eRRM), eRAM, and M-Inform will continue to be supported while the replacement journey is underway. Routine system functionality improvements and fixes continue to be made as planned. At some point prior to the new system migration, there will be a determination surrounding functionality enhancements and customizations, and any changes will need to be evaluated and prioritized. Eventually, there will be a freeze on changes to the current systems.
MiCores, InfoReady, and other software used for research administration that are not currently on the Huron Consulting Group platform are not currently in scope.
The university community will have opportunities to provide critical input through collaboration with project working groups on business requirements, vendor product analysis, evaluation criteria, and survey feedback. The project team is reaching out as the planning effort progresses for your insights, expertise, and recommendations.
A dedicated team of change management, communications and training professionals is developing a comprehensive organizational change management (OCM) strategy and implementation plan. The OCM work will ensure that everyone affected by this change stays informed, supported, and actively engaged throughout the process. By focusing on the people side of this technical transition, the team will prepare staff through targeted training, engagement with key collaborators to advocate for their units' specific needs, and equip all impacted groups with the resources they need to successfully adopt new systems.
Questions, suggestions, or feedback can be sent to the project team at [email protected] or shared via this feedback form.
A Request for Information (RFI) helps University of Michigan (U-M) staff gather important details about the research administration software market. However, we cannot make purchases based solely on an RFI. By gathering information through the RFI process, we will be better prepared to issue a Request for Proposals (RFP), evaluate different suppliers, and make informed decisions. The RFI process enables U-M staff to ask questions and gain insights into the latest features and limitations of the software, as well as obtain preliminary pricing data to help us budget appropriately for the later RFP phase.
A RFI (Request for Information) is a general inquiry asking suppliers of research administration software for information. It cannot be used to make a purchase. The RFI process is usually shorter and involves collecting written responses from suppliers and possibly product demonstrations. In contrast, an RFP (Request for Proposal) is a competitive bidding process that allows U-M to enter into contract negotiations with the top supplier after evaluations are complete. The RFP process is typically more thorough, involving written responses, product demonstrations, and proofs of concept with the leading suppliers. This ensures that we can make the best final selection based on comprehensive evaluations.
A Proof-of-Concept will be conducted with vendor finalists. A POC typically involves short-term access to a “sandbox” environment with mock U-M data or forms in order to demonstrate how a proposed solution will work in a real-world setting before a full commitment is made. It helps evaluate the vendor’s capabilities and ensures the solution meets specific requirements and expectations. The purpose of the POC is to finalize product selections. There will be opportunities closer to the launch of a new module for advanced access for refining configurations and training.
At this time, a custom "home-grown" solution is not recommended. Custom-built systems are typically more expensive to develop and maintain, requiring ongoing investment to ensure relevance, security, and compliance. This diverts valuable resources away from core research and innovation efforts. Industry experts, including those at Gartner, report that most campuses trust their SaaS vendors to respond quickly to federal regulatory changes, as their business success relies on this agility. In contrast, highly customized campus solutions can carry significant risks, particularly if key staff members depart. Most vendors closely monitor federal activities and proactively update their platforms to address new regulations. Once a vendor is selected, supplemental custom applications for existing, critical functionality may be developed to fill any gaps in requirements not offered by the vendor or initially available.
The eResearch Leadership group will assess vendors using a weighted scoring system based on detailed business requirements and project priorities for a fair and transparent selection. Top-scoring vendors will be invited to provide presentations, participate in exercises, and deliver proofs of concept for further evaluation. Scoring will be updated throughout each phase, incorporating feedback from surveys, focus groups, and other contributors. Finalists will be recommended by the Steering Committee, with executive sponsors (Office of the Vice President for Research; Office of the Vice President for Information Technology) having ultimate decision authority. Multiple vendors may be chosen.
Yes, we plan to migrate active records to the new systems and ensure historical records are accessible. Cross-central office working groups will review historical data, and according to data retention policies, determine what should be migrated to new systems and what data could be accessed via an archival system. The approach may differ module to module.
It is possible that the labeling naming convention could change. Once we have selected vendor(s), we will work with them to identify the best approach.