From legacy CMS to a modern content platform: migrating from CamaleonCMS to Contentful

Legacy CMSes can slow teams down with brittle plugins, coupled rendering, and custom solutions that don’t scale. This post shares how we moved a travel media company from CamaleonCMS (with some custom plugins) to Contentful CMS in order to improve editorial speed and reliability while reducing maintenance risk.

TLDR

• Modernized platform: We migrated a travel media company from a legacy CamaleonCMS (Rails-based) setup to Contentful, a headless, API-first CMS.‍
• Operational gains: Editorial workflows improved, faster releases from engineering, and content governance became enforceable at the model level.
• Risk-managed launch: Analytics, URLs and redirects were preserved; assets and content migration.
• Foundation for growth: A flexible content model, cleaner taxonomy, richer website architecture design cut future maintenance cost and support faster iteration.

Background and goals

The company’s content estate — thousands of evergreen and time-sensitive travel articles, deal posts, and destination pages, managed in CamaleonCMS. Over time, the monolithic setup created pain points: coupling between content and rendering, brittle plugins, inconsistent taxonomies, and feature releases gated by engineering deploys.

The goals for this migration were clear:

• Increase editorial velocity and autonomy.
• Establish a robust, flexible content model that supports new formats without migrations.
• Improve reliability and observability of content delivery through APIs.
• Reduce maintenance overhead and plugin risk, while sustaining SEO performance.
• Improve development velocity for new features and improvements.

Why Contentful

We selected Contentful for four reasons:

• API-first and ecosystem: Mature GraphQL/REST APIs, webhooks, and a strong ecosystem for integrations (search, analytics, content modeling, assets management).
• Modeling and governance: First-class content modeling, validations, references, environments, and roles/permissions to enforce standards.
• Editorial UX: Familiar, performant editor with extensibility (apps, field extensions) to handle rich content, assets, and structured blocks.
• Operational posture: Reliability SLAs, environments for preview/sandboxing, and rate-limit transparency suited our CI/CD and staged rollout needs.

Migration approach

We ran the migration as an iterative process with parallel content and platform tracks, between the old website and the new one.

1. Content model redesign and mapping

• Inventoried CamaleonCMS post types, custom fields, and widgets; grouped them into a smaller set of composable Contentful content types (Article, Deal, Destination, Slideshows, Author, Assets).
• Defined field-level mappings and transformations (e.g., Markdown/HTML to Rich Text with embedded entries, slug normalization, date handling, and enum consolidation, etc.).
• Introduced reusable blocks (callouts, content sections, shared heros and layouts) to reduce bespoke fields and improve consistency.

2. Content migration and automation

• Built idempotent migration scripts to extract, transform, and load content via Contentful Management API with backoff and checkpointing.
• Added pre-flight validators (schema, required fields, reference existence) and post-load audits (sampled renders, broken link checks, image dimension/format checks).
• Used environment branching in Contentful to test and iterate the model without blocking editorial work.

3. Taxonomy cleanup

• Consolidated overlapping tags and categories; introduced a canonical taxonomy for destinations, themes, and content formats.
• Removed unused or legacy fields; normalized tag casing and synonyms; merged duplicates.
• Defined governance: who can create terms, how they’re reviewed, and how they map to faceted navigation and on-site modules.

4. SEO and URLs

• Preserved legacy slugs wherever possible; generated deterministic slugs for new content.
• Ensured structured data parity (Article, Slideshows, Gallery, Hotels and Cruise Lines) and migrated meta fields to Contentful.

5. Media assets

• Reprocessed images to modern formats and sizes; captured alt text as a first-class field.
• Standardized aspect ratios and introduced asset variants per template need; mapped to CDN delivery with caching headers.

6. Editorial workflow and permissions

• Implemented roles (Author, Editor, Admin) with environment-based gating; added preview and scheduled publishing.
• Introduced checklists and content guidelines encoded as field validations and app extensions.

7. Performance and delivery

• Decoupled rendering from content; leveraged Contentful Delivery/Preview APIs with caching and incremental revalidation at the edge.
• Added observability around fetch errors, rate limits, and stale content windows.

Challenges we faced

• Schema mismatches: Legacy freeform fields needed normalization to structured fields; we built targeted transformers and flagged ambiguous cases for manual review.
• Rich text fidelity: Converting HTML widgets and inline embeds into Contentful Rich Text with references required custom parsing and resolvers.
• Rate limits and throughput: We batched requests, implemented exponential backoff, and parallelized within safe concurrency to meet timelines without throttling.
• Slug history: Content with multiple historical URLs required a merge strategy and layered redirect rules to avoid chains and loops.
• Asset variants: Inconsistent original dimensions/aspects forced a re-baseline and automated cropping/letterboxing rules to meet template needs.
• Permissions and training: New roles and workflows introduced change management; we ran enablement sessions and created in-editor guidance.

Benefits achieved

• Editorial speed and autonomy: Authors can create, preview, and schedule content without waiting on deploys; reusable blocks reduce rework.
• Reliability and quality: Validations at write-time, plus CI-driven link and asset checks, lowered the chance of broken pages and regressions.
• Flexibility: New content formats can be added by composing blocks and content types rather than custom plugins.
• SEO stability: Redirect coverage and structured data parity protected organic traffic during and after cutover.
• Delivery performance: API-driven delivery with caching and incremental revalidation improved consistency and reduced origin load.‍
• Lower maintenance risk: Moving off custom plugins and monolithic coupling decreased the upgrade burden and bus-factor risk.

Risks and trade-offs

• Vendor lock-in: Headless CMS flexibility comes with reliance on APIs and pricing; we mitigated with clean domain models and export tooling.
• Cost model: Seats, environments, and API usage require governance; we set quotas and lifecycle policies for entries and assets.
• New workflows: Training and role design are non-trivial; we invested in enablement and embedded guidance to smooth adoption.‍
• Operational complexity: Distributed systems (CMS + CDN + renderers) add moving parts; observability and runbooks are essential.

Results and lessons learned

Post-cutover, the organization saw measurable improvements in editorial throughput and a reduction in content-related incidents. While we avoided publishing exact figures, internal dashboards indicated low double-digit gains in time-to-publish and fewer emergency hotfixes. The taxonomy cleanup unlocked simpler navigation logic and better on-site discovery modules. Most importantly, content and presentation are now cleanly separated, enabling experimentation without heavy refactors.

Key lessons

• Invest early in the content model and block library — every later step benefits.
• Make validations your ally: enforce quality at authoring time, not in production.
• Treat SEO as a first-class track with its own acceptance criteria and testing.
• Maintain idempotent, audited migration scripts — you may need to re-run subsets.