Why MODX Users Should Migrate to Next.js in 2026: An Honest Take

Migrating from MODX to Next.js makes sense in 2026. Plugin support, hosting options, and developer availability for MODX keep shrinking. Security patching also lags behind. Next.js pairs static generation with a headless CMS. This cuts hosting costs, improves Core Web Vitals, and taps a much larger talent pool. For most MODX sites today, it's the most practical replacement.

Key takeaways

• MODX's plugin ecosystem, release cadence, and developer talent pool have all been shrinking. This raises the long-term maintenance risk of staying on it.
• Next.js replaces MODX's server-rendered PHP requests with static generation and edge delivery. This usually improves Core Web Vitals and cuts hosting costs.
• A structured migration process keeps SEO risk low during cutover. The steps: content audit, export, Next.js build, redirects, then a parallel run.
• Your headless CMS choice (Payload, Sanity, Strapi, Directus, Contentful) should match your team's comfort with code-defined versus UI-based content modeling, plus your budget.
• We took a WordPress medical practice site from a Lighthouse score of 35 to 94 after a similar move to Next.js and Payload CMS. See the case study.

Updated 26 August 2026: sources added, experience claims checked against our project record, summary added.

The State of MODX in 2026

Let's look at the numbers honestly. MODX 3.x has been around for a while, but adoption has stayed low. The MODX forums, once busy, now see far fewer posts. The official GitHub repository shows less commit activity too, compared with 2018 or 2019, when the community was still pushing hard.

CMS market-share trackers like w3techs show MODX holding a small and shrinking slice of the CMS market. WordPress remains the dominant player by a wide margin. Meanwhile, sites built with JavaScript frameworks and headless CMSes keep gaining ground.

The MODX marketplace (formerly the Extras repository) hasn't produced a meaningful new extension in months. Many popular extras are unmaintained or only partly compatible with MODX 3.x. When an ecosystem stops producing, that's not just a red flag. It's closer to a white flag.

MODX isn't dead. Sites built on it still run. But "still works" is a risky place to be in web development, especially as the surrounding ecosystem thins out.

What MODX Got Right (and Still Does)

Before piling on, credit where it's due. MODX nailed several things that most CMSes still get wrong:

True Content Flexibility

MODX never forced you into a "post and page" mold. Template variables, chunks, and snippets gave developers real content modeling freedom, years before "structured content" became a buzzword. You could build almost anything.

Clean Output

MODX didn't inject its own markup. No mystery CSS classes, no wrapper divs you didn't ask for. Your HTML was your HTML. For front-end developers who cared about craft, this was a revelation.

Developer-Friendly Theming

No theme system to learn. No template hierarchy to memorize. You wrote templates, and that was it. Chunks were reusable partials. Snippets were PHP logic. It was a simple mental model with powerful results.

The Tag Syntax

Say what you want about [[*pagetitle]] and [[!MySnippet]]. Once you learned it, you could build complex pages fast. The caching layer with the ! uncached flag was elegant.

These strengths make MODX developers strong candidates for modern headless architectures. If you already think in structured content and component-based templates, you're halfway to Next.js already.

The Problems You Can't Ignore Anymore

Here's where the picture turns less flattering.

Security Concerns

MODX 3.x fixed many historical vulnerabilities, but running any PHP monolith with a public admin panel is still risky. MODX has had critical CVEs disclosed over the years, and patch adoption on self-hosted installs is often slow, since it depends on individual site owners applying updates.

Compare that to a Next.js site deployed on Vercel or Netlify. There's no server to attack, no admin panel to brute-force, and no PHP to exploit. The attack surface is much smaller when nothing runs server-side to compromise.

The Talent Crisis

Try hiring a MODX developer in 2026 and the problem becomes obvious fast. Developer talent has largely moved to React, Next.js, and modern JavaScript frameworks. Even PHP developers now lean toward Laravel rather than MODX.

This isn't just a theoretical concern. Agencies often report trouble finding contractors willing to maintain legacy MODX codebases once the original developer moves on. When that happens, the site becomes a liability, not an asset.

