CMS Collection content
Article or blog Collection items with title, slug, rich content, excerpt, publication state, date, and supported custom field matching.
Available migration objects and capabilities depend on the selected source and target systems. Check current integration status before using this planning guide.
What the migration covers
The current Migranetix app supports Webflow as both a source and destination through the Webflow Data API v2. Authors, categories, and article-style CMS content have read/write adapters. Static site pages are available as source content, while creating static pages remains a separate Designer or development task.
Authors and categories
Author and category Collections with names, slugs, descriptions, images, parent relationships, and source identifiers where present.
Media and relationships
Images, attachments, author references, category references, tags, featured assets, and related Collection item mappings.
Static page extraction
Migratable static pages with published paths, readable DOM content, metadata, Open Graph values, hierarchy, locale data, and discovered assets.
What requires separate scope
Webflow styles, classes, components, interactions, animations, forms, scripts, apps, ecommerce behavior, Designer structure, Collection templates, and static-page creation are not assumed to transfer as CMS data. They require destination-native design or development scope.
Current Migranetix app coverage
Migranetix defines the current standard automation path; destination design and project-specific schemas remain separate scope.
Migration direction
Webflow is enabled as both source and target for configured CMS Collections. Static pages are source-only in the current adapter.
Connection requirements
Webflow Data API v2 with a Site ID and API token. cms:read permission for source access and cms:read plus cms:write for destination access.
Configured entities
Authors from a configured CMS Collection, Categories or tags from a configured CMS Collection, Blog posts or articles from a configured CMS Collection, Static site pages as source content.
Mapped CMS content
title and slug, body and excerpt, images and attachments, author and category references, tags and publication status, published date and content type, localized CMS item variants.
Moving content into Webflow
Webflow needs a prepared Collection schema before migration. The app can auto-detect common blog, author, and category Collections or use explicit Collection IDs, but it cannot invent the destination architecture safely.
Prepare Collections first
Define article, author, and category Collections, fields, slugs, references, locale behavior, required values, and publishing workflow.
Match fields to the schema
Map source values to Webflow field slugs and types. Unmatched or incompatible fields become transformations, custom work, or documented exclusions.
Load dependencies in order
Create authors and categories before articles so reference fields can resolve to destination item IDs.
Publish deliberately
Respect draft and archived states, validate staged items, and publish approved item IDs only after relationship and rendering checks.
Moving content out of Webflow
The extraction plan separates CMS Collection records from static pages and template-driven output. Collection template pages do not represent independent source content and are not duplicated as static records.
Discover Collection schemas
Identify the site, Collections, field definitions, blog or article Collection, related author/category Collections, and locale IDs.
Extract CMS records
Read Collection items in paginated batches with field data, publication state, images, references, slugs, and locale context.
Extract eligible static pages
Read normal static pages and page content while excluding utility pages and CMS-bound template pages that carry no independent content.
Normalize destination records
Transform Collection fields and page content into the destination model while preserving source IDs and published paths for reconciliation.
Webflow-specific migration constraints
Webflow combines CMS data, visual design, hosting, localization, and account-plan limits. Each layer affects scope differently and should be reviewed before selecting a package.
CMS and plan limits
Collection count, item capacity, field types, reference behavior, static-page allowance, and account features depend on the active Webflow plan.
Static pages are different
The Data API can expose static page content, but the current Migranetix write path creates CMS items rather than Designer pages.
Localization needs IDs
CMS operations use CMS locale IDs, while page localization uses locale IDs. Primary and secondary locale workflows have different API constraints.
Design is not data
Classes, layouts, components, animations, breakpoints, interactions, and custom code need destination-native implementation even when content transfers.
Webflow URL and SEO migration plan
Published paths, Collection slugs, static pages, locale prefixes, and generated Collection pages all affect URL mapping. Redirects should be based on an inventory, not inferred after launch.
Inventory published URLs
Capture static pages, Collection item paths, locale variants, titles, descriptions, Open Graph data, internal links, and priority URLs.
Approve destination paths
Map every valuable source URL to a destination record or document consolidation, removal, language, and exception decisions.
Implement redirects
Configure and test 301 redirects through Webflow, the destination platform, or the hosting layer when published paths change.
Validate crawl signals
Re-crawl after launch, verify status codes, canonicals, metadata, internal links, sitemap entries, media, and indexing behavior.
What changes Webflow migration scope
The number of CMS items is only one input. Collection architecture, references, localization, static pages, media, and destination implementation determine the real effort.
Collections and fields
Collection count, custom fields, rich text, references, multi-references, required fields, and inconsistent item data affect mapping.
Pages and design
Static-page volume, reusable components, interactions, forms, custom scripts, ecommerce, and redesign expectations create separate workstreams.
Localization and publishing
Locale variants, primary/secondary rules, draft state, archived items, item publishing, and locale-specific URLs add validation paths.
Cutover requirements
Domain changes, redirects, content freeze or delta needs, launch ownership, rollback conditions, and support affect timing and package fit.
How the workflow works
- 1. Discover: Confirm the Webflow site, API scopes, Collections, schemas, pages, locales, volume, published URLs, and destination readiness.
- 2. Map: Approve entity types, fields, references, locale behavior, assets, URL rules, design boundaries, custom work, and exclusions.
- 3. Dry run: Transfer representative CMS items and eligible source pages into staging or a prepared destination model.
- 4. Validate: Reconcile counts and inspect field values, references, images, paths, metadata, locales, publishing state, rendering, and exceptions.
- 5. Cut over: Run the approved production or delta plan, publish selected items, implement redirects, and monitor launch signals.
Technical references
Scope is reviewed against the source and destination documentation available for the project.