When to choose WordPress or Payload for a headless front end
Choose between these two platforms when your WordPress site already feeds a JavaScript front end through the REST API, with custom fields plugins and a team of editors in place. WordPress fits when the editorial workflow, the plugin dependencies and the PHP hosting stack are working and the main goal is to keep them. WordPress is released under the GPLv2 or later from the Free Software Foundation, and its plugin ecosystem is the reason most teams stay. Payload fits when the team is TypeScript-first, wants the content schema in code and already builds or plans a Next.js app. Payload is *MIT licensed* and installs directly into an existing Next.js /app folder, so the schema, access rules and front end live in one repository and one review process.
Before you commit, inventory what has to move. Count the custom post types, field groups from plugins such as Advanced Custom Fields, role-based permissions, multilingual setups and any logic that lives in plugins rather than in the theme or front end. Payload's own comparison page contains no guidance on migrating content, themes or plugins from WordPress, so the rebuild of models, access rules and editor views is work your team must scope itself. Ask your implementation partner for a written list of every content type and integration that will be rebuilt, and confirm which items can be migrated by script and which must be rewritten by hand.
The decision turns on two questions. First, how much existing content and plugin logic must move, which sets the rebuild effort and the period in which both systems run in parallel. Second, who will maintain the schema after launch. If developers own it and editors only use it, a code-defined schema in Payload is a strong fit. If editors and a small web team change fields and workflows often and rely on plugin-based tooling, staying on WordPress with a headless API layer may cost less to operate. Name an owner for the schema before the decision, because that owner will carry the long-term cost of either choice.
Which platform fits which team scenario
This table maps common team situations to the platform that usually fits better, and names the condition that drives each choice. Read each row against your own editors, engineers and hosting. Payload's localization and access control points are the vendor's own claims, so verify them in a proof of concept before relying on them.
| Team scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Editors rely on the WordPress admin and a plugin library | WordPress | Editors who need familiar screens, media handling and a wide choice of plugins gain more from staying in WordPress than from a rebuilt admin. |
| Team is mostly TypeScript engineers | Payload | Schemas written as TypeScript config, generated types and code review of content models suit engineers who want the CMS in the same repo as the app. |
| Site needs field-level localization | Payload (vendor claim), verify first | Payload's comparison page says localization is built in at field level. WordPress usually relies on multiple plugins, so confirm your locale workflow against both. |
| Access rules must differ by document or field | Payload (vendor claim), verify first | Payload describes access rules as functions at document or field level. In WordPress this is typically handled through roles and extra plugins, so map your rules before choosing. |
| Team already runs PHP hosting and WordPress skills | WordPress | WordPress asks for PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, which existing PHP operations teams can usually run without a new stack. |
| Front end is already Next.js and the team wants one deployment | Payload | Payload installs into an existing Next.js app folder, so the CMS and front end can share a codebase and deployment pipeline. |
| Large existing WordPress content and plugins must carry over | WordPress | Payload's comparison page contains no migration guidance for content, themes or plugins, so the rebuild effort falls entirely on your team. |
How WordPress and Payload are built and deployed
WordPress and Payload differ most in what you run and who patches it. WordPress is a PHP application with a database that many hosts already manage, while Payload is application code that your team builds, deploys and upgrades inside a Next.js project. The cards below cover the runtime, the database, the deployment targets and the patching model that follow from those choices.
WordPress runtime requirements
WordPress.org recommends PHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater. Most shared and managed WordPress hosts already provide this stack, so the platform team often owns less of the runtime than with Payload. Check that your host's PHP and database versions match the WordPress release you run, and confirm who applies PHP and database patches, since WordPress's automatic updates cover the core software, not the server beneath it.
Payload runs inside your Next.js app
Payload installs directly into an existing Next.js /app folder, so the CMS, the admin panel and your front end share one codebase and one build. This makes Payload a change to your application, not a separate server. Your engineers own the Node.js runtime, the Next.js version, dependency upgrades and the build pipeline, and every Payload upgrade is a code change that needs testing before release.
Database choice and its constraints
Payload supports MongoDB, PostgreSQL and SQLite, so the database is a decision your team makes at project start. WordPress is tied to MariaDB or MySQL. If your organization already runs PostgreSQL for other systems, Payload lets you standardize on it, while WordPress would add a second database engine. Confirm backup, restore and high availability for whichever database you pick, because WordPress hosts and Payload deployments handle these differently.
Where Payload can be deployed
Payload documents deployment to Vercel, to Cloudflare Workers with R2 and D1, or self-hosting anywhere. Each target changes the operating model: a managed platform reduces server work but adds platform limits and vendor dependency, while self-hosting gives you full control and puts patching, scaling and failover on your team. Compare these choices against your data residency rules and the storage your media library needs before you commit.
Patching ownership in each model
WordPress applies automatic background updates to core, and since WordPress 5.6 new sites have automatic major release updates enabled by default. Plugin and theme updates are applied automatically only in special cases chosen by the WordPress.org API, so most plugin patching still falls to your team. With Payload, dependency and CMS upgrades are planned releases that your developers test and deploy, which gives you more control over timing but more work to keep current.
Support windows and version currency
WordPress 7.1 was released on August 19, 2026, and only the most recent release in the 7.1 series is actively maintained, with the WordPress Security Team backporting critical fixes to older versions as a courtesy. Payload v3.91.0 was released on October 15, 2026, while a v4.0.0 beta line is in progress. Before you choose, ask Payload and your hosting provider which release lines receive security fixes and how long each one is supported, and plan your upgrade cadence around that answer.
How schema, access control and localization differ
In Payload, content models are defined as collections and fields in TypeScript configuration that lives alongside the application code. Changes to a model go through the same review, branching and deployment path as the front end, and Payload generates TypeScript types automatically from those definitions, so the front end can read the same shape the CMS writes. In a typical WordPress headless setup, content types and fields are usually built in an admin screen through a custom fields plugin such as Advanced Custom Fields, and the REST API exposes whatever that configuration produces. Payload's comparison page describes this contrast as the core difference, and it is the vendor's own framing.
- Model location: Payload keeps the schema in version-controlled code, while WordPress models often live in the database as plugin configuration.
- Type safety: Payload generates TypeScript types from the collections, which reduces hand-written mapping between the CMS and the Next.js app.
- Change control: Schema edits in Payload follow code review and deployment, whereas WordPress field changes made in the admin may need separate export and sync steps.
- Editor flexibility: Teams that let editors reshape content types on their own may find the admin-driven WordPress model easier to change without a developer.
- Plugin dependency: Custom fields plugins add a dependency that must be tracked through updates and licensing.
Confirm in a proof of concept how your current field groups, relationships and conditional logic map to Payload collections and blocks, and who will own schema changes after launch.
Payload's comparison page states that access rules are written as functions and can apply at the document or field level. WordPress has a role and capability model that covers users, editors and administrators, but row-level and field-level rules for a headless API typically depend on several plugins and custom code. Because the rules sit in the application layer, the same logic governs what the admin panel shows and what the API returns, which is the point of comparing the two models closely. Treat the vendor's description as a claim to test against your own permission matrix.
- Document rules: Payload access functions can decide per document whether a user may read, update or delete an entry, based on fields such as author or status.
- Field rules: Field-level functions can hide or restrict individual values, which is the case most WordPress setups handle with extra plugins.
- Customer accounts: Payload includes built-in authentication, so admin and customer users can be managed inside the CMS, while WordPress separates subscriber roles from site administration unless a membership plugin is added.
- Role sprawl: WordPress permissions across several plugins can be hard to audit as one matrix, so the review effort grows with each added plugin.
- API consistency: Confirm that the rules apply identically to REST or GraphQL requests, preview endpoints and webhooks.
Ask the vendor or your own engineers to run a written permission test covering every role, document state and field that carries regulated or personal data.
Payload's comparison page says field-level localization is built in, so individual fields can hold different values per locale within one document. WordPress typically handles multilingual content through a translation plugin or a multilingual plugin suite, each with its own data model, URL structure and translation workflow. The difference matters most when a headless front end must request content in several languages, fall back to a default locale or keep translations in sync during editing. The vendor describes this as a built-in capability, so confirm how it behaves with your locales and workflow.
- Built-in model: Payload localizes at the field level inside the document, which can simplify queries from a single Next.js route.
- Plugin model: WordPress translation plugins store translations in their own structures, so API output and migration logic depend on the chosen plugin.
- Fallback rules: Check how missing translations fall back to a default locale in both the CMS and the front end.
- Workflow tooling: Confirm whether translators can review drafts, compare versions and publish per locale without extra tooling.
- Scale of change: Localized fields increase storage and query shape, so test with your real number of locales and content volume.
Run a proof of concept with one fully translated content type and a fallback case, and record how editors and the front end behave at each step.
The statements about schema, access and localization come from Payload's own comparison page and README, so they describe intent and design rather than independent measurement. Payload has no WordPress importer documented on that page, so a proof of concept also has to cover how existing WordPress fields, roles and translations would be moved and checked. A short, written test plan lets security, content and engineering teams judge the claims against the same evidence.
- Permission matrix: List each role, content type and field, then test read, write and delete attempts through the API and admin panel.
- Translation cases: Test a missing translation, a partially translated entry and a published change in one locale while another remains in draft.
- Schema change: Make a field change in code and confirm it reaches the admin, the generated types and the front end without manual steps.
- Audit trail: Confirm which access decisions and content changes are logged, and where those logs are stored.
- Migration sample: Export a representative set of WordPress fields and translations and map them to a draft Payload schema.
Ask Payload for documentation of its access and localization behavior in the version you plan to deploy, and confirm the results against your own environment before making a decision.
Capability comparison: WordPress and Payload
This table compares WordPress and Payload on the capabilities that shape a headless build, from license and runtime to access control and updates. Where a capability depends on a plugin or on a version we have not verified for this page, the cell says so, and the confirm column tells you what to check before you commit.
| Capability | WordPress | Payload |
|---|---|---|
| License | GPLv2 or later, per the Free Software Foundation license terms | MIT licensed |
| Language and runtime | PHP; WordPress.org recommends PHP 8.3 or greater | TypeScript running inside a Next.js app |
| Database support | MariaDB 10.11+ or MySQL 8.0+ recommended by WordPress.org | MongoDB, PostgreSQL and SQLite supported |
| Schema definition | Content types usually built through plugins such as Advanced Custom Fields | Collections and fields defined in TypeScript config in code |
| Authentication | Built-in user roles; extra logic usually comes from plugins | Built-in authentication for admin and customer users |
| Versions and drafts | Revisions and drafts available in core; headless workflows may need plugin support, so confirm | Built-in versions and drafts |
| Localization | Typically relies on multiple plugins; confirm your language setup | Field-level localization built in, per Payload's comparison page |
| Access control | Roles and capabilities, often extended by plugins | Field-level access control written as functions at document or field level |
| Live preview | Depends on your front end and plugin setup; confirm with your build | Built-in live preview with a customizable React admin panel |
| TypeScript types | Not generated from schema by default; confirm your tooling | Types generated automatically from code-defined collections and fields |
| Deployment options | Any PHP and MariaDB or MySQL host that meets WordPress.org requirements | Vercel, Cloudflare Workers with R2 and D1, or self-hosted anywhere |
| Plugin ecosystem | Large plugin ecosystem; plugin quality and upkeep vary, so audit each one | Smaller ecosystem; most features are built in, so confirm any extension you need |
| Automatic updates | Background updates for minor and, on new sites, major releases; plugins updated only in special cases set by WordPress.org | No equivalent automatic update mechanism in supplied facts; plan your own upgrade cycle and confirm |
What each license allows and what is paid for
WordPress is released under the GPLv2 or later from the Free Software Foundation, as stated on the WordPress license page. That license lets you run, modify and redistribute the core software, and the facts supplied do not describe a paid WordPress core edition. Your costs therefore sit in hosting, operations and the people who maintain the site, not in a license fee for the core.
- Core is free to run: The GPL places no per-site or per-user license fee on the core software itself.
- Hosting is paid to a provider: You pay for PHP and MariaDB or MySQL capacity, backups and any managed WordPress service you choose.
- Upgrades are paid in labor: Maintaining a current 7.1 series release and applying security fixes is internal or contracted effort.
- Redistribution rules apply: If you ship modified WordPress code to others, the GPL terms govern that distribution.
- Support is optional: Paid support comes from providers or agencies you hire, not from a WordPress core edition.
Check which WordPress maintenance window your team will track, and confirm any managed hosting or support terms directly with the provider you select.
Payload is MIT licensed, according to its GitHub repository. The MIT license allows commercial use, modification and redistribution with a notice requirement, and it does not impose the copyleft terms that GPL carries. The supplied facts describe deployment to Vercel, to Cloudflare Workers with R2 and D1, or self-hosting anywhere, but they do not describe a paid Payload edition.
- Self-hosting is the open path: Payload installs into an existing Next.js
/appfolder and can run on infrastructure you control. - Vercel and Cloudflare are hosting choices: Deploying to either platform means paying that platform's hosting terms, which are separate from the Payload license.
- No paid edition is documented here: The supplied facts do not list a commercial Payload tier, so do not assume one exists or is priced.
- Database choice affects cost: Payload supports MongoDB, PostgreSQL and SQLite, and the database service you run carries its own licensing and hosting costs.
- Release lines differ: The v3.91.0 release and the v4.0.0 beta line may carry different terms in practice, so confirm which line you will build on.
Ask Payload for written hosting and support terms before you commit, and confirm that no commercial tier is required for your deployment model.
The core license does not decide the licenses on everything you install. WordPress plugins and themes carry their own licenses, and a site can depend on dozens of them. A GPL-licensed core does not automatically make every premium plugin free to use, copy or redistribute, so the license of each extension needs its own review.
- Free and premium extensions differ: Commercial plugins and themes may be licensed per site, per developer or per year, and those terms recur.
- Custom fields tools need checking: Plugins such as Advanced Custom Fields used to model content have their own license and update terms.
- Payload needs fewer third-party add-ons for core features: Its built-in authentication, localization and access control reduce the number of extensions you must license, which is a fit question rather than a cost guarantee.
- Your own code has a license too: Custom Payload or WordPress code is yours to license, but any third-party npm package or PHP library carries its own terms.
- Inventory drives the answer: A list of every plugin, theme and package with its license is the input a legal or procurement review needs.
Build a license inventory for your current WordPress site and compare it with the packages your Payload build would pull in before deciding.
License cost is only part of what you pay. One-time costs include the initial build, data migration and any rebuild of themes or content models. Recurring costs include hosting, database operations, backups, plugin renewals and the staff time that applies updates. The supplied facts do not give price or duration figures for either platform, so you should ask for them in writing.
- One-time build work: A move from a WordPress-based headless setup to Payload requires modeling content in code and rebuilding the front end, because Payload's comparison page offers no migration guidance for content, themes or plugins.
- Recurring hosting: WordPress hosting needs PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, while Payload's hosting depends on the Node.js and database stack you select.
- Recurring extension fees: Renewals for paid plugins continue for as long as you use them.
- Staff time to maintain: Applying WordPress releases, checking plugin compatibility and patching the front end all recur.
- Quote items to request: Ask for line items covering build, migration, hosting, support hours and renewal terms, with each figure tied to a written scope.
Request a written quote that separates one-time build work from recurring hosting and support before comparing totals.
How WordPress automatic updates change the upkeep effort
WordPress core updates reach most sites without a planned upgrade project, but plugins and themes do not follow the same path. WordPress has shipped background updates since version 3.7, and since 5.6 newly created sites have automatic major release updates enabled by default. Plugins and themes receive automatic updates only in the special cases the WordPress.org API flags, which the WordPress Security Team uses to patch critical vulnerabilities. Every other plugin update still needs someone to review and apply it. Check which of your sites were created after 5.6 and which were migrated from older installs, because the default may not match what your site actually runs.
Only the latest WordPress release is officially supported, so the version you run matters. The current line is WordPress 7.1, released August 19, 2026, with 7.1.3 published on October 6, 2026. The WordPress.org releases archive states that only the most recent release in the 7.1 series is actively maintained. Older versions receive critical security fixes as a courtesy backport from the Security Team, which is not a support commitment. Your team should confirm how it tracks the installed core version, plugin versions and PHP version on each site, and set a rule for how quickly a new minor release is applied in a staging copy before production.
With Payload, your team owns dependency upgrades inside the Next.js app. Payload installs into an existing Next.js /app folder, so CMS version changes arrive as package updates to the same codebase that builds your front end. Payload v3.91.0 was released on October 15, 2026, and a v4.0.0 beta line is in progress, with v4.0.0-beta.2 published on October 16, 2026. Beta releases are not production upgrade targets, so plan a deliberate move to v4 once it is stable. Ask who will review breaking changes in the Payload GitHub releases and how a CMS bump is tested alongside front end dependency changes.
What drives running cost for each platform
Running cost for WordPress and Payload splits into one-time build work and recurring operations. The six areas below show who pays for each component, which costs recur, and what to ask for in a quote before choosing.
Hosting infrastructure
WordPress needs PHP hosting with MariaDB or MySQL, while Payload runs inside a Next.js app on Vercel, Cloudflare Workers with R2 and D1, or your own servers, with MongoDB, PostgreSQL or SQLite as the database. Hosting is recurring in both cases, but the bill changes with the stack. Ask each vendor or host to itemize compute, database, storage and bandwidth for the front end and the CMS separately, so the two headless layers can be compared like for like.
Developer skills
A headless WordPress site already needs PHP maintenance alongside the JavaScript front end, so a team may carry two runtimes. A Payload build keeps schema, access rules and the front end in one TypeScript codebase, which can lower the number of specialists on call but raises the demand for React and Next.js depth. Recurring salary or contractor spend follows the skill mix, so ask who will maintain each layer after launch and at what hours.
Plugin and theme maintenance
Many headless WordPress sites depend on custom fields, access and multilingual plugins, each with its own update and compatibility cycle. Payload builds these capabilities into the framework, so the recurring plugin review shrinks, though your own custom code still needs testing. Ask for a list of every WordPress plugin the current site relies on and an estimate of the hours to re-verify or replace each one, since this work recurs with every major release.
Content editor training
Editors who already know the WordPress admin face a one-time retraining cost when Payload's React admin panel replaces it, and the custom admin screens you build will need their own documentation. Training is mostly a one-time cost, but new hires and contractor turnover make it recur. Ask the implementation partner for the training scope, the number of editor roles, and whether the custom admin views are included in the handover.
Upgrades and testing
WordPress applies automatic background updates, and since WordPress 5.6, newly created sites have automatic major release updates enabled by default, which lowers routine effort but still requires regression testing of the headless front end. Payload's code-defined schema and generated TypeScript types catch some breaking changes at build time, yet Payload 4.0.0 is still in beta, so a major version move will need planned work. Ask for the upgrade test plan, the staging environment cost and who signs off on each release.
Support options
WordPress has no paid vendor support tier from its core project, so ongoing support usually comes from hosts, agencies or retainers you buy separately. Payload offers its own licensing and support arrangements, which should be confirmed directly with the vendor because no pricing is supplied here. Support is recurring, and its cost depends on response expectations and who holds the security patching duty. Ask each option for response times, what is covered in writing, and whether a retainer includes security testing.
How to move a headless WordPress site to Payload
This sequence turns a headless WordPress content model into a Payload schema, moves the content with custom scripts, and switches the JavaScript front end over only after both systems have been compared side by side. The output is a tested Payload instance with verified content, access rules and a documented cutover.
Inventory content types and custom fields
Export the list of post types, taxonomies, menus, users and custom field groups from the WordPress site, including the plugin that defines each field group. Your team or your implementation partner does this against a copy of production, not the live site. The inventory is complete when every content type has a row listing its fields, field types, relationships, required status and the front end routes that consume it. Payload's WordPress comparison page does not describe a migration path, so this inventory is the starting point for all custom work that follows.
Map each type to a collection or global
Translate each post type into a Payload collection and each single-instance set of settings into a global, defined as TypeScript config in the Next.js app. Field groups from Advanced Custom Fields or similar plugins become Payload field definitions, with relationships and block-based layouts where the WordPress data is structured that way. Review the mapping with the front end developers and a content editor. It is done when the schema compiles, generated TypeScript types cover every collection, and each WordPress field has a named target or an explicit decision to drop it.
Decide the fate of plugin-driven features
List every feature that a WordPress plugin provides, such as SEO metadata, forms, redirects, caching, sitemaps, search, scheduled publishing or membership logic. For each one, decide whether Payload covers it in its built-in features, whether you will implement it in the Next.js app, or whether a third-party service replaces it. Confirm each decision in writing with the business owner, because some plugin behavior, such as redirect rules or form submissions, is easy to lose silently. The step is complete when every plugin has a disposition and no feature is left undecided.
Rebuild access rules and localization
Recreate the WordPress roles and capabilities as Payload access control functions at collection and field level, and confirm which users exist in the CMS for editors and for any customer accounts. Payload's built-in authentication can manage both groups in the CMS itself, so check whether any WordPress plugin-managed accounts need a migration plan. Then rebuild localization using Payload's field-level localization, validating every translated field against the locales your site serves. Test each role with real accounts on staging. This step is done when a test matrix shows that each role can perform exactly the actions it had in WordPress and nothing more.
Migrate content with custom scripts
Write import scripts that read the WordPress REST API or a database export, transform each record into the Payload schema, and write it through Payload's local API so hooks and validation run. Migrate media files, preserve slugs and internal links, and keep an ID mapping table from WordPress IDs to Payload IDs. Because no importer is documented, the scripts, their tests and the reconciliation reports are custom deliverables that someone must own. The step is complete when record counts, slugs and a sample of rendered pages match between the two systems, and the mapping table is archived with the project documentation.
Rebuild the front end's data fetching
Replace the calls to the WordPress REST API in the JavaScript front end with queries against Payload's local API or REST endpoints, using the generated TypeScript types so mismatches fail at build time. Rework preview, draft handling and caching for the new data flow, since draft and live preview behavior changes when the CMS moves. Have front end engineers run the full set of templates, routes and error pages against Payload on staging. The step is done when every route renders from Payload data, preview works for editors, and the build fails cleanly when a field is missing.
Run both systems in parallel
Keep WordPress live and read-only for the content that changes least while the Payload site runs on a staging or preview address. Compare rendered pages, search results, redirects, forms and access behavior between the two stacks, and log every difference with an owner and a decision. Repeat the content migration as often as the team needs until the reconciliation report is clean for a full pass. Confirm the hosting target, whether Vercel, Cloudflare Workers with R2 and D1, or your own infrastructure, has backups and monitoring in place before go-live.
Cut over and keep WordPress as a fallback
Switch the production domain to the Payload-backed front end during a window agreed in advance, freeze editorial writes in WordPress for that window, and run the final content delta import. Keep the WordPress database and files in read-only archive form for a retention period your compliance owner sets, and document the rollback steps in case of a severe fault. Confirm the cutover with a checklist covering DNS, redirects, certificates, analytics, search indexing and editor sign-off. The step is complete when production serves from Payload, the archive is verified, and the runbook names who can reverse the cutover.
Where a WordPress to Payload rebuild usually runs long
The rebuild usually runs long in the places where WordPress does work that nobody wrote down. Before you estimate anything, inventory what your plugins actually do. A custom fields plugin may store field data in ways your Payload collections must reproduce, and a commerce, forms or SEO plugin may run logic in hooks, filters or shortcodes that the front end depends on. Payload documents its own WordPress comparison as a vendor view, and it gives no guidance on migrating content, themes or plugins, so every plugin behavior you rely on is an item for your own discovery. Ask each plugin's maintainer or read its code for side effects such as scheduled posts, rewrite rules, user meta or custom post types, and log each one as a requirement, a replacement or a retirement.
Media and URLs are the next common overrun. Every published post, page and attachment has an address that search engines, email campaigns and partner links already use. Decide early how Payload collections will map to existing paths, how upload files and image sizes will be moved and regenerated, and where the redirect table lives. Plan to test redirects against a crawl of the live site rather than a sample of pages. Editorial workflow is the third area. WordPress roles, draft states and scheduled publishing often run through plugins, while Payload handles versions, drafts and access rules in code. Map each editor action to a Payload control, such as versions and drafts, field-level access control or a hook, and confirm with editors which steps they will still expect.
Multilingual content and preview are where the design choices are hardest to reverse. Payload has field-level localization built in, but your WordPress translations may be stored as separate posts linked by a plugin, so the mapping of language variants to fields has to be decided before any content moves. Preview is the other constraint: Payload offers live preview in its admin panel, but your JavaScript front end also needs a preview route that reads drafts through the same access rules. Confirm with your front-end team how preview tokens, draft reads and cache invalidation will work. DeployOpen works on fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts, so this discovery should produce the written inventory that the timeline is based on. No duration is estimated here.
Questions teams ask before choosing WordPress or Payload
How much effort does a move from WordPress to Payload take?
Effort depends mostly on how much structured content, custom field logic and front-end work sits behind the current site. Payload's own WordPress comparison page presents Payload as a TypeScript-defined content model, but it contains no guidance on migrating content, themes or plugins, so the move is a rebuild rather than a configuration change. The main drivers are the number of content types, how many custom fields and relationships each one uses, how many posts and media files must be carried over, and how much of the current front end is replaced. Ask any implementation partner to size these four inputs in writing before comparing quotes.
Can our team run the WordPress to Payload move without outside help?
A team with strong TypeScript and Next.js skills can build a Payload project, but the move also needs WordPress export knowledge, content mapping decisions and editor sign-off on the new admin experience. Payload installs into an existing Next.js app folder and generates TypeScript types from code-defined collections and fields, which keeps the schema in version control. Whether your own staff have the capacity for a full rebuild, data mapping, testing and cutover is the question to answer honestly. DeployOpen plans, implements, integrates and documents self-hosted platforms in your infrastructure, typically under a fixed scope agreed in writing before work starts.
What does the work need from editors and developers?
Developers define collections, fields, access rules, hooks and the front end, and they own the deployment pipeline. Editors need to review the new admin panel, confirm that drafts, versions and localized fields behave the way their workflow requires, and check that migrated content keeps its meaning. Plan time for editors to test real pages, not demo data, and for developers to replace plugin behavior such as forms, SEO fields or menus with code or with the features Payload provides. Both groups should agree on who approves the content model before build starts, because changing it later costs more.
Will Payload import our WordPress content automatically?
No. The Payload comparison page does not document a WordPress importer, so you should not assume that posts, pages, custom fields or media transfer automatically. Expect to export WordPress data, map each custom field type to a Payload field, transform rich text into the Lexical editor format and move media into your storage. Ask the implementation partner to state in writing which WordPress data types are in scope, which are dropped, and how redirects and URLs will be preserved, since those choices affect search traffic and editor work.
How long will a WordPress to Payload rebuild take?
No public duration is available for this kind of rebuild, and the answer depends on scope. Ask for a written plan that lists content types, number of templates, integrations, migration steps, testing rounds and cutover approach, with a timeline tied to each deliverable. Be cautious of any timeline quoted before the content model is reviewed. The more custom fields, languages and access rules you need, the longer design and testing take. Payload's localization and access features are documented by the vendor, so the proof of concept described below should confirm how much work they save for your site.
Can we keep our WordPress plugins after moving to Payload?
Most WordPress plugins do not carry over, because they run inside WordPress and depend on its hooks, database tables and admin screens. Payload does not run WordPress plugins. Each plugin behavior you rely on, such as custom fields, membership, forms or SEO metadata, must be rebuilt as Payload configuration, a Next.js route or a third-party service. List every active plugin, record what it does for the site, and decide which functions are still needed before estimating the work. Some functions may be better served by a separate service you already run.
What drives hosting cost for Payload compared with WordPress?
Hosting cost depends on the stack you choose, not on a license fee, since Payload is MIT licensed. Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere, and it supports MongoDB, PostgreSQL and SQLite. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. The main cost drivers are the compute and database sizing for your traffic, the build pipeline for a Next.js front end, media storage and bandwidth, backup and monitoring, and who operates each layer. Ask for a line-item hosting estimate that separates one-time setup from recurring infrastructure.
How do we verify Payload's localization and access claims in a proof of concept?
Payload documents field-level localization and access rules written as functions at document or field level, and the vendor says WordPress usually needs several plugins and user roles to match this. Test these claims with your own content. Build two or three representative collections with localized fields, draft and published versions, and a field that only certain roles can read. Then check that translators see only their language, that a restricted field stays hidden through the API and admin panel, and that the rules hold under your expected editing workflow. Record the results and the developer hours spent, and compare them with your current WordPress setup.
How DeployOpen helps teams choose and implement
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For a WordPress vs Payload decision, that means we can help you test both options against your actual content model, editorial roles and access rules before you commit. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before any work starts, so you know what a decision-stage engagement covers and what a build covers.
DeployOpen does not favor either platform. We can run a discovery or a proof of concept that models a representative slice of your content, such as one content type with localized fields, draft and publish states, and field-level permissions for editors and contractors. Use the outcome to check the things this page cannot settle for you: how many custom field groups you actually maintain, whether your front end team is comfortable in TypeScript, and how much of your WordPress plugin set has a Payload equivalent you would accept. Ask us to document each finding so the decision is traceable later.
DeployOpen does not publish a price list. A quote follows from the written scope, so bring your content inventory, integration list, hosting constraints and the number of environments you need. Ask any vendor, including us, to separate one-time work such as schema rebuild, content migration and hardening from recurring costs such as hosting, upgrades, plugin or dependency maintenance and retainers. Ask us to state the assumptions behind each line item so you can compare quotes on the same basis.
