Cascade CMS is the platform of choice for hundreds of higher education institutions. Hannon Hill has built a solid product, and the SaaS model means the application layer is genuinely managed — upgrades, uptime, and feature releases are Hannon Hill's responsibility.
What most Cascade CMS customers don't fully account for is the infrastructure that receives published output. When a content editor clicks Publish, the files go somewhere. That somewhere is a web server, a CDN, a load balancer, and an origin server. None of that is Hannon Hill's concern.
What Hannon Hill Actually Manages
The Cascade CMS SaaS product covers the publishing application itself: the CMS interface, the publishing engine, the workflow tools, and the SaaS infrastructure that runs them. Hannon Hill maintains the application, applies patches, and guarantees its availability.
That scope ends at the publish destination. Once files leave Cascade CMS, they land on infrastructure that the institution is responsible for configuring, securing, and operating.
The Infrastructure Nobody Assigned
In a typical Cascade CMS deployment, the published output goes to:
- A web server (Apache, Nginx, or IIS) receiving static files
- A staging environment for preview and review
- A production environment serving the live site
- CDN configuration for caching and global delivery
- Load balancers if the site receives significant traffic
- SSL certificate management and renewal
- Backup processes for the published file system
This is the hosting gap. Not a Hannon Hill gap — they're clear about their scope. A gap in how institutions procure and assign operational responsibility for the non-SaaS half of the stack.
How the Gap Typically Manifests
The pattern we see most often: the institution signed up for Cascade CMS years ago. IT provisioned a server. A developer configured it. The developer moved on or moved to a different role. Nobody documented who owns patching. The SSL certificate auto-renewed until it didn't. Publish performance degraded as the server aged and nobody investigated why.
When something breaks, the institution opens a ticket with Hannon Hill. Hannon Hill confirms the CMS is functioning. The issue is below their scope. The institution isn't sure who to call.
The institution that treats Cascade CMS as a fully managed product often discovers they've been operating an unmanaged server for years. The CMS is fine. The infrastructure it publishes to is not.
Active Directory and SSO Are Also Outside Hannon Hill's Scope
Most higher education institutions use Active Directory for identity management. Cascade CMS supports SAML-based SSO so that editors log in with their institutional credentials. This integration is valuable — and frequently broken.
SAML configuration is brittle. Certificate rotations break SSO. Active Directory changes affect attribute mapping. When it breaks, diagnosing it requires someone who understands both the Cascade CMS SAML configuration and the institution's Active Directory environment. Neither Hannon Hill support nor the AD team necessarily has full visibility into the other side of the integration.
What Managed Operations Looks Like for Cascade CMS
This is exactly what Cascade Website Hosting is built to operate. A managed operations engagement for a Cascade CMS institution covers what Hannon Hill doesn't:
- Production and staging infrastructure on AWS or Azure under SLA
- OS and server software patching on a defined schedule
- CloudFront or Azure CDN configuration for performance
- SSL certificate management and automated renewal
- SAML/Active Directory SSO configuration and ongoing maintenance
- Publish performance monitoring and optimization
- Backup with validated restore testing
- 24x7 monitoring with defined escalation on outage or publish failure
The result is that Hannon Hill manages the CMS, and a managed operator manages everything else. The institution has a defined owner for every layer of the stack. This is the model behind purpose-built Cascade hosting for higher-education institutions.