PHP 8.x Compatibility Headaches

MODX 3.x runs on PHP 8, but many extras don't. If your site depends on third-party snippets or plugins, upgrading PHP can break things. You end up pinned to older PHP versions, which brings back the security problem.

No Modern Developer Experience

No hot module reloading, no component-based architecture, no TypeScript support, no built-in image optimization, no edge rendering, and no ISR.

MODX's workflow is simple: edit a file or chunk in the manager (or via a syncing tool in your IDE), clear the cache, then refresh the browser. It works, but it's slow compared with a modern hot-reloading setup.

Performance Ceiling

MODX can be fast. With careful caching, CDN setup, database tuning, and snippet architecture, quick load times are possible. Next.js gives you strong performance close to out of the box through static generation. On MODX, you're fighting for performance. On Next.js, you're fighting to avoid slowing it down.

Why Next.js Is the Natural Migration Target

You might ask: why not WordPress? Why not Astro? Why not just a static site generator?

All are valid options, but Next.js hits the sweet spot for most MODX migrations. Here's why:

Rendering Flexibility Mirrors MODX Thinking

MODX developers already know that different pages need different caching strategies. In MODX, you'd mark snippets as cached or uncached. In Next.js, you choose between Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Server-Side Rendering (SSR) per page. It's the same idea, done better.

Component Architecture Replaces Chunks

MODX chunks are reusable HTML partials. React components are reusable UI partials with built-in logic. If you've written chunks like [[!$header]] and [[!$footer]], you already think in components. You just didn't have props.

API Routes Replace Snippets

MODX snippets handle server-side logic: form processing, API calls, custom queries. Next.js API routes (or Server Actions) do the same job in JavaScript or TypeScript, with better tooling and testing support.

If you're weighing alternatives, Astro is worth a look for content-heavy sites that don't need much interactivity. But if you need dynamic features, authenticated experiences, or complex data fetching, Next.js is the stronger pick.

The Migration Path: MODX to Next.js

Let's get practical. Here's how a MODX-to-Next.js migration actually works.

Step 1: Audit Your Content Model

Map every MODX template, template variable, and resource type. This becomes your content model in whatever headless CMS you pick. Document everything:

## Resource: Blog Post
- pagetitle → title (text)
- longtitle → seo_title (text)
- content → body (rich text)
- TV: hero_image → hero_image (media)
- TV: author → author (reference)
- TV: category → category (taxonomy)

Step 2: Export Your Content

MODX doesn't have a great export tool. You'll likely need a custom snippet or script that queries modx_site_content and your TV tables, then outputs JSON:

<?php
// Quick and dirty MODX content export
$resources = $modx->getCollection('modResource', [
    'published' => 1,
    'deleted' => 0
]);

$output = [];
foreach ($resources as $resource) {
    $output[] = [
        'id' => $resource->get('id'),
        'title' => $resource->get('pagetitle'),
        'slug' => $resource->get('alias'),
        'content' => $resource->get('content'),
        'template' => $resource->get('template'),
        'tvs' => $resource->getTemplateVars(),
        'parent' => $resource->get('parent'),
        'publishedon' => $resource->get('publishedon'),
    ];
}

header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);

Then write import scripts for your target CMS. It's unglamorous work, but it's a one-time job.

Step 3: Build Your Next.js Front-End

Start with create-next-app and build your templates as page components. Your MODX-to-Next.js mapping might look like this:

MODX Concept	Next.js Equivalent
Template	Layout component
Chunk	React component
Snippet	Server Action / API route
Template Variable	CMS field
Resource	Page / content entry
[[*field]] tag	Props / data fetching
Plugin (event hook)	Middleware
[[!uncached]]	SSR / dynamic rendering
[[cached]]	SSG / ISR

Step 4: Handle URL Redirects

This is where people mess up. Every old MODX URL needs a 301 redirect to its new Next.js equivalent. Build a redirect map and add it to next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-modx-path.html',
        destination: '/new-path',
        permanent: true,
      },
      // ... hundreds more, generated from your export
    ]
  },
}

