On this page
Many Craft CMS sites use flexible block fields, often called Matrix fields, to let editors build pages from a menu of block types: text, image, quote, gallery, call to action and so on. When moving to a modern front end, these blocks are a gift, because they already describe a component library. The work is to formalise it.
Inventory every block type
List each Matrix field and its block types. For each block type, record its fields and their types, how many entries use it and on which sections. Usage counts reveal which blocks are essential and which were created for a single page and never used again.
Look at real usage, not just definitions
Definitions show what is possible; usage shows what matters. Pull a sample of entries and note how editors combine blocks. You may find unofficial patterns, such as a heading block always followed by an image block, that would be better expressed as a single component.
Design the component contract
For each component you plan to build, define:
- Its name and purpose.
- Its fields, with types and validation.
- Variants it supports, such as image left or image right.
- How it behaves on small screens.
- Accessibility requirements, such as alternative text and heading level.
Keep the contract close to the original block's fields where possible, which makes content mapping straightforward.
Consolidate and simplify
Migration is the right time to merge near-duplicate blocks. Three slightly different call-to-action blocks might become one component with a variant option. Retire blocks with very low usage after moving their content into a supported component.
Nested blocks and relations
Some Craft setups nest blocks or relate blocks to other entries. Decide whether to preserve nesting or flatten it. Relations, such as a featured entries block, should become references in the new data model so listings stay accurate when related content changes.
Rich text inside blocks
Rich text fields may contain links to other entries using Craft's reference tags, custom classes and embedded media. Plan a transformation that converts internal references into the new URL structure and strips styles the new design system replaces.
Preview matters to editors
Editors working with flexible blocks rely on preview to see how a page will look. Whether Craft remains the CMS in a headless setup or another CMS replaces it, make sure editors can preview drafts in the real front end before publishing.
Migrate in passes
A practical approach is to migrate content in passes: first the structure and simple fields, then rich text transformations, then assets and relations. Compare a set of representative pages after each pass. Automated checks for missing fields and broken references help find problems quickly.
The benefit
Converting Matrix blocks into a defined component library preserves what editors liked about Craft, the ability to compose pages, while giving designers and developers a consistent system to maintain. It also documents the site's design language in a way that makes future pages faster to build. Keep the component contracts alongside the codebase and update them whenever a component changes, so editors and developers continue to share the same reference.
Turn this topic into a project plan
Use these supporting guides to prepare the details for your craft cms discussion.
Put this into practice
Planning a move like this?
See how a scoped craft cms migration project handles content, URLs, integrations and launch.
