Finding the Bigger Project Inside a Deadline: A Digital Strategy for the University of Colorado

The Challenge: A Platform Question With an Institution Behind It

Someone in the Controller’s office needs to update a page. They open the editor, find one long text field and start writing HTML by hand: a shortcode, placed just so, to build the two-column layout that thousands of university employees will read tomorrow.

That was the daily reality of publishing at the University of Colorado, and it was the reality for 52 department sites at once.

The university’s system website had been publishing continuously for nearly thirteen years. In that time it had grown to hold roughly 8,500 pieces of content across those 52 departments, on one Drupal platform that no single department owned. Employee Services alone held more than 2,000 records. The Controller’s office held close to 1,900. Each department had its own audiences, its own approvals and its own idea of what the site was for — which is the condition a university system publishes in, rather than a fault in how this one had been run.

And a date on the calendar. The release the site ran on was reaching end of life, which made the request both reasonable and urgent: get onto a supported version, and get there quickly. CU engaged Pare & Co to scope that migration.

The question CU asked was about a platform. The question underneath it was about how a federation of 52 departments publishes at all.

The Strategy: Understand the Institution Before Recommending a Platform

Talk to the people who publish, count what is actually there, then put three costed paths in front of the people who have to choose.

• Talk to the departments who publish every day. We interviewed stakeholders across six groups: Advancement and the CU Foundation, Budget and Finance, Employee Services and University Information Services, Policy and Efficiency, System Administration and the Procurement Service Center. Each conversation asked the same practical question about content types and features: keep, change or retire. The people closest to a constraint describe it most precisely.
• Count what is there before pricing the work. We inventoried the content department by department, and the features holding it up. A number like “8,500 records across 52 sites” changes a conversation, because it converts a feeling that the project is large into a figure a budget committee can act on.
• Establish what can carry forward, and what cannot. Parts of the site depended on custom work with no supported path ahead of it, which meant new work was needed whichever direction the university chose. Knowing which parts, and how much of the site rested on them, is what separates a costed recommendation from a guess.
• Read the shortcodes as an authoring problem. The shortcode system was a component system, built before component systems were standard, and the departments had made it work through years of careful manual effort. Read as a technical detail it’s a migration task. Read as a daily-work problem it’s the reason editors across the university were writing HTML to do their jobs, and that framing is what put a modern authoring experience at the center of the recommendation.
• Propose an architecture, and say why. We recommended giving each department its own subdomain in place of a shared structure no one owned. It gives each department clear separation while keeping it adjacent to the main domain, and it leaves the university free to move an individual site elsewhere later without unpicking the whole.
• Price every path, and recommend one. A staged migration onto subdomains, which we recommended and broke into three phases with costs and timelines for each. A single-launch migration keeping the existing structure. A multi-site architecture with separate hosting. Each one written with its disadvantages stated as plainly as its advantages, because a recommendation no one can argue with isn’t a recommendation.

The Outcomes: A Deadline Became a Decision

Trust. We recommended the larger project. The discovery concluded that a like-for-like move onto a supported release would not serve the university, and said so directly: “After a comprehensive review of the current cu.edu website, it is clear that a simple re-platforming … is not a viable solution. Therefore, we recommend treating this as a complete site redesign.”

The reasoning ran against the easier sale in both directions. Replatforming would move thirteen years of accumulated structure onto a new release without addressing the way people publish underneath it, and it would still be expensive, because everything the old platform depended on needs rebuilding either way. The faster path was not the cheaper one. That case was made in writing, with the alternatives priced beside it, so the university could weigh it rather than take our word for it.

Intelligence. The university ended the engagement knowing what it actually had. A department-by-department content inventory. A current content model and a proposed one. A documented account of what the platform could and could not carry forward, plus the stakeholder interviews synthesized into a single set of findings. That inventory outlives the migration decision. It is the reference any future platform conversation starts from.

Engagement. The recommendation came from the departments. The clearest finding in the interviews was that the appetite for something more than a version upgrade already existed inside the university. Accessibility came up as a universal concern across every group. So did granular permissions, content moderation workflows and better media management. The synthesis recorded it plainly: “There was an interest in the opportunity for a redesign and an overall modernization of the platform.” Our job was to give that instinct evidence, structure and a price.

Growth. A deadline became a decision. The platform’s end of life set the date. What the discovery established is what the university would build against it: WCAG 2.2 AA as a design input rather than a remediation project, a modern authoring experience for the people who publish daily, search that reaches across every department site and an architecture with somewhere to go next.

The migration was the question CU asked. The discovery’s job was to make sure it was the right one.