I've been building sites on MODX since the Evolution days. I've written custom snippets, wrestled with TVs (template variables, not televisions), and defended MODX in countless CMS debates. So believe me when I say this isn't a hit piece. It's a wake-up call from someone who genuinely loved this platform.

But here's the thing: the web development world has moved on, and MODX hasn't kept up. The community is shrinking, the release cycle has slowed to a crawl, and the talent pool is drying up faster than a puddle in July. If you're still running production sites on MODX in 2026, you need to seriously consider your exit strategy. And for most teams, that exit leads to Next.js.

Let me walk you through why — honestly, without the hype.

Table of Contents

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

The State of MODX in 2026

Let's look at the numbers honestly. MODX 3.x has been out for a while now, but adoption has been... tepid. The MODX forums, once buzzing with activity, now see maybe a handful of posts per week. The official GitHub repository shows increasingly sparse commit activity. Compare that to 2018 or 2019 when the community was still pushing hard.

BuiltWith data from early 2026 estimates MODX powers roughly 0.3% of CMS-detected websites, down from around 0.7% in 2021. WordPress still dominates at ~62%, and newer players like Next.js-based sites (often paired with headless CMSes) are growing at roughly 40% year-over-year.

The MODX marketplace (formerly the Extras repository) hasn't seen a meaningful new extension in months. Many popular extras are unmaintained or only partially compatible with MODX 3.x. When the ecosystem stops producing, that's not a red flag — it's a white flag.

I'm not saying MODX is dead. It still works. Your sites still run. But "still works" is a dangerous place to be in web development.

What MODX Got Right (and Still Does)

Before I pile 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" paradigm. Template variables, chunks, and snippets gave you genuine content modeling freedom years before "structured content" became a buzzword. You could build 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. That was it. Chunks were reusable partials. Snippets were PHP logic. Simple mental model, 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 actually make MODX developers great 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 I have to be blunt.

Security Concerns

MODX 3.x addressed many historical vulnerabilities, but running any PHP monolith with a public admin panel is an inherent risk vector. In 2025, we saw at least two critical CVEs affecting MODX installations, and patches took weeks to arrive. With a shrinking security team, response times aren't improving.

Compare that to a Next.js site deployed on Vercel or Netlify — there's literally no server to attack. No admin panel to brute-force. No PHP to exploit. The attack surface is fundamentally smaller.

The Talent Crisis

Try hiring a MODX developer in 2026. Go ahead. Post the job listing and watch the crickets. The developer pool has migrated to React, Next.js, and modern JavaScript frameworks. Even the PHP talent is going to Laravel, not MODX.

This isn't a theoretical concern. I've talked to agencies that have MODX sites they literally can't find developers to maintain. When the original developer leaves, the site becomes a liability.

PHP 8.x Compatibility Headaches

MODX 3.x runs on PHP 8, but many extras don't. If you've built a site that depends on third-party snippets or plugins, upgrading PHP often breaks things. You end up pinned to older PHP versions, which circles back to 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. No ISR. I could keep going.

MODX's development workflow is essentially: edit a file or a chunk in the manager (or in your IDE via a syncing tool), clear the cache, refresh the browser. It works, but it's slow compared to modern DX.

Performance Ceiling

MODX can be fast — I've built sub-2-second sites on it. But getting there requires significant optimization: full-page caching, CDN setup, database tuning, and careful snippet architecture. Next.js gives you sub-second performance essentially out of the box with static generation. You're fighting for performance on MODX; on Next.js, you're fighting to mess it up.

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

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 valid options, but Next.js hits the sweet spot for most MODX migrations. Here's why:

Rendering Flexibility Mirrors MODX Thinking

MODX developers already understand 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. Same concept, better execution.

Component Architecture Replaces Chunks

MODX chunks are reusable HTML partials. React components are reusable UI partials with built-in logic. If you've been writing 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 in Next.js 14+) do the same thing but in JavaScript/TypeScript with better tooling and testing support.

For teams considering alternatives, Astro is worth evaluating 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 choice.

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 choose. 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 to write 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 effort.

Step 3: Build Your Next.js Front-End

Start with create-next-app and build your templates as page components. Your MODX template → page layout mapping might look like:

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. Verify forms work. Then flip DNS.

Choosing a Headless CMS to Replace MODX

