Short answer: A Joomla to Next.js migration typically runs 80 to 900+ engineering hours, depending almost entirely on whether your site has user accounts. At $100/hour — a round number so the arithmetic stays visible, not a surveyed rate — that is roughly $8,000 for a brochure site and $45,000–90,000 for a membership or e-commerce site, over 3 weeks to 12 months of calendar time. The expensive part is never the content — it is the URLs, the extensions and the logins.
I spent the better part of a decade building Joomla extensions before I spent any time migrating away from them, so this comes from both sides of the fence.
How much does a Joomla to Next.js migration cost?
Cost tracks engineering hours, and hours track one question: does your site have user accounts? A content site is a URL-mapping problem; a membership site is a data-migration problem, and data migration costs about twice as much.
The hours are the real number. The dollars are those hours at $100/hour. Substitute your own rate.
| Your site | Engineering hours | At $100/hr | What drives the cost |
|---|---|---|---|
| Brochure site, under 50 pages, no logins | 80–160 | $8,000–16,000 | Design and build; content is one script |
| Content site, 200–2,000 articles, long SEO history | 200–450 | $20,000–45,000 | URL mapping and redirect QA, not page count |
| Membership site or shop with order history | 450–900 | $45,000–90,000 | Auth, historical records, payments, permissions |
| Multi-site or multilingual estate | 900+ | $90,000+ | Every locale multiplies QA, not build |
Estimates, not quotes. Each row is wide on purpose: the same page count hides a 20-hour import or a 200-hour one, depending on how much content sits in extension tables rather than articles.
None of it narrows into a quote until someone has read your URL inventory, your extension list and your #__users table. That reading is the first piece of work on any migration, and it is worth buying on its own — a fixed-price look before anybody signs for a rebuild. How we structure engagements.
How long does a CMS migration take?
Calendar time runs longer than engineering time, because migrations wait on people. Content review, redirect sign-off and client testing are not billable hours, but they are weeks.
| Your site | Realistic calendar time |
|---|---|
| Brochure site | 3–6 weeks |
| Content site with SEO history | 8–16 weeks |
| Membership site or shop | 4–8 months |
| Multi-site or multilingual estate | 6–12 months |
One real anchor instead of a bracket: consolidating four WordPress properties into one Next.js and Directus platform took us 12 weeks and 480 hours across two developers, against a five-month client-facing plan.
The item nobody budgets for is the content freeze. Everything published after the export gets migrated twice, and freezing content is politically harder than any technical step below.
What breaks when you migrate off Joomla?
Content survives a migration. URLs, extensions, logins and editorial habits are what break. Each item below carries its mechanism, because the mechanism is what lets you price it.
1. Your URLs contain a database primary key. Joomla's public article URL is <id>-<alias> by default, as in /news/98-shifting-in-new-premises, where 98 is the row ID in your database. Nothing in a modern CMS reproduces those IDs, so every such URL is either mapped by script against the old tables or lost.
2. Your SEF extension invented URLs Joomla never knew about. Joomla's SEO extensions kept their own alias tables, separate from core, so one article is often indexed at three or four addresses: with and without Itemid, with and without the category path, with and without the .html suffix. Your sitemap lists none of them; only a 16-month Search Console export will.
3. Most extensions do not travel, and they are why you chose Joomla. Core Joomla 4/5 ships a Web Services REST API covering content, contacts, categories, fields, media and tags, so the built-in stuff is reachable headless if you want to keep it. Third-party components are the real problem: each is server-rendered PHP that reads Joomla's database and writes into Joomla's template, and unless its author shipped a Web Services plugin for it, a headless frontend cannot call it. Each one gets rewritten, replaced with a SaaS, or dropped. The painful ones: ACL member areas, form builders holding years of submissions, blog components with their own article tables, comment systems keyed to article IDs. No automated path exists for any of it.
4. Some password hashes are portable, some are not. Joomla 5 registers bcrypt, argon2i and argon2id alongside legacy phpass and MD5 for backward compatibility. Hashes prefixed $2y$ (bcrypt), $argon2i$ or $argon2id$ all port to a modern auth layer that can verify them. Hashes prefixed $P$ (phpass) or bare MD5-with-salt do not — check the prefix of the password column, and treat those accounts as a forced reset, which is a churn event.
5. Orders, subscriptions and form submissions detach from their owners. That data sits in extension tables with foreign keys pointing at Joomla's user IDs, so importing users into a system that assigns fresh IDs silently orphans every record. Carry the old primary key across as a column and reconcile counts both ways.
6. Images break inside article bodies, not in the media library. Joomla editors embed relative paths straight into the article HTML, so moving the files leaves every inline <img src> pointing at nothing while the library still looks healthy. Rewrite those paths during import or the articles arrive blank.
7. Multilingual setups do not map one to one. Joomla models a translation as an association table, a language filter plugin and a separate menu tree per language; modern systems use a field on the item or a locale-scoped collection. The associations convert, the menu trees do not, and the /de/ prefixes are re-derived from scratch.
8. Your editors lose the workflow, which is how migrations get reversed. Joomla gave a non-technical editor a WYSIWYG box and modules they could position; structured content gives typed fields. That is better for the codebase and worse for their Tuesday afternoon unless you rebuild the composition step deliberately. On ReelAbilities we shipped 26 content blocks, so a new page takes 15 to 20 minutes with no developer and the content team built 30+ pages after one two-hour training session.
Before any of it, get the real URL inventory:
-- Joomla's public URL is <id>-<alias>, so the primary key is part of your SEO.
-- Diff this against a Search Console export: anything Google knows that this
-- query does not return is an extension URL you were about to lose.
-- Replace #__ with your actual table prefix (check configuration.php).
SELECT c.id, c.alias, CONCAT(c.id, '-', c.alias) AS url_segment, cat.alias AS category
FROM `#__content` c JOIN `#__categories` cat ON cat.id = c.catid
WHERE c.state = 1;
Should I migrate or rebuild my legacy site?
You are almost never migrating a Joomla site. You are rebuilding it and migrating its content and its URLs, because Joomla's value lives in its extensions and its template, and neither travels.
So the real question is how much of the content model you keep, answered per collection rather than per site: keep the article model, rethink anything that has grown past fifteen fields.
There is a third option people skip: keep Joomla running and put the new site in front of it, moving one section at a time. That is the reverse-proxy approach, and it turns one terrifying cutover into a sequence of small reversible ones.
Who should stay on Joomla?
Stay if your site works. Migration earns its cost when the platform is losing you money in maintenance, speed, or work your team cannot do — never because the stack is old.
- You are on a current Joomla release and supported PHP, and nothing is broken. Upgrading costs a fraction of replacing.
- Your pain is one extension. Replacing a component is a week; replacing the platform is a quarter.
- You have under 20 pages and no developer budget. A hosted site builder wins on every metric you care about.
- Nobody on your side can run a deploy pipeline. Next.js needs a build step, and anything beyond a static export needs a Node runtime. Its
output: 'export'mode will serve from shared hosting, but you lose redirects, ISR and image optimization — and on a Joomla migration, losing redirects is the whole job, since the URL map is what you are paying for. Joomla on $8/month hosting with FTP access is a real feature. - You are inside a revenue-critical season. Migrate in your quiet quarter.
Who can migrate my Joomla site to a modern stack?
Any competent Next.js agency can rebuild your frontend. The ones worth hiring treat the redirect map as a deliverable, not an afterthought, and can walk you through how they would build yours before they touch a line of code. Two questions sort the rest quickly. "How will you find the URLs that are not in my sitemap?" — the right answer mentions a Search Console export and the old database. "What happens to accounts with pre-3.2 password hashes?" — if they have to think about it, they have never migrated a Joomla site with logins.
Where I am coming from, so you can discount it correctly. Ready Bytes started in 2009 building social products for Joomla, on 10,000+ websites within two years, then PayPlans, a recurring billing and e-commerce suite on 40,000+ Joomla websites whose IP we sold in 2017. Those installs are a decade old now. They are the legacy sites.
I have not delivered a Joomla to Next.js migration for a client, and I will not imply otherwise. Our production migration work is WordPress to Next.js: the ReelAbilities platform, four WordPress properties consolidated into one Next.js and Directus codebase, launched 2025, 15 city sites on it since, page loads down from 4.2s to 0.8s. The teardown including what went badly is in my WordPress to Next.js and Directus comparison; the architecture is in what the Next.js middleware docs do not tell you about multi-tenancy.
What I bring to a Joomla job is the other half: I know what is in those tables because I put things in them for ten years. And we have run the URL problem on ourselves. This site, a decade after leaving Joomla, still carries 112 redirect rules — 91 of them still pointing at .html or index.php addresses from the Joomla era, 54 of those /blog/item/<slug>.html — plus a 410 list of five legacy-URL patterns and one that catches a leaked template placeholder. The most recent addition to that list dates to August 2026.
Common questions
Will I lose my Google rankings? Only if the redirect map is incomplete. Rankings move after any replatform even when it is done right, so take a Search Console baseline before launch and judge at eight weeks, not eight days.
Is it worth migrating from Joomla in 2026? It is worth it when the platform blocks work you need to do — page speed, structured content, integrations, editorial autonomy. It is not worth it because the stack is old.
Shyam Verma founded Ready Bytes in 2009 and spent its first years building products for the Joomla ecosystem. He writes about migrations, legacy modernization and applied AI at readybytes.in/blog.
Shyam Verma
Full Stack Developer & Founder
Shyam Verma is a seasoned full stack developer and the founder of Ready Bytes Software Labs. With over 13 years of experience in software development, he specializes in building scalable web applications using modern technologies like React, Next.js, Node.js, and cloud platforms. His passion for technology extends beyond coding—he's committed to sharing knowledge through blog posts, mentoring junior developers, and contributing to open-source projects.