Don't skip this. Your SEO depends on it.

Step 5: Run Parallel for 2-4 Weeks

Deploy Next.js alongside your existing MODX site. Test everything, check analytics, and confirm forms work. Then flip DNS.

Choosing a Headless CMS to Replace MODX

Next.js is your front-end, but you still need a place to manage content. Here's how the popular options compare for MODX refugees:

CMS	Learning Curve for MODX Devs	Content Modeling	Pricing (2026)	Self-Hosted Option
Sanity	Medium	Excellent (code-defined schemas)	Free tier, then paid plans	No (cloud only)
Strapi	Low	Good (UI-based)	Free (self-hosted), paid Cloud tiers	Yes
Contentful	Medium	Good	Free tier, then paid plans	No
Payload CMS	Low	Excellent (code-defined)	Free (self-hosted), paid Cloud tiers	Yes
Directus	Low	Flexible	Free (self-hosted), paid Cloud tiers	Yes

If you loved MODX's flexibility and self-hosting, Payload CMS or Strapi will feel familiar. If you want a strong developer experience and don't mind cloud-only, Sanity is hard to beat.

We've built production sites with Payload CMS and Sanity, including our SleepDr migration and bdManagedIT case study. The right choice for your MODX migration depends on your team's comfort level and budget. Explore our headless CMS development practice for more detail.

Real Performance Gains: Before and After

Real MODX-to-Next.js migrations follow a clear pattern. Moving from a server-rendered PHP monolith to statically generated pages cuts most of the wait time in the browser. In one of our own CMS migrations, we moved a WordPress medical practice site to Next.js 15 and Payload CMS. Its Lighthouse performance score jumped from 35 to 94, verified in a published case study. MODX sites moving to a similar static Next.js setup usually see the same kind of gain, because the same bottleneck disappears: PHP execution and database queries on every request.

The table below shows the types of improvement to expect, using general ranges rather than one project's exact numbers:

Metric	MODX (optimized)	Next.js on Vercel
Lighthouse Performance	Moderate, limited by PHP execution and database queries per request	Higher, since pages are pre-built and served statically
Largest Contentful Paint	Multi-second on unoptimized pages	Sub-second on most pages
Time to First Byte	Hundreds of milliseconds, even with caching	Tens of milliseconds from a CDN edge
Core Web Vitals	Partial pass without heavy optimization	Full pass achievable by default
Deploy Process	Manual FTP or SFTP	Automated CI/CD, typically under a minute
Hosting Cost	Ongoing VPS or shared-hosting fee	Often $0 on free hosting tiers

For definitions of these metrics, see web.dev's Core Web Vitals overview.

What You'll Miss (and What You Won't)

You'll Miss

• The Manager UI: MODX's admin panel is genuinely easy for content editors to use. Most headless CMS admin panels take more time to learn.
• In-context editing: Editing content where you see it rendered. Most headless setups mean switching between CMS and preview, though Sanity's Presentation tool and Payload's Live Preview are closing this gap.
• Simplicity: One server, one database, one codebase. There's beauty in that. A headless stack has more moving parts.
• The community vibe: The MODX community, while small, has been tight-knit and genuinely helpful.

You Won't Miss

• Cache clearing: The endless cache-clear-refresh cycle.
• TV management: Creating and managing template variables through the UI for every field.
• Database anxiety: That sinking feeling when your MySQL connection maxes out during a traffic spike.
• FTP deployments: Or whatever manual process you used to push changes.
• Plugin event debugging: Trying to figure out which plugin fired, when, and in what order.

Cost Comparison: Running MODX vs Next.js

Let's be honest about total cost of ownership, not just hosting. The figures below are planning estimates based on typical ranges, not numbers from one specific project:

