UNIT DEVELOPED APPLICATION REVIEW AND TRANSITION

PURPOSE

SCOPE

OIT POLICY STATEMENT

• The unit owning the application must contact the IT Governance Office to request a review, providing as much data as possible about the application to be transferred. There is a request form here: [link to service now request form]
• The Governance Office will schedule a series of meetings with relevant stakeholders from OIT and from the campus unit. Stakeholders will include representatives from the unit, users of the tool, unit leadership responsible for budgets and funding, an OIT risk manager, an OIT architect, relevant engineers and support staff from OIT, and a representative from technology planning. Depending on the complexity of the application, there could be multiple meetings required.

Step 2: Initial Assessment
During the initial meeting, the requesting unit will:

• Confirm whether the application is still needed and outline its current business purpose.
• Discuss current support challenges and the reasons OIT assistance is needed.
• Provide an overview of the tool, its integrations, data sources, reports, key features, operating costs, issues, and problems • Describe the level of support the unit had in place to support the tool when they developed it and put it into production. This includes # FTE, # student employees, information about the frequency of required changes, and so forth.

OIT will:

• Outline the next steps given the scope and complexity of the units expressed needs.
• Set up follow up meetings with engineers, architects, support personnel and technology planning to begin drafting a recommendation. (See below for the components of the recommendation packet.)
• Establish appropriate timeline for necessary work after consulting with engineering teams required for a transition.
• Document the system and its current configuration and ownership in the CMDB

During follow up meetings, OIT personnel work with unit experts to:

• Evaluate the tool to determine the best short-term and long-term roadmap. This may take several meetings with OIT architects, subject matter experts, site reliability engineers, unit personnel, and the support team that would be assigned to manage the application. Activities to include:
  
  • Document the technology stack used to develop and support the app
  • Evaluate of the health of the development stack
  • Develop an architecture diagram, including assessment of technical alignment, data security, and integration impacts
  • Evaluate security and privacy risks
  • Determine how much support (labor and budget) the tool requires to function, including bug fixes, updates, patches, incident management, storage costs, azure costs, container costs and so forth
  • Update CMDB entries as documentation is gathered
• Compile Recommendation including but not limited to:
  
  • Potential replacement tools
  • Stack recommendation (maintain, adjust or redevelop)
  • Pillar and Support Team alignment
  • Annual labor and budget estimates
  • Key stakeholders (Unit liaison, portfolio director, etc.)
  • Architecture diagram
  • DSA, privacy, security review results (notes any compliance issues)
  • Recommended resource planning steps
  • Monitoring recommendations

Step 3: Resource Review
Once the review is complete, the unit will work with the OIT Technology Planning office to address short-term and long-term resource needs.

Short-term resource planning
The unit requesting should be prepared to transfer FTE or budget to cover anticipated expenses through to the next resource planning cycle. For example, if an application transitions to OIT in July of 2025, expenses will need to be covered through December 2026, and long-term resource implications will need to be included in the 2027 Resource Planning Cycle.

Long-term resource planning
As a part of the Resource Planning Cycle, the unit must submit a request for labor, funding, and licensing required to support the existing tool or transition to a different solution based on the Architecture Review. The plan must include:

• Budget required for so]ware or hardware purchases, fees for ongoing support related to Azure, containers, integrations, licensing implications, or other factors identified during the Architecture Review
• Request for personnel needed to develop and/or support the application in the future
• Items determined to require long-term resource planning will be placed on the OIT Risk Register so that appropriate follow-up takes place and resource planned work is requested.

Step 4: Transition Decision
Based on discussions, the OIT Transition Team will recommend one of the following:

1. Decommission – If an enterprise solution already in place fulfills the need.
2. Third-Party Tool – There may be enterprise tools available or existing applications that could be used to transition unit application to a more sustainable future.
3. Retain and Support in Current Application Stack – If the architecture review recommends the current stack as best fit, compliant with all standards, and resources are secured for this approach, some applications may transition to OIT in their current stack and configuration.
4. Transition to Another Platform (Simple) – Simple applications may be able to easily convert to a sustainable format with Power Platform or other tools available through OIT.
5. Transition to Another Platform (Complex) – Complex applications may require significant resources to rebuild. In such cases OIT assist units in planning for interim business needs and properly resource planning future replacement efforts.

Units will acknowledge that transitioning support of the application to OIT may entail the loss of system administration privileges, direct access to databases or service accounts, and other shifts. However, the business purpose and requirements for the transferring application will be documented and agreed to by unit and OIT leadership before the transition takes place.

Step 5: Implementation and Documentation
The recommendation will be reviewed by the unit and OIT leadership. Applications approved for transitioning to OIT will be documented in the OIT Leadership Council Decisions Log. The transitioning service will be entered into the Service Catalog and CMDB, with the date of the transition decision noted. Architectural review and security documentation will be linked to the catalog record and stored in the OIT repository (ServiceNow).

Unit Leadership: Work with OIT and the Unit Application Owner on the resource planning elements of the transfer.

IT Governance Office: Coordinate review, document decisions, ensure compliance with IT Governance standards.

OIT (Architecture, SRE, & Development Teams): Assess technical feasibility, resource needs, and provide transition support or guidance.

OIT (Technology Planning Teams)OIT (Technology Planning Teams): Assess budget and cashflow impact, resource needs, and provide support or transition guidance.

Receiving Support Team: If it is determined that OIT will take on the application, Support Teams participate in Service Catalog documentation, process documentation, knowledge base articles, support team assignments, and planning to ensure readiness to assume ongoing maintenance.

COMPLIANCE & ENFORCEMENT

RELATED RESOURCES

• IT Transition Request Form (to be written)
• IT Application Development Standards Policy (in draft)
• OIT Architecture Review Guidelines (in draft)
• OIT Resource Planning Guidelines (in draft)
• OIT Service Catalog Guidelines (in draft)
• ITSM Standards (in draft)
  

IT Standards are developed by subject matter experts and approved by the Information Technology Committee, which consists of the CIO, the CISO, University Vice Presidents and other senior leaders.