Mapping your current CMS
How the features of WordPress, Drupal, Contentful, Strapi or a custom CMS translate to Atlas, and what has no equivalent.
Most customization in a traditional CMS falls into a handful of patterns. This table shows where each one goes in Atlas.
| In your current CMS | In Atlas | Notes |
|---|---|---|
| Page builder (blocks, rows, widgets) | Page made of sections; each section is one of your components | Editors pick from the sections your page type allows |
| Custom post types (products, news, team) | Collections with entries | Filter, sort and paginate them with the Delivery API |
| Custom fields (ACF, Drupal fields, Contentful fields) | Typed fields in the site contract | Text, rich text, number, date, link, asset, reference, list, group, table and more |
| Relationships between items | Reference fields | |
| Menus, header, footer, site settings | Globals such as site-header and site-footer |
Your code still renders them |
| Theme and design settings | Design tokens in the contract: colours, type styles, spacing | Atlas never applies its own styles to your site |
| Media library | Media, with renditions per media profile, focal points and alt text | |
| Multilingual plugin (WPML, Polylang) | Translations of pages, entries and globals, with fallback | Arabic and other right-to-left languages included |
| SEO plugin (Yoast, Rank Math) | SEO fields per page, redirects, route list for your sitemap | Your code outputs the tags and the sitemap |
| Redirect manager | Redirects, read by your site | |
| Contact forms (Contact Form 7, Gravity Forms) | Forms with Turnstile spam protection and lead emails | Development and live website (status) |
| Roles and editorial workflow | Roles, drafts, preview, publish, Production release approval | |
| Scheduled posts | Scheduled publishing for editorial collections | |
| Webhooks and “on publish” automations | Signed webhooks |
What has no equivalent, on purpose
Section titled “What has no equivalent, on purpose”| In your current CMS | Why Atlas does not do it | What to do instead |
|---|---|---|
| Plugins that run code on your site | Content must never be able to run code on your website | Build the feature in your website’s code and give it a component with settings |
| Shortcodes, raw HTML blocks, “custom code” widgets | Same reason. It is also a common way CMS-driven sites get compromised | A component per embed type (video, map, booking widget) with a URL or ID field |
| Tracking scripts added by editors | Scripts are a developer decision, reviewed in code | Add them in your code or tag manager, under your Content-Security-Policy |
| The CMS rendering and hosting the site (themes) | Atlas is headless; your website stays yours | Keep your hosting |
| Server logic in the CMS (checkout, member areas, custom APIs) | Out of scope | Keep it in your application or existing services |
| Site search | Not provided | Keep your search, or index entries from the Delivery API |
A worked example
Section titled “A worked example”A corporate WordPress site has a page builder, a “Projects” post type with ACF fields, Yoast, WPML (English and Arabic), Contact Form 7 and a [map] shortcode.
- Each page-builder block becomes a component in the contract, rendered by an existing React component.
- “Projects” becomes a collection with the same fields. The projects page reads
/entries?collection=projects. - Yoast titles and descriptions move into each page’s SEO fields. Old URLs go into redirects.
- English and Arabic become locales. The site requests
&locale=arand setsdir="rtl". - The contact form becomes an Atlas form. It reaches the live site with the next release; leads arrive in Forms & leads.
- The
[map]shortcode becomes a Map component with an address field. The map script lives in the website’s code.