CMS migration guides for Laravel teams
List what must survive, what can be retired, and what needs rebuilding. Assign an owner to URLs, content, media, integrations, editor acceptance, infrastructure, and the final launch decision.
Move with a clear destination
Prove the difficult pages before committing the whole site to a migration.
A migration is a chance to reduce maintenance, but only if the new site preserves the work people depend on. Start with the content, URLs, media and integrations you must keep. Then use a representative pilot to decide whether Capell improves the workflow enough to justify the move.
Migration planning has five gates: agree the inventory and exclusions, run a representative pilot, verify content and public behaviour, rehearse cutover and rollback, then name the person who accepts each result.
The source guides turn those gates into concrete work. They do not promise an automatic import or treat a successful content export as a finished migration.
Find the hidden requirements
Inventory behaviour as well as records.
Articles and page titles are only part of a working site. Record forms, permissions, redirects, search, feeds, scheduled work and third-party integrations. Assign an owner to decide whether each behaviour moves, is rebuilt or is intentionally retired.
Separate the content mapping from the public presentation. A cleaner page model may be worthwhile, but it should not silently remove information or break a customer journey. Use the family-specific guides below to identify the likely trouble spots.
Make cutover reversible
Agree acceptance and recovery before switching public traffic.
Reconcile source and destination records, inspect media and metadata and let editors repeat their real publishing tasks. Define a go or no-go decision with named owners rather than treating a completed import as approval.
Plan the final export, write freeze, redirects and monitoring window. Keep the old system recoverable until the agreed checks pass, and avoid conflicting edits across both systems. A recovery plan should describe how content and public routing return to a consistent state.
Guides for your current CMS
Pick the platform you are leaving. Each guide identifies source-specific inventory, a difficult pilot, acceptance checks, cutover dependencies, and the person who should sign off each decision.
- From WordPress Inventory WordPress content, plugins, URLs, media, and editor work; prove one difficult pilot before cutover. Review a source-specific risk map
- From headless CMS Inventory content contracts and every API consumer; prove a coupled pilot before retiring headless delivery. Review a source-specific risk map
- From Statamic Map Statamic collections, assets, templates, routes, and Git review; prove the new workflow with one representative pilot. Review a source-specific risk map
- From custom Filament admin Keep effective domain resources; pilot recurring page work after mapping model logic, routes, actions, and editor expectations. Review a source-specific risk map
A representative migration pilot
Inventory URLs, content, media, users, integrations, editorial states, and traffic-critical paths. The owner of each area defines acceptance before implementation begins.
Use the focused guides for WordPress, Statamic, a headless CMS, or a custom Filament admin.