Cost Category	MODX (Annual)	Next.js + Headless CMS (Annual)
Hosting	$540-$1,200 (VPS/shared)	$0-$240 (Vercel/Netlify)
CMS License	$0 (open source)	$0-$3,600 (varies by CMS)
SSL Certificate	$0-$100	$0 (included)
CDN	$0-$600	$0 (included)
Security Monitoring	$200-$500	Minimal (no server)
Server Maintenance	$500-$2,000 (time or outsourced)	$0
Developer Hourly Rate	$75-$120 (scarce talent)	$100-$175 (abundant talent)
Total (excluding dev time)	$1,240-$4,400	$0-$3,840

The wild card is developer rates. MODX developers cost less per hour if you can find them, but scarcity pushes rates up over time. You often end up stuck with whoever is available, rather than picking the best fit.

If you're weighing migration costs for your own situation, we break down our pricing approach here. We're upfront about what these projects actually cost.

FAQ

How long does a typical MODX to Next.js migration take?

A typical migration for a site with 100 to 500 pages takes 6 to 10 weeks with a dedicated team: about two weeks for content modeling and export, three to five weeks to build the Next.js front-end, and the rest for QA, testing, and redirects. Larger sites with complex custom snippets or heavy e-commerce integration can take 12 to 16 weeks. The biggest variable is how much custom PHP logic needs rewriting.

Can I keep my MODX admin panel and just use Next.js for the front-end?

Technically yes. You could build a REST API layer in MODX and feed it to Next.js. But this combines the worst of both systems, since you still maintain the PHP server, the MySQL database, and every existing security concern, while also running a separate front-end codebase. Unless you have a very specific reason, moving content to a purpose-built headless CMS is the better path.

Will I lose SEO rankings during migration?

Not if redirects are handled properly. The key steps: keep the same URL structure where possible, set up 301 redirects for URLs that change, preserve metadata, submit an updated sitemap to Google Search Console after launch, and watch rankings closely during the first few weeks after cutover. Sites that improve Core Web Vitals after migrating often see ranking gains over time, though results vary by site and competition.

What about MODX sites with FormIt forms and complex workflows?

Forms are one of the trickier parts of migration. FormIt handled validation, email sending, hooks, and spam prevention all in one package. In Next.js, teams typically combine Server Actions for processing, Zod for validation, and a transactional email service such as Resend or SendGrid for delivery. It's more explicit, but also more testable and reliable than FormIt's all-in-one approach.

Is Next.js overkill for a simple brochure site?

Maybe. If a MODX site is just a handful of static pages with a contact form, Astro is often a better fit, since it ships zero JavaScript by default and is simpler to set up. But if there's any chance you'll need dynamic features, authentication, or complex data fetching later, Next.js saves you a second migration down the road.

What happens to my MODX extras and custom snippets?

They need to be rebuilt by hand, since there's no automated conversion path. Custom snippets become API routes or Server Actions in Next.js. Extras like Gallery, Articles, or MIGX get replaced by your headless CMS's native features, which are usually more capable. E-commerce extras like Foxy or SimpleCart are typically replaced by Shopify's Storefront API, Snipcart, or Medusa. Plan for this rebuild work explicitly in your migration timeline.

How do I convince my non-technical stakeholders to approve this migration?

Focus on three things stakeholders care about: risk, cost, and results. MODX's shrinking community makes finding developers for emergencies harder every year. Server maintenance and security patching cost time and money even with a free CMS license. And Google factors page speed into search rankings. If competitors load in under a second while your site takes three, that's a business problem worth showing them directly with a Core Web Vitals comparison.

Can I migrate incrementally or does it have to be all at once?

Incremental migration is possible using a reverse proxy setup that serves new pages from Next.js while routing legacy pages to the existing MODX server. You can set this up with nginx rules that send specific paths to the old server and everything else to the new deployment. It adds complexity, but for sites with hundreds of pages, it lets you migrate in phases over weeks or months, rather than a risky big-bang cutover.

If you're sitting on a MODX site and feeling these pain points, the best time to start planning is now, not after a security breach, a departing developer, or a PHP end-of-life deadline forces the issue. We've completed comparable CMS migrations, including our SleepDr WordPress-to-Next.js project and the bdManagedIT WordPress-to-Astro migration. Reach out to us if you want to talk through your specific situation.