Files are often organized by page
Kirby stores media with pages or at site level by default. Central collections are configurable. A dedicated DAM may be better when search, variants, governance and multi-channel delivery become more demanding.
Kirby CMS Migration · Sanity or Payload
Kirby Migration: Manage Media Centrally. Reuse Content Across Applications.
Is your Kirby website working, but files are scattered across page folders, content must be maintained in several places, or code and editorial changes are difficult to synchronize? It may be time to assess a separate content architecture.
Valanor evaluates whether improving Kirby is sufficient or migrating to Sanity or Payload provides more control. We engineer content models, asset migration, frontends and integrations while protecting search visibility.
Kirby CMS limitations: When a custom website grows more complex
Kirby is a flexible flat-file CMS. These challenges arise mainly when editorial, media and multi-application requirements expand; they are not universal Kirby defects.
Assets need reuse and usage visibility
Teams need stable references and knowledge of where assets appear. A shared Kirby media pool can be built, while usage tracking and broader governance require an explicit design.
Multiple applications need the same content
Kirby already offers REST APIs and structured blueprints. A separate content platform may be more economical when portals, applications and sites need common models and workflows.
Content updates and deployment must be coordinated
Default flat-file storage means teams should deliberately manage content synchronization, backups, staging and code deployment.
Large content trees demand careful structure
Many pages, media assets and global update operations can require indexing, cache planning and suitable content organization. Performance depends on the actual implementation.
Customized templates and plugins add maintenance
Blueprints, PHP templates, plugins and Panel extensions provide flexibility, but heavily customized sites can increase upgrade and onboarding effort.
Kirby asset management: Shared media pool or independent DAM?
Kirby can reuse shared files. The question is how much asset governance your organization needs.
Kirby supports files attached to pages or the site. Files Sections can display files from other parts of the site; Blueprints can direct uploads to a central media page. A blanket claim that Kirby lacks central media management would be inaccurate.
For teams delivering assets to multiple websites, portals and marketing channels, the requirements may extend to metadata, rights, renditions, usage tracking, search and consistent delivery.
We first assess whether a well-structured Kirby media pool solves the problem. When a dedicated DAM adds value, we can integrate Cloudinary or ImageKit and separate media responsibilities from content schemas. See our Platform Engineering services.
Kirby's documentation explains page- and site-level files and configurable Files Sections. We review these native options before proposing another media system.
Should you replace Kirby or modernize the existing setup?
The business workflow and operating model determine the architecture.
Kirby can remain a sound and economical choice for custom websites with manageable editorial requirements. It supports structured blueprints, APIs, multilingual content and adaptable editing interfaces.
A new content platform becomes relevant when several applications share content, publishing processes must be decoupled from frontend releases or media and integrations grow more complex.
We assess current features, data structures, assets, permissions, hosting and ongoing cost before recommending a move. Our Consulting & Diagnostics service provides that decision basis.
Kirby's REST API already supports using content in other applications. The architecture choice is therefore based on requirements and operating costs, not an assumed lack of API access.
What a Kirby migration should enable beyond a new CMS
Success means better systems and capabilities, not exchanging a CMS logo.
One content model across applications
Structured data can serve websites, customer portals and product interfaces without duplicate editorial maintenance.
Controlled Schema as Code
Sanity and Payload use code-defined models and validation. Kirby also has code-based blueprints; the differences are primarily in architecture, integration and operations.
Shared design systems and components
Frontend components and design tokens can be reused across products where their frameworks and technical requirements allow.
Assets with clear ownership
A DAM can separate asset search, transformation and delivery from page-specific content when a dedicated media workflow is justified.
Explicit integration boundaries
ERP, CRM, search and other applications communicate through designed APIs, permissions and error handling.
Kirby vs Sanity vs Payload: A decision framework
Each option has a different operational fit. We choose against real use cases.
Our guide to Sanity CMS explains what changes when structured content becomes a separate API-driven service.
Content: one website or multiple applications?
Kirby: a practical fit for tailored websites with structured content and APIs. Sanity: suited to reusable content serving several websites, portals and applications independently. Payload: suited to content models integrated closely with a custom TypeScript application.
Asset management: shared pool or dedicated DAM?
Kirby: page- and site-level files with configurable shared Files Sections. Sanity: managed assets referenced from content models. Payload: upload collections for files. For rights management, many variants, advanced discovery and cross-channel delivery, assess a dedicated DAM regardless of CMS choice.
Editorial releases: how much separation is needed?
Kirby: Panel and blueprints with file-based content by default; plan deployment and content synchronization deliberately. Sanity: Studio, Content Lake and API-based publishing separate from frontend releases. Payload: editing and data close to the application, with corresponding deployment and operational ownership.
Operating model: who owns the cost and infrastructure?
Kirby: lean for suitable websites but requires hosting and custom-plugin maintenance. Sanity: managed content platform with usage-dependent fees plus a separate frontend. Payload: more direct control of database and hosting, with greater operational responsibility. Compare total cost over multiple years.
Frontend, search and integrations engineered for the actual workload
Content, components and application code can have independent lifecycles.
Astro can be suitable for content-heavy websites. Next.js or React Router may fit interactive applications. Rendering, preview, hosting and the team's capabilities determine the final choice.
Algolia or Typesense can support more demanding search. Cloudinary or ImageKit can handle asset transformations and delivery when justified; neither is automatically required.
We define APIs, content ownership, permissions, preview, tests and monitoring together so that future products can reuse the foundations without duplicating every feature.
How we migrate Kirby to Sanity or Payload
Content, files, URLs, functionality and editorial workflows need one coordinated plan.
01 · Audit Kirby content and dependencies
Inventory blueprints, page trees, languages, plugins, templates, media, metadata, URLs and connected systems.
02 · Design the target schemas and asset strategy
Map fields and blocks to target models. Define asset references, metadata, usage requirements and whether a DAM is necessary.
03 · Transfer content and media with validation
Transform text files, structured fields, relationships and assets. Verify metadata, alternative text, file links and image renditions.
04 · Test frontend and editorial workflows
Validate components, preview, roles, languages, forms, search and external integrations with realistic cases.
05 · Protect SEO during cutover
Map URLs and 301 redirects, verify canonicals, hreflang, metadata, structured data and internal links, then monitor indexing.
Kirby migration cost: What drives the effort?
Page count alone does not define migration complexity.
Main cost drivers include custom blueprints, plugins, Kirby blocks, asset volume and references, locales, URL structures, integrations and editorial workflows.
We separate content migration, frontend, DAM, APIs, SEO, testing and ongoing operations. Central media management can also be implemented without replacing the CMS.
Whether Kirby, Sanity or Payload is the best investment depends on the full operating model. No migration guarantees lower costs or improved rankings.
Relevant CMS modernization and decoupled platform experience
These cases demonstrate related engineering decisions, not completed Kirby migrations.
An ongoing project developing a decoupled web platform with content used by additional applications. It is not a Kirby migration.
An ongoing implementation with an independent Next.js frontend and retained WordPress CMS, demonstrating that replacement is not always justified.
FAQ: Kirby migration, asset management and CMS alternatives
Practical answers to media, platform and migration decisions.
Does Kirby store files only within individual pages?
No. Files commonly belong to a page or the site. Files Sections can display assets from a shared collection, while upload destinations and selection can be configured.
When is a shared Kirby media pool enough, and when is a DAM justified?
A shared Kirby media pool may be sufficient for one website, a small editorial team and limited delivery channels. A dedicated DAM becomes more useful when several teams need centralized rights, variants, discovery, approvals and cross-channel delivery. Assess that independently of the CMS decision.
Is Kirby unsuitable for large websites?
Not inherently. Large page trees and media collections require planned content structure, caching and indexing. Assess the current system before making performance claims.
Does Kirby offer a headless API?
Yes. Kirby provides a REST API and structured blueprints. Moving to Sanity or Payload is about architecture and operational fit, not the absence of an API.
How does Kirby differ from Sanity?
Kirby is a customizable file-based CMS with PHP templates and blueprints. Sanity provides a separate API-driven content platform with code-defined schemas and customizable editing interfaces.
When should we use Payload instead of Kirby?
When a TypeScript application benefits from closer integration of CMS, custom logic, database and hosting. Team expertise and operating responsibility still matter.
How are Kirby pages and images migrated?
We inventory blueprints, file paths, locales and references, transform content to target schemas and transfer media with metadata. Then we test links, previews and redirects.
Can Kirby migration impact SEO?
Rankings cannot be guaranteed. We plan redirects, canonicals, relevant metadata, hreflang and structured data, and monitor crawling and indexation.
How much does it cost to migrate from Kirby?
Costs depend on templates, plugins, content types, assets, locales, integrations and frontend development. A reliable estimate starts with an audit.
Can we improve Kirby without migrating?
Yes. A shared media pool, better blueprints, deployment controls or targeted integrations may solve the problem without replacing the CMS.
Kirby CMS Migration · Sanity or Payload
Discuss your Kirby migration and target architecture.
Need a central asset workflow, reusable content or smoother releases? We assess your Kirby implementation and recommend a justified improvement or migration.
Aleksandar Basara
Managing Director
aleks@valanor.co
+49 (0) 711 16 44 6 83
Lindenspürstrasse 22, 70176 Stuttgart
