Migration checklist
Work through these questions with your developers before you move a website with its own CMS to Atlas.
Use this list in a planning session with whoever built your current website. A “no” is not a blocker by itself. It shows you where the work is.
1. Technology
Section titled “1. Technology”- The site is Next.js App Router, or the team accepts extra effort for another server framework. (Why)
- Content can be fetched in server code, and the delivery token can live in a server environment variable.
- The site can keep a built-in fallback for every page it moves, so it still works if Atlas is unreachable.
- The team can add one route for preview, one for webhooks, and a build report at start-up.
2. Design and components
Section titled “2. Design and components”- Pages are made of reusable sections (hero, cards, FAQ, call to action). One-off pages can still be one component with fields.
- You have listed every page type: home, product, article, landing page, legal and so on.
- For each section you know which parts editors change (text, images, links, lists) and which stay fixed in code.
- Interactive parts (calculators, configurators, maps, animations) stay in your code. Editors only fill their text and settings.
3. Content in your current CMS
Section titled “3. Content in your current CMS”- You can export pages, entries and images: a database dump, an API, CSV, or an AI agent reading the old site.
- Repeating content (products, news, team, locations) maps to collections.
- You have listed custom fields and know their types: text, rich text, number, date, link, image, reference, list.
- You know where the current CMS runs code inside content: shortcodes, embeds, HTML blocks, scripts. Each one needs a replacement component. See Mapping your current CMS.
- You have a list of URLs and redirects to keep, so search rankings are not lost.
- Languages and their fallback rules are clear. Right-to-left languages need
dir="rtl"support in your components.
4. Features your site depends on
Section titled “4. Features your site depends on”Check each one against capability status before you commit:
- Forms and lead emails: Development and the live website (in final review before release).
- Chatbot: Development and the live website (in final review before release).
- Sending leads to a CRM or another system: CRM push and the Leads API cover Development leads only today; live-website leads reach you through webhooks.
- Analytics: Atlas counts page views per route, without cookies, on Development and the live website. Keep your existing analytics.
- Search on your site: Atlas does not provide site search. Keep your own, or build it from the entries API.
- E-commerce, checkout, member logins: not part of Atlas. These stay in your code or your existing services.
- Scheduled publishing, translations, redirects, SEO fields: supported.
5. People and approvals
Section titled “5. People and approvals”- You know who edits, who reviews and who approves Production releases.
- Everyone who signs in can use the Atlas sign-in. Single sign-on with your own identity provider is not available.
- Legal and security reviewers have read Security and the open items in the FAQ.
Result
Section titled “Result”- Mostly yes: follow the step-by-step migration.
- Several no’s in sections 1 to 3: start with a pilot on one page type.
- Your site depends on items in section 4 that are not available: wait, or keep those parts outside Atlas for now.