A serious CMS migration should model the workflow behind each page before it models the page itself. In complex content ecosystems, many URLs look like ordinary pages during the audit while carrying operational rules behind the visible layout. Recipes, giveaways, events, lead magnets, quizzes, store locator pages, product microsites, and gated resources each behave differently once you look past the page shell. The useful architecture work comes from classifying those workflows, deciding which system owns each part, and turning repeatable patterns into structured CMS collections, templates, references, and approval states. This article explains workflow-first content modeling using a composite migration scenario rather than a single client case.
I'm Matija Žiberna, founder of BuildWithMatija. I work on CMS architecture, Payload implementation, content modeling, and migration planning for companies with complex content ecosystems. This article draws on recurring migration patterns and uses a composite scenario because the most useful lessons usually come from workflow structure rather than one named project.
A representative migration context
Consider a product-heavy company moving from a legacy CMS to a more structured content platform.
One site may be consumer-facing, another may serve professional or practitioner audiences, and another may sit closer to ecommerce while checkout, inventory, order, and fulfillment logic stay in operational systems.
The audit may cover product pages, blogs, recipes, events, giveaways, landing pages, lead magnets, quizzes, product microsites, educational primers, store locator pages, gated resources, downloadable PDFs, community links, practitioner resources, ecommerce-adjacent pages, and redirect candidates.
The URL inventory gives the project its visible scope. The workflow review gives the project its architecture.
What a URL inventory doesn't tell you
A URL audit can tell you that a site has recipes, events, giveaways, resource pages, product pages, microsites, and lead forms.
That inventory helps with migration planning, redirects, SEO preservation, and prioritization, without explaining how the company actually works to produce each page.
A recipe URL can contain product relationships, dietary filters, creator information, downloadable content, CRM capture, and approval needs.
A giveaway URL can contain campaign timing, prize fields, eligibility rules, legal review, social promotion, form routing, and archive behavior.
An event URL can promote an event while registration, participation, livestream, replay, and community activity happen in another platform.
A store locator URL can show page content while retailer data, inventory visibility, preferred retailer logic, and channel ownership live elsewhere.
The Payload model needs to follow those operational differences. Treating each of those areas as a generic page would remove the structure that the business needs most.
Recipes became a structured content type
Recipe content is often one of the clearest candidates for structured modeling.
This content often already uses meaningful categories such as lifestyle, health goals, dietary preferences, diet, and ingredients or produce. That structure should not be flattened into generic rich text during migration.
The Payload recipe model should preserve and strengthen those relationships.
A recipe record can include title, slug, locale, hero image, ingredients, steps, prep time, cook time, servings, dietary preferences, health goals, related products, creator, lead magnet connection, SEO fields, status, review owner, and publish date.
This gives editors a predictable way to create recipes. It gives the frontend a consistent template. It gives product and marketing teams a way to connect recipes to products without copying product truth into the article body.
The migration value comes from turning old recipe pages into a structured collection that can later support filtering, related products, health-goal browsing, creator pages, and traceability.
Giveaways became campaign records
A giveaway area can look simple on the website while hiding a more specific workflow underneath.
A recurring giveaway pattern usually needs structured fields for the campaign title, product or prize, start date, end date, rules, eligibility, form destination, winner announcement, related products, social promotion, tracking, status, and archive behavior.
That should become a giveaway or campaign collection, rather than a manually updated page.
The structured model prevents the same information from being entered in multiple places. It also gives the team a clean way to archive old campaigns, schedule active ones, and review legal or contest-rule content before publishing.
A giveaway page is a campaign workflow with a public page attached to it.
Events needed a boundary between promotion and participation
Event content usually needs a clean split.
The public website can own the promotional layer: event title, date, location, host, description, agenda, CTA, related products, related resources, SEO fields, and post-event replay content.
The actual registration, community activity, livestream, reminders, attendance tracking, or replay hosting may remain in external systems.
Payload should model the event content and the external registration boundary, without absorbing the full event platform unless that becomes a separate scoped decision.
This creates a practical event collection with fields for external registration URL, platform type, event status, start and end date, event owner, related content, and post-event state.
The frontend gets richer event pages. The business keeps existing event systems where they already work.
Lead magnets needed CRM boundaries
Lead magnets often appear across multiple content areas: recipes, educational primers, product education pages, campaign pages, and downloadable resources.
The architecture decision is usually clear.
Payload should own the page, content, downloadable asset reference, CTA, SEO metadata, thank-you state, tracking fields, and campaign context.
The CRM should own the form submission, customer profile, segmentation, email automation, and downstream marketing flow.
This model gives marketers control over lead magnet pages without turning Payload into a CRM.
A useful Payload lead magnet model can include headline, intro copy, downloadable asset, CRM form destination, form embed or API configuration, thank-you content, related products, related articles, campaign tags, tracking fields, status, locale, and approval state.
The page stays editable. The lead data stays in the right system.
Store locator content needed separation from locator data
Store locator content usually carries two different responsibilities.
The first responsibility was website content: page copy, banners, online retailer links, logos, promotional CTAs, explanatory text, and channel-specific updates.
The second responsibility was locator data: retailer records, addresses, product availability, preferred retailer logic, online retailer data, and possible inventory visibility.
Payload is a good place for the surrounding page content and controlled channel-specific updates.
The locator data source should stay external unless the business separately decides to rebuild that system.
That split allows the responsible team to update messaging, banners, and retailer copy without asking developers for every small change. It also keeps retailer and inventory data in a system designed for that responsibility.
Quizzes needed a decision framework
Many audits uncover quiz-like experiences embedded or connected through the existing CMS ecosystem.
A quiz can be a simple interactive content block. It can also become a segmentation engine, product recommendation flow, CRM capture mechanism, lead magnet, or campaign experience.
That difference determines the right implementation.
Approach
When it fits
The blueprint should keep quiz implementation open until the business confirms frequency, logic variance, response destination, CRM value, and product recommendation needs.
Microsites needed treatment decisions
Large ecosystems often include product microsites, educational primers, campaign properties, subdomains, and older standalone experiences.
Those pages could not all receive the same migration treatment.
A future Payload setup can support microsite records with fields for brand, domain or subdomain, campaign context, microsite navigation, allowed blocks, related products, lead forms, assets, SEO fields, status, and launch or retirement date.
This keeps microsites planned without forcing every old property into the initial launch scope.
The workflow map
The main project table should become a workflow map.
This table helped move the project away from page-by-page thinking.
Each row connects a visible website area to the workflow that needs to be modeled.
Workflow-first modeling changes the Payload schema
A workflow-first migration creates more useful collections and relationships than a page-first migration that simply creates a pages collection, imports content, recreates layouts, and adds redirects.
In projects like this, the CMS model needs collections and globals such as pages, brands or sites, blogs, recipes, events, giveaways or campaigns, landing pages, lead magnets, microsites, product references, resource records, media references, navigation, redirects, taxonomy, SEO fields, approval states, and workflow metadata.
The content model also needs relationships between products, ingredients, health goals, topics, creators, authors, assets, downloads, forms, campaigns, recipes, blog posts, events, and landing pages.
Those relationships create long-term value.
They allow editors to find every place a product is referenced. They allow related content to be selected consistently. They support filtering and recommendations. They make migration QA more structured. They give compliance and product teams a better way to review affected content.
Workflow ownership affects permissions
Workflow-first modeling also changes permissions.
A blog editor, recipe editor, giveaway owner, channel owner, legal reviewer, product reviewer, asset approver, and publisher should not have identical access.
The CMS should support access by role, brand, content type, workflow state, and reviewer assignment.
For example, a giveaway might require marketing edit rights and legal approval. A recipe might require editorial rights and product review when a product is referenced. A store locator page might require content ownership for page copy while locator data remains external. A lead magnet might require marketing control over page content while CRM configuration remains restricted.
These permission rules belong in the architecture before implementation starts.
Workflow status belongs inside the CMS
The current operating pattern relied heavily on external coordination.
A page update could involve project management tasks, Slack or email messages, developer handoff, asset requests, review comments, and publishing coordination.
Payload should absorb the workflow states that directly affect publishing.
Useful states include draft, needs assets, needs product review, needs legal review, ready for approval, approved, scheduled, published, needs update, and archived.
The exact states can vary by content type.
Giveaways, recipes, product education pages, lead magnets, and store locator updates carry different review needs. The CMS should reflect those differences instead of treating all content as a generic draft.
Workflow-first migration reduces hidden scope
Many migration surprises come from treating workflows as page content.
A lead magnet gets imported as a page, then the team later realizes the CRM integration, thank-you state, downloadable asset, and tracking setup were part of the actual work.
A giveaway gets rebuilt as a page, then the team later realizes start dates, end dates, rules, legal review, archive behavior, and winner content need structure.
A store locator page gets redesigned, then the team later realizes retailer data and inventory visibility depend on another source.
A microsite gets migrated, then the team later realizes it needs domain handling, custom navigation, lead forms, product references, and campaign ownership.
Workflow-first modeling surfaces those dependencies early.
It gives the team a clearer implementation roadmap and a cleaner scope boundary.
Practical workflow-first CMS checklist
Use this checklist before modeling a migration around pages:
List every major URL type in the ecosystem.
Identify the business workflow behind each URL type.
Separate visible page content from system-owned data.
FAQ
Why is page-first modeling risky?
Page-first modeling can hide workflow requirements inside generic content fields. The team may miss CRM routing, product references, asset approval, legal review, external registration, locator data, archive logic, and migration treatment rules.
Which content types usually need workflow-first modeling?
Recipes, giveaways, events, lead magnets, quizzes, product education pages, microsites, gated resources, store locator pages, and product-related blog posts often need workflow-first modeling because they connect content to business processes.
Should every workflow live inside Payload?
Payload should manage workflows that affect website content, review, approval, publishing, references, and page configuration. External systems should keep responsibility for CRM records, ecommerce orders, inventory, community participation, account portals, and source-of-truth product data.
When should a page become a collection?
A page should become a collection when it repeats, has structured fields, needs filtering, has relationships, requires approval, connects to external systems, or needs consistent migration rules.
How should quizzes be handled?
Quizzes should be rebuilt in Payload only when they are frequent, share repeatable logic, need internal editorial control, or create useful product recommendation or segmentation data. Rare or highly variable quizzes usually fit better as embedded or external tools.
Conclusion
This migration's architecture came from the workflows behind each URL rather than the URL list itself. Recipes, giveaways, events, lead magnets, quizzes, store locator pages, microsites, blogs, resources, and product pages each needed different treatment because each carried a different workflow behind the visible page.
Payload should model those workflows through collections, templates, relationships, references, approval states, and external system boundaries.
Start by asking what work the page represents. Then model that work in the CMS.
Thanks,
Matija
Payload quiz builder
Quizzes are frequent, share similar logic, need internal control, connect to product recommendations, or create valuable segmentation data
External quiz tool
Quizzes are rare, logic varies heavily, reporting belongs elsewhere, or the business already relies on a specialist tool
Hybrid model
Payload owns the quiz landing page, educational content, SEO, related products, and campaign context, while quiz logic remains embedded from another system
Microsite treatment
When it fits
Remain a distinct experience
Business wants it to feel separate from the main brand site
Payload-managed microsite template
Content follows a repeatable pattern that fits a structured template
Bespoke rebuild
Supports important product education or campaign value
Consolidate into main site
Content overlaps with the main brand experience
Redirect or retire
Format is outdated
Website area
Visible artifact
Operational workflow
Payload treatment
Recipe page
Recipe article
Structured ingredients, dietary tags, health goals, product references, creator, lead magnet, SEO, review
Recipe collection with product references and controlled fields
