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 does not provide a delivery API.
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.