At Sengo, we’ve helped enterprise teams navigate Optimizely SaaS migration projects from assessment through go-live. Whether you’re evaluating the move or already committed, this guide gives you a practical framework to plan with confidence.
Jean-Nicolas Gauthier
If you’re running Optimizely on PaaS (DXP) today, the question isn’t whether to consider an Optimizely SaaS migration — it’s when. Optimizely has made its direction clear: the future is SaaS. Their latest releases focus on the SaaS-native CMS, and PaaS customers are being encouraged to plan their transition now. This guide covers everything you need to know before you switch, from architecture differences to content migration strategies and common pitfalls that derail timelines.
The difference between Optimizely SaaS and PaaS goes deeper than hosting. On PaaS (formerly DXP), you deploy your .NET application to Optimizely’s managed cloud infrastructure. You control the codebase, the deployment pipeline, and the server configuration. It’s flexible, but that flexibility comes with operational overhead — patching, scaling, and infrastructure management are your responsibility.
Optimizely SaaS, by contrast, is a fully managed content management platform. The CMS runs as a multi-tenant service. You interact with content through a visual editor and APIs, not through server-side code. Front-end delivery is decoupled — you build your presentation layer using any framework (Next.js, React, or any other) and connect it via Optimizely’s Graph and Content Delivery APIs.
This architectural shift means several things for your team:
Before starting your Optimizely SaaS migration, you need a clear picture of what’s involved. This checklist covers the key areas every team should assess:
Document every content type, page template, and block type in your current PaaS instance. Identify which content types have direct equivalents in SaaS and which need restructuring. Pay special attention to custom properties, validation rules, and content references — these often require manual mapping.
List every integration: search (Optimizely Search & Navigation or third-party like Coveo), analytics, personalization, CRM, DAM, e-commerce, and marketing automation. Each integration needs a SaaS-compatible replacement or reconfiguration. Some integrations that relied on server-side events will need to shift to webhooks or API-based triggers.
Evaluate all custom code: scheduled jobs, initialization modules, custom APIs, event handlers, and business logic embedded in the CMS layer. In the SaaS model, this logic moves to your front-end application, a middleware layer, or serverless functions. Nothing runs inside the CMS anymore.
Choose your front-end framework and hosting platform. Most teams select Next.js on Vercel or Netlify for Optimizely SaaS projects. Additionally, define your component library, design system, and build pipeline early — these decisions affect every subsequent phase.
If you run multiple languages or sites, plan how they’ll work in SaaS. The localization model differs from PaaS. Review your URL structure, language fallback rules, and translation workflows to ensure nothing breaks during the transition.
The most significant effort in an Optimizely SaaS migration is the code transformation. Here’s what changes and what stays:
| Component | PaaS (DXP) | SaaS CMS |
|---|---|---|
| Page templates | Razor views / MVC controllers | Front-end components (React/Next.js) |
| Content types | C# classes with attributes | Visual editor definitions + Graph schema |
| Content delivery | Server-side rendering | API-first (Graph / REST) |
| Scheduled jobs | .NET scheduled jobs | External (Azure Functions, cron) |
| Search | Optimizely Search & Navigation | Optimizely Graph or third-party |
| Personalization | Server-side visitor groups | Client-side / Optimizely Data Platform |
The front-end rebuild is typically the largest workstream. Every page template and block rendering needs to be recreated as a JavaScript component that consumes content from Optimizely Graph. However, your content structure, editorial workflows, and business logic can largely carry over — they just live in different places.
Content migration is where many Optimizely SaaS migration projects hit unexpected delays. The content model in SaaS differs from PaaS, so a direct database migration isn’t possible. Instead, you need a structured approach:
Step 1: Map content types. Create a mapping document between your PaaS content types and the SaaS equivalents. Identify gaps where properties don’t have direct equivalents and decide how to handle them — merge, split, or deprecate.
Step 2: Export content via APIs. Use the Optimizely Content Delivery API on your PaaS instance to export content in a structured format. This ensures you capture published content, drafts, and metadata accurately.
Step 3: Transform and import. Build transformation scripts that convert exported content into the SaaS content model. Import using the SaaS Management API. Validate every piece of content — broken references, missing media assets, and orphaned blocks are common issues.
Step 4: Validate with editors. Have your content team review migrated content in the SaaS editor. Automated validation catches structural issues, but only human review catches visual and contextual problems. Build time for this review into your timeline.
Timeline and cost depend on the complexity of your current implementation. Here are realistic ranges based on our experience with Optimizely SaaS migration projects:
These estimates include assessment, development, content migration, testing, and go-live support. They don’t include Optimizely licensing costs, which change when you move from PaaS to SaaS. Consequently, factor in licensing discussions with your Optimizely account team early in the planning process.
An Optimizely audit before committing to the migration gives you accurate scope and budget estimates specific to your implementation.
After working on multiple Optimizely SaaS migration projects, we’ve identified the mistakes that consistently cause delays and budget overruns:
Teams often assume they can reuse existing front-end code. In practice, moving from server-rendered Razor views to a decoupled JavaScript application is a full rebuild. Budget for it accordingly, and start the front-end workstream early.
Optimizely Search & Navigation doesn’t exist in SaaS. You need to migrate to Optimizely Graph or a third-party search solution. This affects site search, navigation, filtering, and any feature that relied on indexed content queries. Plan for this early — it’s not a minor configuration change.
Migrating all content as-is usually means migrating years of outdated, duplicate, and unused content. Use the migration as an opportunity to clean up. Archive what you don’t need, consolidate duplicate content types, and simplify your content model for SaaS.
The SaaS editor is different from the PaaS editor. Your content team needs training and transition time. Failing to plan for this creates friction post-launch and slows content operations when they should be accelerating.
Some teams plan extended parallel-run periods to reduce risk. In reality, maintaining two platforms doubles your operational cost and creates content synchronization nightmares. Set a firm cutover date and work backward from it.
An Optimizely SaaS migration is a significant undertaking, but it’s also an opportunity to modernize your digital platform, reduce operational overhead, and unlock capabilities that PaaS can’t deliver. The key is planning thoroughly before writing a single line of code.
At Sengo, we specialize in CMS and DXP migrations — including Optimizely SaaS migration projects. We start with an assessment that gives you a clear scope, timeline, and budget before you commit to anything. No guesswork, no surprises.
Like (0)