Joomla migration
Joomla to a modern stack: rebuild the site, keep the workflows
For Joomla 3 and 4 sites with years of connected workflows: we rebuild on a modern stack, automate feeds and newsletters, add AI where it helps, and move content, users and URLs with a rehearsed cutover.
Illustration: a tangled Joomla site resolves into four layers, Frontend, API, Data and Automation, that serve the website, the newsletter, a mobile app and a chat agent.
Where Joomla 3 and 4 sites stand today
The Joomla project ended security fixes for Joomla 3 on August 17, 2023 and for Joomla 4 on October 14, 2025. A site on either version still runs, but security problems found since then are no longer fixed by the Joomla project. Joomla 5 receives security fixes only from October 13, 2026.
| Version | Bug fixes end | Security fixes end | What it means for a live site |
|---|---|---|---|
| Joomla 6 | Oct 17, 2028 | Oct 16, 2029 | Supported. Upgrading and staying on Joomla is a real option. |
| Joomla 5 | Oct 13, 2026 | Oct 12, 2027 | Security fixes only, so plan the next step now. |
| Joomla 4 | Oct 14, 2024 | Oct 14, 2025 | No fixes from the Joomla project. Upgrade or move. |
| Joomla 3 | Aug 16, 2022 | Aug 17, 2023 | No fixes from the Joomla project, and many extensions are no longer maintained. |
An unsupported version is rarely the only problem. Old Joomla sites usually also run on an old PHP version, carry extensions whose vendors have stopped, and hold years of workflows that nobody has written down. The dates set the deadline; the workflows decide the route.
Why businesses move from Joomla to a modern stack
A modern stack splits the site into parts that each do one job: a fast frontend, an API, a database and automation. That split is what makes the following possible.
Speed and Core Web Vitals
Pages built ahead of time and served from a CDN avoid the PHP and database work behind every Joomla page view. Loading, responsiveness and visual stability, the three Core Web Vitals, become something you design for.
Less patching
A Joomla site keeps core, PHP, templates and every extension on separate update schedules. A modern build has fewer moving parts in public, and its dependencies are updated and tested together in one pipeline.
Lower hosting and upkeep
Static and edge-served pages need little server capacity. The server work that remains is the API and its database, sized for what they actually do.
No extension lock-in
Forms, memberships, newsletters and stores often depend on extensions from small vendors, some no longer updated. In a modern stack those jobs are your own code or well-supported services with documented APIs.
Developers you can hire
React, Next.js, Node.js, TypeScript and Python are widely used, so the site no longer depends on finding Joomla extension specialists.
APIs first
Content, users and data sit behind one documented API, so partners, apps and internal tools read the same source instead of scraping pages.
Ready for automation and AI
Structured content in a real database, queues and an API are what feed pipelines, newsletters and a chat agent need.
One backend for web and mobile
The same API serves the website and a React Native or Flutter app, so a mobile app later does not mean a second backend.
Upgrade, go headless or move to a modern stack?
Leaving Joomla is not always the right call. When editors rely on Joomla and the site mostly publishes pages, upgrading is often cheaper. The assessment tells you which of these routes fits, and why.
Upgrade and stay on Joomla 6
Best when editors rely on Joomla’s workflows, the critical extensions have Joomla 6 versions and the site mostly publishes articles. Our Joomla migration page covers upgrades from Joomla 3, 4 and 5.
View Joomla migration & upgradesKeep Joomla for editors, build a new frontend
Best when you want a fast Astro or Next.js frontend but the editors want to keep Joomla. Joomla’s Web Services API feeds the new frontend, and Joomla itself still needs a supported version.
View React & Next.js developmentMove everything to a modern stack
Best when the site has become an application: partner feeds, memberships, newsletters, custom data and new features that extensions struggle to carry. The rest of this page covers this route.
View Web application development
Start with a migration assessment
Before anyone picks a framework, we map what the current site actually does. The assessment ends with a written recommendation: the route, the stack for each layer, the migration plan, the risks and the phases with their cost.
Content and data model
Articles, categories, tags, custom fields, media and languages, and how much of the archive is still read.
Extensions and custom code
Every extension, template override and custom component, the job it does and what will replace it.
Integrations and workflows
FTP or API feeds, newsletters, payments, CRM, scheduled jobs and the order they run in.
Users and memberships
Accounts, groups, subscriptions and access levels, and how passwords can move.
Traffic and search
The pages that bring visitors, peak load, top URLs, backlinks and Search Console data.
Hosting, backups and risk
Server, PHP and database versions, backup history and what fails today.
To start we need a recent backup or a staging copy, access to the hosting, and the list of tasks editors and visitors must still be able to do after the move.
The modern stack, layer by layer
There is no single best stack. Each choice below is matched to the kind of site it suits. The assessment picks one option per layer and explains the reason in writing.
Frontend
Astro
Best when the site is mainly content: news, articles, guides and landing pages. Pages are built ahead of time and served from a CDN, with interactive parts only where they are needed.
Next.js and React
Best for applications, customer portals, member areas and personalized pages that change per visitor, with server rendering where it matters.
View React & Next.js development
Backend and APIs
Node.js and TypeScript
Best when one language across the frontend and the API helps your team, and for webhooks, real-time features and integration work.
Python and FastAPI
Best for APIs that sit close to data and AI work: ingestion, classification, search and retrieval services, with typed request validation and generated OpenAPI documentation.
Django or Laravel
Best when the site needs a full admin, roles and business rules from day one: Django for Python teams and data-heavy work, Laravel for PHP teams.
View Django development
Data and search
PostgreSQL
The default system of record: articles, users, feeds and history in one relational database, with full-text search and the pgvector extension when a chat agent needs retrieval.
MySQL or MariaDB
Best when keeping compatibility matters, for example a phased move in which part of the Joomla data stays where it is for a while.
Redis
A cache for busy pages and API responses, and the backbone for queues, rate limits and scheduled jobs.
Meilisearch or OpenSearch
Best when readers need fast, typo-tolerant search across a large archive; OpenSearch when you also need heavy filtering and analytics.
Content editing
- Joomla
Strapi or Sanity
Best when editors want a modern headless CMS with drafts, roles and previews. Joomla can also stay as the editing backend for a while.
Mobile apps
React Native or Flutter
Best when a mobile app is on the roadmap: both read the same API as the website, so the app adds screens, not a second backend.
View React Native development
One backend for the website, the newsletter, apps and chat
The new site is not one large application. Each layer does one job, and every channel reads from the same API, so a feature is built once and appears wherever it is needed.
One API for every channel
The website, the newsletter, a mobile app and the chat agent read and write through the same API, with the same permissions and rate limits.
PostgreSQL as the system of record
One database for content, users, feeds and history, backed up and restored as a unit.
Search across the archive
A search index rebuilt from the database, so a search problem never touches the content itself.
Cache and queues in Redis
Cached pages and API responses absorb traffic peaks; queues hold background work such as feed processing and newsletter sends.
Retrieval for the chat agent
Articles and licensed datasets are indexed with pgvector, so the agent answers from your own content and cites it.
An editor interface your team keeps
Editors work in a headless CMS or a custom admin, with drafts, review and scheduled publishing.
Automated content pipelines, with people in charge
Daily partner feeds, formatting, tagging and the newsletter can run on their own. Each step is a separate job in a queue, so one failure does not stop the rest, and an editor stays in charge of what gets published.
Feeds received over FTP, SFTP or API
Files and API payloads are picked up on a schedule or on arrival, checksummed and stored before anything else happens, so the original is always kept.
Parsed and normalized
Each partner format is parsed into one article structure: headline, body, images, companies or symbols, source and embargo time.
Tagged by AI, reviewed by an editor
A model suggests categories, tags and related entities. Suggestions below the confidence threshold you set wait for an editor, and every suggestion is logged.
Published on schedule
Approved items go to the site, the API and the app at the time set, and only the pages that changed are refreshed in the CDN.
Daily newsletter assembled
The newsletter is built from the day’s published articles, previewed by an editor and sent through your email provider, with unsubscribes kept.
Retries, dead letters and fallbacks
A failed step retries with backoff. After the last attempt the item moves to a dead-letter queue with its error and an alert names the feed. If a partner feed is late, the site keeps showing the last good content.
Idempotent by design
Every item keeps a stable ID from its source, so a feed delivered twice creates one article, not two.
New API integrations, for example a market data or partner API, join the same pipeline: responses are validated, cached and versioned before the site, the app or the agent uses them.
A chat agent over your own content and data
A chat agent can let readers ask questions across years of articles and the new API data. It answers from the sources it retrieves, shows them, and stays inside limits you set.
| What the agent does | How it is controlled |
|---|---|
| Answers from your articles and datasets | It retrieves from your own indexed content and licensed data only, and every answer cites the articles or records it used. |
| Respects data licenses | Partner content and licensed datasets are included only where the license allows it; excluded sources are filtered out before the model sees anything. |
| Knows who is asking | Signed-in members see what their plan includes and visitors see public content. Permissions are checked on the server, never by the model. |
| Stays within limits | Rate limits per visitor and per account, cost caps and timeouts protect the site and the model budget. |
| Declines advice it must not give | On a finance site the agent explains data and links its sources. It does not give investment advice or tell anyone to buy or sell. |
| Can be checked | Questions, sources and answers are logged, and a set of real questions is rerun whenever prompts, models or sources change. |
The model sits behind one layer, chosen per task, so it can change without a rebuild. The guardrails follow the risks named in the OWASP Top 10 for LLM Applications 2025, such as prompt injection, data leaks and excessive agency.
Built for heavy, time-sensitive traffic
News and market sites see their biggest traffic at the worst moment for a failure. Reliability is designed in from the start, not added after launch.
CDN caching and incremental rebuilds
Pages are served from a CDN. When an article changes, only that page and the lists that show it are rebuilt or revalidated.
Queues, retries and idempotent jobs
Feed processing, newsletters and API calls run as queued jobs that can safely run twice, so a retry never duplicates an article or an email.
Fallbacks when a provider fails
If a feed, the search engine or the AI model is unavailable, the site keeps serving cached content, search falls back to the database and the agent says it cannot answer rather than guess.
Monitoring and alerts
Uptime, error rates, feed freshness, queue depth and dead letters are monitored, and alerts go to named people.
Backups with tested restores
Database and media backups are kept away from the server, and restores are tested on a schedule, not assumed.
Load tested before launch
The new stack is tested against your real peak traffic patterns before any visitor reaches it.
The migration itself, phase by phase
Content, users and search traffic move in rehearsed steps, and the Joomla site keeps running until the new stack has proven itself.
Assess and plan
The assessment, the chosen stack, a URL inventory and a written migration plan.
Build the new stack
Frontend, API, database and pipelines built against a copy of your real content, with editors trying the new workflow early.
Move content and media
Articles, categories, tags, images and files are migrated by script, repeatably, so the final run is a rerun rather than a new process.
Map every URL and protect search
Each important Joomla URL keeps its address or gets a permanent 301 redirect to its closest replacement. Canonical tags, the sitemap and structured data are rebuilt and checked.
Read the guide: Website migration SEO checklistMove users and replace extensions
Accounts move with their password hashes, so where the new stack can verify the hash format, users sign in with their current password. Forms, memberships, stores and newsletters move to their replacements.
Train editors
Editors rehearse their daily work in the new interface: writing, review, scheduling and the feed queue.
Parallel run, staged cutover and a way back
The new stack runs alongside Joomla on real content before visitors move. The switch is planned for a quiet window, and the Joomla site stays ready for a fast return if something serious appears.
Parallel run
Both systems receive the same feeds for an agreed period, and their output is compared article by article.
Content freeze and final sync
A short editing freeze, agreed in advance, then a last incremental sync of content and users.
Staged cutover
Traffic moves in steps where the hosting allows it, for example one section or a share of visitors first, then everyone.
Checks after the switch
Redirects, top pages, forms, sign-in, feeds, the newsletter and Search Console are checked against a written list.
Rollback window
Until the agreed checks pass, the Joomla site stays ready, and switching traffic back is a rehearsed step.
Retire Joomla
When the window closes, Joomla is archived read-only with a final backup and its hosting is shut down.
How we would approach a site like this
An example request, not a client project: a stock market news and quotes website on Joomla 3 with fifteen years of interconnected workflows, large and time-sensitive traffic, and a wish for automation, a new market data API and a chat agent. This is how we would map it.
Example
| What the site needs | How we would approach it |
|---|---|
| Partner content over an FTP feed | A pickup job per partner over SFTP or FTP, every file checksummed and stored, parsed into one article format, with source IDs so a resent file never duplicates an article. |
| Formatting and tagging | Partner formats normalized in code. AI suggests tickers, sectors and tags, and an editor reviews anything below the confidence threshold. |
| A daily newsletter | Built from the day’s published articles on a schedule, previewed by an editor and sent through the email provider, with unsubscribes kept. |
| New features from a market data API | A FastAPI or Node.js service that validates, caches and versions the provider’s data within its license terms and serves it to the site and the app. |
| A chat agent over articles and data | Retrieval over the article archive and the licensed API data with pgvector, answers with citations, rate limits per visitor and no investment advice. |
| Large, time-sensitive traffic | Astro or Next.js pages from a CDN with incremental rebuilds, Redis caching for quote widgets, and load tests at peak patterns. |
| Fifteen years of workflows | Each workflow inventoried and given an owner, then replaced one at a time and run in parallel with Joomla until the outputs match. |
| Backups and fallbacks | The last good content keeps showing if a feed fails, dead-letter queues with alerts, off-server backups with tested restores, and a rehearsed rollback to Joomla during the cutover window. |
This illustrates our approach; it is not a case study and reports no results. The real plan, phases and price follow an assessment of the actual site.
Some of the teams we have worked with.
Across talent, fitness, mobility, payments and local commerce.Questions about leaving Joomla.
How much does a Joomla to modern stack migration cost?
Pricing follows the assessment. The main cost drivers are the number of content types and custom extensions, the feeds and integrations, user accounts and memberships, any AI features, the traffic the new stack must carry and how many workflows run in parallel during the move. After the assessment you receive a written proposal with phases and a price for each.
How long does the migration take?
It depends on the size of the archive, the number of workflows and integrations, the custom code to replace and how quickly decisions and the content freeze can be agreed. The assessment turns these into a schedule for each phase.
Will the site go down during the move?
The new stack is built and tested alongside the running Joomla site, and visitors move at the cutover. The planned interruption is a short editing freeze agreed in advance, and a rehearsed rollback stays ready until the checks pass.
Will we lose our search rankings?
Any change of URLs carries some risk, which careful mapping keeps small. Important URLs are inventoried and either kept or redirected permanently to their closest replacement, and redirects, canonical tags and the sitemap are checked at launch. Google notes that rankings can fluctuate while it recrawls a moved site, and no one can guarantee rankings through a migration.
Can our editors keep using the Joomla admin?
Yes, in the headless route: Joomla stays as the editing backend and a new frontend reads it through Joomla’s Web Services API, as long as Joomla stays on a supported version. In a full move, editors switch to a headless CMS or a custom admin, and we train them on their real daily work.
Which stack should we choose?
It depends on what the site does. Astro suits content-led sites, Next.js suits applications and member areas, Node.js or FastAPI suits the API, and PostgreSQL is the default database. The assessment recommends one option per layer and explains the reasons in writing.
Do our users have to reset their passwords?
Not where it can be avoided. Joomla stores password hashes, not passwords. Where the new stack can verify the same hash format, users sign in with their current password and the hash is upgraded at that sign-in. Accounts with a format that cannot be verified get a planned, announced reset.
Can we add a mobile app later?
Yes. The website and a React Native or Flutter app read the same API, so an app adds screens and app store work, not a second backend.
Can the chat agent give investment advice?
No. On a finance site the agent explains your articles and data and cites its sources, but it does not give investment advice or recommend buying or selling. It answers only from content and data your licenses allow it to use.
Do we keep our FTP feeds and newsletter?
The partners can keep delivering the way they do today. Their FTP or SFTP feeds and the daily newsletter move into the new pipeline as queued, monitored jobs, and they run in parallel with the Joomla versions until the outputs match.
Bring us the workflow you can least afford to break.
Tell us what your Joomla site does every day: the feeds, the newsletter, the members and the traffic peaks. We start with an assessment and a written recommendation before anything is rebuilt.
Technology names and marks belong to their owners.