Keep Laravel; test the workflow that will change
The migration changes how content is stored, reviewed, templated, and deployed. Preserve the parts of Statamic that justify their place until editors and developers have accepted the replacement workflow.
Map collections and taxonomies
Rebuild templates deliberately
Decide what happens to Git review
Preserve the editorial workflow
Map familiar content and publishing tasks before changing CMS conventions.
A move from Statamic should solve a demonstrated project problem while preserving the work editors already do well. Use the existing blueprints, assets, URLs and add-ons as a migration inventory. Capell may offer a useful Filament-centred destination, but the pilot must establish that fit.
What normally transfers
Collections and taxonomies, entries, locales, metadata, routes, and asset references can usually be parsed and mapped. The content-model owner decides which collections become pages, reusable records, or application-owned data.
What needs mapping or rebuilding
Blueprints and fieldsets need target schemas. The Antlers and template owner rewrites Antlers, Blade, partials, tags, modifiers, and build assumptions rather than promising mechanical conversion. The Git workflow owner decides which content leaves pull-request review and what stays as code.
What may not transfer cleanly
Custom addons, Bard sets, repository conventions, generated assets, and implicit relationships may need bespoke work. The asset owner checks source files, transforms, alt text, rights, folder assumptions, and broken references.
Verify URLs and search metadata
The URL owner records routes, aliases, language paths, redirects, canonicals, metadata, sitemap entries, and static-cache behaviour. Validation verifies high-value routes and a representative sample before migration, in the pilot, and after cutover.
Run a representative pilot
Move one collection with taxonomies, assets, an Antlers or Blade template, addon behaviour, and an editorial review step. Editors repeat their normal task while developers verify rendering, routes, metadata, asset output, cache behaviour, and rollback.
Plan cutover and rollback
The cutover owner defines the content freeze or final repository merge, export, database import, route switch, cache warm-up, monitoring window, and acceptance sequence. Keep the Statamic deployment recoverable until every owner signs off.
Statamic may remain the better fit after this work. Move only when the new Eloquent, Filament, and publishing model improves the project enough to justify changing a successful content-first workflow.
Map fields and behaviour
Map each field's purpose before choosing its Laravel publishing definition.
Review collections, blueprints, field types, relationships, language versions and media metadata. Identify which values belong to a Capell page family and which represent application behaviour or a separate package requirement.
Inspect add-ons and template assumptions alongside the records. Some fields need editorial cleanup or a different representation rather than a direct import. Preserve the information editors need and make any intentional change explicit.
Prove the public result
Keep URLs, previews and cutover decisions visible.
Record existing addresses, redirects, metadata and important navigation paths. Trial the new public template and check the content, media and enquiry journey. A successful export does not establish a complete destination website.
Agree a final write freeze and reconciliation process. Keep the source recoverable until editors and the technical owner accept the new result. If the new workflow costs more than the problem it solves, staying with Statamic remains a valid outcome.
Map editorial intent alongside the fields
Cover the content model, Antlers and templates, assets, URLs, editor acceptance, Git workflow, and cutover before implementation begins. On a small team, one person may own several areas; keep every responsibility and acceptance check visible.
2 keep 4 replaced by Capell 2 to decide
-
In your Statamic site Collections and entries In Capell Database-backed page and content records Capell replaces
Entries can become pages, content sections, field notes, or package-owned records depending on how they are edited and rendered. Content leaves flat files for a queryable database.
-
In your Statamic site Blueprints and fieldsets In Capell Page types and widget schemas Capell replaces
Reusable field structure belongs in page types, Layout Builder widgets, or package schemas instead of staying coupled to one template.
-
In your Statamic site Antlers templates In Capell Blade views and theme assets Capell replaces
Templates are rewritten rather than converted. Antlers partials usually map cleanly onto Blade components, widgets, and theme views, and the logic moves into a stack the rest of Laravel shares.
-
In your Statamic site Public URLs, slugs, and redirects In Capell The same routes, verified during the move Keep
Slugs, aliases, redirects, canonical URLs, language paths, and sitemap output should be verified as part of the migration, and existing addresses can be preserved and verified.
-
In your Statamic site Your Laravel app and hosting In Capell Retained where compatible Keep
Statamic already lives inside Laravel, so the application, server, and deploy pipeline can usually carry over. Capell requires Laravel 13 (Illuminate 13) and PHP 8.4, while Statamic officially supports Laravel 12 and 13, so an application on Laravel 12 must upgrade first. Confirm the requirements and run a pilot before treating hosting as unchanged.
-
In your Statamic site Addons, tags, and modifiers In Capell Composer packages or app code You decide
Custom tags, modifiers, fields, or workflows that keep recurring can become Capell packages; one-off helpers usually land as plain Laravel code in the app.
-
In your Statamic site Git-based content review In Capell CMS publishing workflow You decide
Content edits stop arriving as pull requests. Decide whether editorial review moves into drafts and publishing inside the admin, or whether parts of the content should stay in the repository as code.
-
In your Statamic site Static caching In Capell Optional HTML Cache package Capell replaces
Full-page HTML caching is not part of Capell Core. The optional HTML Cache package caches rendered pages and invalidates them when content changes; install and evaluate it as a configured feature.
Statamic work has mixed-system risks
A Statamic migration already has enough scope. Follow an adjacent guide for a legacy WordPress area, an active API consumer, or custom Filament resources rather than merging those risks into one vague estimate.
Questions
Questions that belong in the Statamic pilot
Where does content live after the move?
In your Laravel database instead of flat files. Pages, URLs, media, translations, and settings become structured records you can query, index, and cache, while Git keeps holding your code.
Review content model
What happens to my Antlers templates?
They are rewritten in Blade. Most Antlers partials map onto Blade components, theme views, and widgets, and the templating skills transfer quickly because both stay close to HTML.
View themes
How do collections and blueprints map to Capell?
Collections generally become pages or custom content types, and blueprints become page types and widget schemas. Plan this mapping first, because it decides how editors work day to day.
See page building
Can I run Statamic and Capell side by side during the migration?
Yes. A common path is to stand up Capell in a fresh Laravel app, migrate content section by section, and switch routes over once each area is verified, keeping redirects for anything that moves.
Read install path
Do editors lose the control panel?
They trade it for a Filament workspace: structured fields, previews, drafts, publishing flow, and media management, with roles that keep day-to-day edits away from code.
See editor fit