Headless CMS architect
1Content modeling, target CMS choice (Strapi, headless Drupal, Directus, WP+WPGraphQL), API design, design system
Loading...
Loading...
Migration from a traditional CMS (WordPress, Drupal, Joomla) to a headless architecture: a content API back-end (Strapi, headless Drupal, Directus) paired with a SPA front-end (Next.js, Astro), SEO and performance preserved.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Complete inventory of source URLs, content, and third-party integrations (CRM, ESP, payment). Multi-language hreflang map. Core Web Vitals baseline audit. Priority scope and target CMS choice (Strapi, headless Drupal, Directus, WP+WPGraphQL). Source/target 301 redirect table validated by SEO.
Content modeling workshop: separation between business entities (Article, Author, Category) and presentation components (Hero, CTA Block), normalized relations. Capture existing editorial workflows, identify WordPress plugins / Drupal modules to replace or integrate.
Optimized content API design: one page = one call, not cascade. Front-end design system (components, design tokens). Performance budget set (LCP < 2.5 s, CLS < 0.1, INP < 200 ms). Non-regression test suite preparation on critical workflows.
Build SPA front (Next.js or Astro), configure target headless CMS, migrate content from monolith, integrate CRM/ESP/payment, activate live previews, visual parity tests on representative page sets.
Production cutover with 301 table active on .htaccess or middleware. Editor training over 2 sessions (before + 2 weeks after). Daily Search Console monitoring for 90 days, alert on impression or position drop. Publishing time measurement post-cutover (target: ≤ baseline).
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
News media and editorial portals whose front-end debt slows down publishing cycles. Multi-site, multi-market brands that stack WordPress or Drupal instances to manage several countries. Public-sector and institutional players who maintain complex bilingual sites (French/Arabic, French/English) where performance and accessibility are audited. In every case, tight front/back coupling becomes a brake: every presentation change forces a full CMS release cycle, and the legacy stack blocks any modernization of mobile or app fronts.
Three forces are pushing the move: (1) Core Web Vitals pressure since 2021 — a monolithic site struggles to pass the LCP < 2.5 s threshold without a deep rendering rewrite; (2) multi-channel — website, mobile app, in-store screens, voice all share the same content, which a monolithic CMS cannot expose cleanly; (3) end-of-life of critical plugins (notably on WordPress) forcing a decision: WordPress rebuild or headless cutover. Headless decouples the fast front-end cadence (design system) from the slow back-end cadence (content governance, security).
For a simple brochure site with no multi-channel needs and no dedicated technical team, an optimized WordPress remains more economical. For an editorial team without dev support, headless reduces autonomy (no native WYSIWYG on the front-end). For an e-commerce site with heavy merchandising workflows, some monolithic platforms (Shopify, Magento) keep the edge. Headless is not a universal answer: it makes sense when multi-channel, performance, or front-end freedom justify the investment.
The access-international.dev site moved from WordPress to a headless architecture (Next.js 16 + static export) on April 23, 2026. Factual markers: 135 bilingual pages (66 FR + 66 EN + utility pages), a 124-URL sitemap with complete FR/EN hreflang, 51 WordPress → Next.js 301 redirects baked into the Plesk `.htaccess` to preserve every legacy path. Post-migration SEO audit 91/100, security 92/100 (HSTS preload, hardened headers). 31 OG images generated through Playwright from a parameterized HTML template. AI crawlers (GPTBot, ClaudeBot, PerplexityBot) are explicitly allowed in `robots.txt`. This migration is our own proof point: we apply on our site the ATLAS methodology we sell to clients. No theoretical claim — the result is measurable and open to audit.
Headless CMS + SPA front (Next.js, Astro)
When the team has a JavaScript culture and wants a lightweight, extensible CMS back-end deployable on Cloudflare, Vercel, or AWS. No PHP dependency.
When the team capitalizes on existing Drupal expertise (modules, permissions, editorial workflows) and wants to keep the back-end while modernizing the front.
When content is structured like a real database and the team wants an automatically generated REST/GraphQL API without a heavy CMS abstraction.
When WordPress is already in place and a smooth transition is preferred — keep the WP back-end, switch the front to Next.js or Astro, add a GraphQL layer.
8 to 16 weeks depending on content volume to migrate (from 100 to 5,000 pages), number of third-party integrations (CRM, ESP, payment), and design system maturity. Typical team: 1 project manager, 2 front-end developers (Next.js or Astro), 1 API/CMS developer, 1 SEO lead during the migration phase.
SEO preservation poorly framed — the migration changes URL structure, breaks redirects, or subtly alters server-side rendering. Common pattern in the literature: 20% to 40% ranking losses in the six months following cutover, sometimes never recovered.
Complete URL mapping, source and target, before any development, exhaustive 301 redirect table baked into .htaccess or middleware, comparative Core Web Vitals audit before/after, daily Search Console monitoring for 90 days post-cutover. On the Access International project, 51 WordPress→Next redirects were preserved with no position loss.
Content model copy-pasted from the monolith — teams replicate WordPress content types into Strapi without rethinking the API. Result: rigid API, duplicated data, the front-end has to make 5 calls to render a homepage.
Upstream content modeling workshop, clear separation between business entities (Article, Author, Category) and presentation components (Hero, CTA Block), normalized relationships. The API must deliver a full page in a single optimized call, not in cascade.
Editorial workflow broken without preparation — editors lose their familiar WYSIWYG, no longer see visual rendering while writing, must understand the notion of "draft API" versus published. Strong resistance, delayed content publishing.
Implement live previews on the front-end (Next.js draft mode, Astro view transitions), hands-on training of editors over 2 short sessions, visual documentation of the new flows. Success is measured by article publishing time: it must remain less than or equal to the previous baseline.
Front-end performance poorly measured — the team assumes "headless = automatically fast" and neglects front-end optimizations. Result: LCP degraded by unoptimized images, CLS broken by custom fonts, bloated JavaScript bundle.
Performance budget set at scoping (LCP < 2.5 s, CLS < 0.1, INP < 200 ms), continuous CrUX field data measurement, systematic optimization: WebP/AVIF responsive images, subset fonts with font-display swap, aggressive code splitting, ISR or SSG by default. Headless guarantees performance only if performance is explicitly governed.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Content modeling, target CMS choice (Strapi, headless Drupal, Directus, WP+WPGraphQL), API design, design system
Next.js or Astro, SSG/ISR, Core Web Vitals optimization, responsive WebP/AVIF images, code splitting, draft mode for previews
Headless CMS configuration, REST/GraphQL API, entity modeling, editorial workflows, permissions
Source/target URL mapping, exhaustive 301 table, hreflang, robots/sitemaps, GSC monitoring 90 days post-cutover
Live preview design, hands-on editor training (2 sessions), visual documentation, publishing time measurement
Scoping → cutover leadership, business / IT / SEO team coordination, user acceptance
Access has hands-on experience on monolithic CMS back-ends, delivered for clients: Drupal powering the bilingual (Arabic + English) Ministry of Culture KSA platform for Vision 2030 heritage valorization; WordPress powering the Azur City portals (3 shopping malls) and Gnet News (news portal). This back-end expertise transfers directly to a headless transition (headless Drupal via JSON:API, headless WordPress via WPGraphQL).
On modern static front-ends: the access-international.dev site itself runs Next.js 16 + static export on Plesk hosting, with 135 bilingual pages, SEO baseline 91/100, complete hreflang, and 51 preserved legacy redirects. The vivantro.org site runs on Astro with Cloudflare Pages. The terrageo.pages.dev site combines Vite + React + PWA. SPA front-end capability is operational and can be paired with any headless CMS back-end.
Cost depends on content volume, number of integrations, and design system maturity. As a benchmark: an editorial site of 500 pages with 3 third-party integrations (CRM, ESP, payment) lands between 40,000 and 80,000 EUR in a fixed-price nearshore Tunisia engagement. A multi-site portal with 5,000 pages and complex editorial workflows can exceed 150,000 EUR. The Intake scoping phase locks an explicit range. See the delivery models.
Three safeguards: (1) complete URL mapping before any development, exhaustive 301 redirect table validated by the SEO lead; (2) comparative Core Web Vitals audit before/after to ensure the headless move improves performance and introduces no CLS or LCP regressions; (3) daily Search Console monitoring for 90 days post-cutover, automatic alert on any drop in impressions or positions. On our own site we preserved 51 WordPress redirects with no ranking loss.
8 to 16 weeks depending on volume. For a brochure site of 100 pages without complex integrations, 8 weeks are enough (scoping 2, dev 4, UAT + cutover 2). For a multi-site portal of 5,000 pages with CRM, ESP, payment, and multilingual content, plan 14 to 16 weeks. A pilot on a sub-perimeter (one section, one language) in 4 weeks validates the mechanics before committing to the rest.
The main risk of a headless migration is editorial resistance: loss of the familiar WYSIWYG, new workflows, draft API. Our approach: live previews on the front-end from day one (Next.js draft mode or Astro view transitions), 2 hands-on training sessions with editors (before cutover and 2 weeks after), visual workflow documentation. Success is measured by article publishing time: it must remain less than or equal to the previous baseline within 30 days of cutover.
Three concrete ways to start — from an SEO diagnostic to a full program. Our approach is demonstrated on access-international.dev itself (51 redirects preserved, SEO score 91/100).