CMS SaaS vs CMS PaaS — Choosing Your Platform

Why this decision matters

Optimizely offers CMS in two deployment models — SaaS (software as a service) and PaaS (platform as a service). They share the same content management DNA, but they differ in how you host, extend, and operate the platform. Picking the wrong model creates friction that compounds over time: infrastructure you did not need to manage, developer workflows that fight your team’s strengths, or feature gaps that force workarounds.

This page gives you a framework for making that choice based on your team, your architecture, and where your organization is headed.

What each model is

CMS SaaS

Optimizely hosts and operates everything. You get a managed service with automatic updates, built-in scaling, and no servers to maintain. Your developers define content types, build frontend experiences, and deploy through the Optimizely cloud pipeline. The editing experience centers on Visual Builder — a drag-and-drop page composition tool.

CMS PaaS

You host the CMS application on your own infrastructure (or a cloud provider like Azure). The CMS runs as a .NET application that you build, deploy, and maintain. You have full control over the runtime, middleware, custom code, and hosting environment. Content types are defined in C# and deployed with the application.

Feature comparison

Capability	CMS SaaS	CMS PaaS
Hosting	Optimizely-managed cloud	Self-hosted (.NET on Azure, AWS, or on-premises)
Updates	Automatic, continuous	Manual NuGet package upgrades
Visual Builder	Yes — drag-and-drop page composition	No — form-based editing with ContentArea
Content type definition	Code + UI-based (Visual Builder)	Code only (C# classes)
Frontend framework	Any (headless-first approach)	.NET templates (Razor/MVC) or headless via Graph
Server-side code	Limited — no custom middleware or startup code	Full .NET application with custom middleware, DI, background jobs
Database access	No direct access	Full SQL Server access
Deployment	Push to Optimizely cloud	CI/CD to your infrastructure
Scaling	Automatic	Manual (or cloud auto-scale rules you configure)
Extensibility	Content types, webhooks, Graph	Unlimited .NET extensibility — custom providers, scheduled jobs, event handlers
Graph integration	Built-in, always on	Available, requires configuration
Multi-site	Supported	Supported
Personalization	Supported (Optimizely platform)	Supported (Visitor Groups + Optimizely platform)

The editing experience

The biggest day-to-day difference between SaaS and PaaS is how content authors build pages.

CMS

Visual Builder lets authors compose pages by dragging components onto a visual canvas. Authors see a live preview as they work — no form fields, no guessing how the page will look. Components are defined by developers but assembled by authors without code changes.

CMS 12, 13

On PaaS, authors build pages using form-based editing. Content types present properties as form fields (text inputs, rich text editors, content pickers). ContentArea properties allow authors to add blocks, but the layout is controlled by developer-defined templates rather than a visual canvas.

For organizations where author productivity and design flexibility are priorities, Visual Builder in SaaS is a significant advantage. For organizations where content structure is tightly controlled and authors fill in predefined fields, the PaaS form-based model may be sufficient.

Developer experience

SaaS developer workflow

1. Define content types using the SaaS content modeling tools
2. Build frontend components in your framework of choice (React, Next.js, Vue, etc.)
3. Query content from Graph using GraphQL
4. Deploy frontend independently from the CMS

SaaS steers you toward a headless architecture. Your frontend is a separate application that consumes content through Graph. You do not write .NET rendering code.

PaaS developer workflow

1. Define content types as C# classes in a .NET project
2. Build views using Razor templates or MVC controllers
3. Optionally expose content via Graph for headless consumers
4. Deploy the entire .NET application to your hosting environment

PaaS gives you a full .NET application. You can add custom middleware, scheduled jobs, event handlers, dependency injection, and anything else the .NET ecosystem supports. This power comes with the responsibility of hosting and maintaining the application.

Key tradeoff

SaaS removes operational burden but limits server-side customization. PaaS gives you maximum flexibility but requires you to manage infrastructure and upgrades.

When to choose SaaS

SaaS is the stronger choice when:

• You want zero infrastructure management. No servers to patch, no deployments to orchestrate, no scaling to configure. Optimizely handles it all.
• Your team builds with modern frontend frameworks. If your developers work in React, Next.js, or Vue, SaaS plus Graph is a natural fit. There is no .NET rendering layer to maintain.
• Authors need visual page composition. Visual Builder gives non-technical authors the power to build pages without developer involvement for every layout change.
• You are starting a new project. New implementations benefit from the SaaS model’s simplicity and always-current platform.
• Speed to launch matters. Less infrastructure setup, automatic updates, and managed scaling reduce time to production.

When to choose PaaS

PaaS is the stronger choice when:

• You need deep .NET customization. Custom authentication providers, background processing, event-driven workflows, third-party integrations at the middleware level — PaaS gives you the full .NET runtime.
• You have existing .NET infrastructure and expertise. Teams with strong .NET skills and established CI/CD pipelines for .NET applications can be productive on PaaS immediately.
• Regulatory or compliance requirements mandate self-hosting. Some industries require hosting in specific data centers, on-premises environments, or government clouds that Optimizely SaaS may not cover.
• You have a large existing PaaS implementation. If your site already runs on CMS PaaS with extensive customizations, staying on PaaS (and upgrading to CMS 13) may be more practical than migrating.
• You need direct database access. PaaS lets you query the CMS database directly for reporting, data migrations, or custom integrations that go beyond the content API.

Migration path: PaaS to SaaS

Optimizely provides a migration path for organizations moving from PaaS to SaaS. This is not a lift-and-shift — it requires rethinking how your site is built because the rendering model changes fundamentally.

What migrates

• Content types — Your content model (types, properties, relationships) transfers to SaaS. Property definitions may need adjustment for SaaS-specific property types.
• Content instances — Pages, blocks, and media migrate with their content and hierarchy intact.
• Assets — Images, documents, and other media files transfer to the SaaS asset system.

What changes

• Rendering layer — .NET Razor views and MVC controllers do not migrate. You build a new frontend that consumes content through Graph.
• Custom server-side code — Scheduled jobs, event handlers, custom providers, and middleware need equivalent solutions (webhooks, external services, or Graph extensions).
• Database integrations — Direct SQL queries against the CMS database must be replaced with Graph queries or API calls.
• Hosting and deployment — You stop managing servers. Deployment moves to the Optimizely cloud pipeline.

Migration approach

1. Audit your customizations. Catalog every .NET extension, scheduled job, event handler, and database integration. Determine which have SaaS equivalents and which need external solutions.
2. Migrate content model. Transfer content type definitions to SaaS, adjusting property types as needed.
3. Export and import content. Use Optimizely migration tools to move content instances, preserving hierarchy and relationships.
4. Build new frontend. Create a frontend application that queries Graph for content. This is typically the largest effort.
5. Reimplement integrations. Replace server-side customizations with webhooks, external services, or Graph-based alternatives.
6. Validate and cut over. Test thoroughly in a staging environment before switching production traffic.

CMS 12

CMS 12 runs on legacy .NET Framework. If you are on CMS 12, consider whether to migrate to CMS 13 (modern .NET on PaaS) or to CMS SaaS. Going directly from CMS 12 to SaaS skips the CMS 13 upgrade effort, but the frontend rewrite is required either way.

Decision matrix

Use this matrix to score your situation. The column with more checks is likely the better fit.

Factor	Leans SaaS	Leans PaaS
Team has frontend (React/Next.js) expertise	Yes
Team has deep .NET expertise		Yes
Need Visual Builder for authors	Yes
Need custom .NET middleware or background jobs		Yes
Want automatic platform updates	Yes
Need to control hosting environment		Yes
Greenfield (new) project	Yes
Large existing PaaS codebase		Yes
Regulatory requirement for self-hosting		Yes
Priority is speed to launch	Yes
Need direct database access		Yes
Headless / multi-channel delivery is primary goal	Yes

Both models share

Regardless of which model you choose, you get the same core CMS capabilities:

• Content versioning, approval workflows, and scheduled publishing
• Multi-language and multi-site support
• Role-based access control
• Integration with Optimizely Graph for content delivery
• Compatibility with Optimizely One products (Experimentation, ODP, CMP)
• Content search and navigation

The differences are in how the platform is hosted, extended, and how authors compose pages — not in the fundamental content management capabilities.

📝 Check your understanding 3 questions

Related content

Continue your journey with these related pages.

📖Understand the concepts

• What is Optimizely CMS?
• Content Modeling in Optimizely
• Content Delivery with Graph

🔧Follow a guide

• Content Management guides