Name every consumer before removing the API
Capell Foundation has no delivery API; the optional API package (beta, free) returns read-only JSON for published pages only. Plan a coupled migration only when the Laravel website can own delivery and every independent consumer has a supported destination or a deliberate retirement decision.
One app, not two Keep your structure Delivery you control
Bring the consumers with you
Map the content contract before moving records out of a headless CMS.
A headless migration affects every consumer that depends on its responses. Before choosing Capell, decide which experiences will render in Laravel and which still need an independent API. The destination must fit that boundary, not simply accept the exported content.
What normally transfers
Entries, content models, assets, locales, taxonomies, metadata, references, and URL records can usually be exported. The content-model owner decides how remote schemas map to pages, reusable records, or application-owned data.
What needs mapping or rebuilding
The API consumer owner inventories every website, application, feed, partner, and build process. The webhooks and query assumptions owner records SDK versions, filters, pagination, draft access, locale fallback, schema expectations, retries, build triggers, and downstream jobs.
What may not transfer cleanly
Provider-specific references, deeply nested content, unpublished states, asset transforms, and webhook order may need bespoke work. The multi-channel dependency owner must approve a destination or retirement plan for each consumer because Capell Foundation has no delivery API and the optional API package (beta) only returns read-only JSON for published pages.
Verify URLs and search metadata
For the Laravel website, inventory routes, metadata, canonicals, languages, media, sitemaps, and redirects. For every other consumer, verify the fields and behaviour its current query contract provides before changing the source.
Run a representative pilot
Move one content model with linked records, assets, locales, preview, webhook effects, and a query used by a real consumer. The editor acceptance owner tests drafting and preview; consumer owners compare outputs; the technical owner checks public HTML, logs, jobs, and rollback.
Plan cutover and rollback
The cutover owner defines the content freeze, final export, credential changes, webhook pause, route switch, consumer release order, monitoring window, and go or no-go decision. Keep the headless service readable and recoverable until every named consumer passes verification.
Do not remove a valuable API simply to reduce the number of systems. Proceed only when the inventory proves the Laravel site can own delivery and the migration removes more coordination than it creates.
Map what consumers expect
Preserve the contract deliberately or plan an explicit change.
Inventory API fields, identifiers, media URLs, relationships, locales and unpublished-content rules. Find the consumers and their owners, including scheduled jobs and external integrations. A renamed field can be as disruptive as a missing record.
Capell's optional API package is beta and read-only for published pages. Trial the actual scope against each consumer requirement; do not assume it replaces a mature platform's entire API or preview integration.
Coordinate the change
Keep publication, consumer deployment and cache freshness aligned.
A content import and a frontend deployment may need different timing. Agree how the consumer switches contract, which system accepts edits and how stale cached content is refreshed. Preview access needs its own verified path.
Reconcile the data and run the real visitor journeys before cutover. Keep the previous provider recoverable until consumer acceptance is complete. If the required contract cannot be reproduced responsibly, reconsider the migration or retain the split.
Map contracts before moving entries
Cover the content model, API consumers, webhooks and query assumptions, assets, editor acceptance, multi-channel dependencies, and cutover. On a small team, one person may cover several responsibilities; none of the checks should disappear.
2 keep 4 replaced by Capell 3 to decide
In your headless stack Content entries In Capell Records in your Laravel database Capell replaces
Headless exports are vendor-specific. Migration Assistant supports mapped CSV or XML imports into Capell; relationships, assets, routes, and preview assumptions still need an explicit source-to-target map.
In your headless stack Your frontend components In Capell The same markup, fed by Blade or Livewire Keep
Design systems and component markup may carry over when they already belong to Laravel. An independent frontend that requires the vendor API needs its own replacement decision; Capell does not supply that API.
In your headless stack API calls and SDK glue In Capell Direct data access in one app Capell replaces
Page data comes from the CMS runtime in the same codebase, so the fetch wrappers, retry logic, and cache-invalidation glue around the content API can be retired.
In your headless stack A separate frontend deployment In Capell One Laravel deploy Capell replaces
One repository, one pipeline, one place to look when something breaks. Routing, policies, tests and deployment stay in the Laravel project your team controls.
In your headless stack Preview tokens and preview builds In Capell Drafts and previews in the admin Capell replaces
Editors preview unpublished work inside the Filament workspace, with no token wiring or preview deployment to keep alive.
In your headless stack Webhooks and build triggers In Capell Laravel events and jobs, where still needed You decide
Triggers that only existed to rebuild the frontend go away. Hooks that other systems depend on need a new home in Laravel events, jobs, or scheduled commands.
In your headless stack Asset CDN or DAM In Capell Capell media, or the setup you already trust You decide
Media can move into Capell records, or stay on the current CDN with Capell storing references. Volume and team workflow decide.
In your headless stack Translation vendor workflow In Capell Language variants stored in the CMS You decide
Capell holds per-language content and paths. If a vendor pipeline feeds translations today, plan the handoff format before the move.
In your headless stack Your domain and URLs In Capell The same public routes Keep
Canonical paths, redirects, and sitemap output move under your control in Laravel, and existing addresses can be preserved and verified.
Decide whether the API should be removed
Return to the comparison before implementing. Use adjacent source guides only for genuine WordPress or custom-admin areas, not as generic next steps.
Role scenarios
What to inspect before migrating
Checks for mapping, redirects, media, integrations, cutover, recovery, and ownership.
Role-based checks drawn from product capabilities and fit boundaries.
Check import rollback after editing a record
Dry-run an import, inspect its field map, then edit one imported record before testing rollback. The process should skip bad items, preserve redirects and refuse to erase the later edit.
Read more Show less
Check that old permalinks redirect to their intended new destinations after import. Re-import the same source and confirm that corrections already made to migrated pages are preserved.
When to look elsewhere: A tiny, tidy source can still be faster to re-key by hand than to map. Site owners would only lean on this when there is real structure worth carrying across, and site owners would still keep a developer close.
Migrations: a Laravel technical lead acceptance check
Preview an import, inspect field mappings, dry-run it and edit one migrated record before rollback. The rollback must preserve the later human edit and report any source structure needing custom handling.
Read more Show less
A credible evaluation should confirm: That last detail separates a move developers trust from one developers cross their fingers over: an undo will not wipe the cleanup the delivery team already did on top. Developers see what maps across before committing, so the client gets a plan instead of a leap.
When to look elsewhere: Genuinely bespoke or badly structured sources still need custom handling. This shines when there is real structure worth carrying over; a thin, messy source can be quicker to rebuild by hand.
Import is the start, not the finish — what to verify
Import several pages as drafts, including one with awkward formatting and media placement. Nothing should publish automatically, and the result should produce a clear editorial cleanup queue.
Read more Show less
Operational evidence to check: Because pages land as drafts rather than going straight live, nothing rough surfaces to a visitor before editors have been through it. Editors get to read and fix the imported content on their own time instead of firefighting it in public.
Decision note: A big, messy source just means more tidying, and no tool removes that editorial pass. The mapping moves the content; making it read well once it lands is still their work.
Questions
Questions every API consumer owner must answer
Which consumers prevent the delivery API from being retired?
Capell Foundation has no delivery API, and the optional API package (beta) only returns read-only JSON for published pages. Content and public rendering move into the Laravel application that owns the website. Tour Capell
Can the current frontend stay?
Yes, when it is already a Laravel frontend. Replace remote content calls with hydrated Capell render data and keep the presentation code in the app. View themes
What happens to content models?
Map remote schemas into Capell page types and package-owned records. A developer still defines the Filament schemas; editors do not create arbitrary models. See owner fit
What should move first?
Start with one content type, its media, URLs, preview, and publishing path. Prove the coupled render before migrating the remaining collections. Explore features