Why migrate from PaaS to SaaS
Section titled “Why migrate from PaaS to SaaS”CMS PaaS runs on infrastructure you manage — .NET hosting, database servers, deployment pipelines, security patches. This gives control but demands ongoing operational investment. As the CMS SaaS platform matures, the calculus shifts: SaaS handles infrastructure, scaling, and updates, freeing your team to focus on content strategy and frontend development.
The migration is not a lift-and-shift. CMS SaaS has a different content modeling approach (Visual Builder vs traditional templates), a different delivery model (headless-first via Graph vs server-rendered), and a different deployment model (managed vs self-hosted). This recipe provides the sequence for planning and executing the migration.
Architecture overview
Section titled “Architecture overview”┌─────────────────────────────────────────────────┐│ Current: CMS PaaS ││ .NET templates, server-rendered pages, ││ database-backed content, self-hosted │└──────────────────────┬──────────────────────────┘ │ migration phases ▼┌─────────────────────────────────────────────────┐│ Phase 1: Content Model Mapping ││ Map PaaS content types → SaaS content types ││ Identify gaps and transformation needs │├─────────────────────────────────────────────────┤│ Phase 2: Graph Delivery Setup ││ Configure Graph, build frontend, test queries │├─────────────────────────────────────────────────┤│ Phase 3: Content Migration ││ Export PaaS content, transform, import to SaaS │├─────────────────────────────────────────────────┤│ Phase 4: Cutover ││ DNS switch, URL redirects, PaaS decommission │└─────────────────────────────────────────────────┘Phase 1: Content model mapping
Section titled “Phase 1: Content model mapping”Audit your PaaS content types and map each to a SaaS equivalent.
| PaaS concept | SaaS equivalent | Migration notes |
|---|---|---|
| Page types (.NET classes) | Content types (Visual Builder) | Flatten deep inheritance hierarchies |
| Block types | Component types | Reusable components in Visual Builder |
| Content areas | Composition slots | Different nesting model |
| Categories | Tags/taxonomies | Simpler taxonomy in SaaS |
| Visitor groups | Visitor groups (ODP-backed) | Rebuild using ODP segments |
Key differences to plan for:
- SaaS does not support .NET code-behind logic — move business logic to the frontend or edge functions
- SaaS content types are defined in the UI, not in code
- Property types may not map 1:1 — identify transformation needs early
Phase 2: Set up Graph delivery and frontend
Section titled “Phase 2: Set up Graph delivery and frontend”Before migrating content, build the delivery infrastructure:
- Configure Graph on the SaaS instance and verify the schema reflects your content types
- Build the frontend application (Next.js, Nuxt, or your framework of choice) with Graph queries for each page type
- Implement URL routing that matches your current URL structure to preserve SEO equity
- Set up preview mode so content authors can review pages before publish
Test the frontend with sample content created directly in SaaS before attempting data migration.
Phase 3: Content migration
Section titled “Phase 3: Content migration”Export content from PaaS and transform it for SaaS import:
- Export PaaS content using the Content API or a database export. Include all properties, media references, and content relationships
- Transform the data to match SaaS content type structures. Handle property type differences, flatten inheritance, and resolve media references
- Import to SaaS using the Content Management API. Validate each imported item against the expected schema
- Verify content integrity — compare page counts, property values, and media assets between PaaS and SaaS
Run the migration on a staging environment first. Fix transformation issues before migrating production content.
Phase 4: Cutover
Section titled “Phase 4: Cutover”Plan the cutover as a coordinated event:
- Content freeze — stop PaaS content editing 24 hours before cutover
- Final migration — run the migration script one last time to capture any changes
- URL redirect map — configure 301 redirects for any URLs that changed between PaaS and SaaS
- DNS switch — point your domain to the new frontend
- Verify — check top 50 pages, all navigation paths, and conversion flows
- Monitor — watch for 404s, broken images, and traffic anomalies for 7 days
Post-migration: decommission PaaS
Section titled “Post-migration: decommission PaaS”After confirming the SaaS site is stable:
- Keep PaaS running in read-only mode for 30 days as a rollback option
- Export any remaining data (analytics, logs, custom integrations)
- Cancel PaaS hosting and infrastructure
- Update internal documentation and training materials
When to use this pattern
Section titled “When to use this pattern”Migrate when the operational burden of PaaS exceeds the value of the control it provides, or when your content strategy requires headless delivery that SaaS offers natively. Delay migration if you depend heavily on custom .NET logic that cannot be replicated in a headless architecture — address those dependencies first.