Next.js is your front-end, but you still need somewhere 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 $15/user/mo No (cloud only)
Strapi Low Good (UI-based) Free (self-hosted), Cloud from $29/mo Yes
Contentful Medium Good Free tier, then $300/mo No
Payload CMS Low Excellent (code-defined) Free (self-hosted), Cloud from $50/mo Yes
Directus Low Flexible Free (self-hosted), Cloud from $99/mo Yes

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

We've done extensive work with all of these through our headless CMS development practice, and the right choice really depends on your team's comfort level and budget.

Real Performance Gains: Before and After

I migrated a mid-size MODX site (approximately 400 pages, blog + services + portfolio) to Next.js with Sanity in late 2025. Here are the actual numbers:

Metric MODX (optimized) Next.js on Vercel Improvement
Lighthouse Performance 72 98 +36%
Largest Contentful Paint 2.8s 0.9s -68%
Time to First Byte 680ms 45ms -93%
Core Web Vitals Pass Partial Full pass ✅
Build/Deploy Time Manual FTP 42s auto-deploy Night and day
Monthly Hosting Cost $45/mo (VPS) $0 (Vercel free tier) -100%

The TTFB improvement alone is staggering. MODX has to boot PHP, connect to MySQL, run snippets, assemble chunks, and serve the response — even with caching. A statically generated Next.js page is served from a CDN edge node in milliseconds.

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

You'll Miss

  • The Manager UI: MODX's admin panel is genuinely intuitive for content editors. Most headless CMS admin panels have a learning curve.
  • In-context editing: Editing content where you see it rendered. Most headless setups require switching between CMS and preview. (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, was 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 on 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, in what order.

Cost Comparison: Running MODX vs Next.js

Let's be real about total cost of ownership, not just hosting.

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 are cheaper per hour if you can find them. But scarcity drives up rates over time, and you're often stuck with whoever is available rather than choosing the best fit.

If you're evaluating migration costs for your specific situation, we break down our pricing approach here — we're transparent about what these projects actually cost.

FAQ

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

For a site with 100-500 pages, expect 6-10 weeks with a dedicated team. Content modeling and migration takes about 2 weeks, building the Next.js front-end takes 3-5 weeks, and QA/testing/redirects fills the rest. Larger sites with complex custom snippets or heavy e-commerce integration can take 12-16 weeks. The biggest variable is how much custom PHP logic needs to be rewritten.

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 consume it with Next.js. But this gives you the worst of both worlds: you still maintain the PHP server, the MySQL database, and all the security concerns, while also maintaining a separate front-end. Unless you have a very specific reason, it's better to migrate content to a purpose-built headless CMS.

Will I lose SEO rankings during migration?

Not if you handle redirects properly. The critical steps are: maintain the same URL structure where possible, set up 301 redirects for any URLs that change, keep your metadata intact, and submit an updated sitemap to Google Search Console after launch. Most sites we've migrated see ranking improvements within 4-8 weeks due to better Core Web Vitals scores.

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, you'll typically combine Server Actions for processing, Zod for validation, and a service like Resend or SendGrid for email delivery. It's more explicit but also more testable and reliable.

Is Next.js overkill for a simple brochure site?

Maybe. If your MODX site is literally 10 static pages with a contact form, Astro might be a better fit — 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, starting with Next.js saves you from another migration down the road.

What happens to my MODX extras and custom snippets?

They need to be rebuilt. There's no automated conversion. 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 better). E-commerce extras like Foxy or SimpleCart would be replaced by Shopify's Storefront API, Snipcart, or Medusa. Plan for this effort explicitly in your migration timeline.

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

Focus on three things they care about: risk, cost, and results. Risk: MODX's shrinking community means finding developers for emergencies is getting harder every year. Cost: server maintenance and security patching aren't free, even if the CMS license is. Results: show them the Core Web Vitals comparison and explain how Google uses page speed as a ranking factor. If their competitors are loading in under a second and they're at 3 seconds, that's a business problem.

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

Incremental migration is possible using a reverse proxy setup — you'd serve new pages from Next.js and route legacy pages to your MODX server. We've done this with nginx configurations where specific paths are proxied to the old server while everything else goes to the new Next.js deployment. It adds complexity, but for sites with hundreds of pages, it lets you migrate in phases over weeks or months rather than doing a risky big-bang cutover.

If you're sitting on a MODX site and feeling the pain points I've described, the best time to start planning is now. Not because the sky is falling, but because migrations done under pressure — after a security breach, after your developer quits, after a PHP version reaches end-of-life — are always more expensive and more stressful than planned ones. Reach out to us if you want to talk through your specific situation. We've been through this enough times to know where the landmines are.