Joomla preparation must treat the site as a connected content system rather than a collection of Articles and database tables. Articles depend on Categories, menu items, modules, access levels, languages, media, templates, plugins, components, and routes. A content record can exist in the database yet remain unreachable, hidden from the intended user group, assigned to the wrong language, or dependent on an extension that is absent from the Target Store.
The preparation package should make those relationships explicit before migration begins. Every major task needs an owner, an evidence artifact, and a ready condition. The objective is not to complete the target design in advance. It is to remove ambiguity about what Joomla owns, what an extension owns, what should remain external, and which representative records will expose the most important relationships during representative migration test.
Secure Administrative, Hosting, and Source Evidence
Start by confirming who can access the Joomla Administrator, hosting control panel, database, filesystem, media directories, DNS records, and any external storage or delivery services. Access should be sufficient to recover the site, inspect extension-owned records, and produce reliable evidence even if the public site becomes unavailable.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm Joomla Administrator access | Site owner or Joomla administrator | Working administrator account and role summary | Required menus, users, extensions, and configuration areas can be inspected. |
| Confirm hosting and database access | Hosting or infrastructure owner | Control-panel access, database credentials, and PHP/database version record | A current database export and filesystem backup can be created independently of the live site. |
| Capture the Joomla environment | Technical owner | Joomla version, PHP version, database version, active template, enabled languages, and caching/CDN notes | The source environment is documented in one dated inventory. |
| Record external dependencies | System owner | DNS, CDN, object storage, email, search, forms, CRM, analytics, and authentication list | Every external dependency has an owner and continuing target decision. |
| Freeze source identifiers | Migration coordinator | Article IDs, Category IDs, menu-item IDs, user IDs, extension record IDs, and external keys where relevant | Important cross-record references can be traced after extraction. |
Create a full backup before any cleanup changes. Keep the original backup immutable and record its date, scope, location, encryption or access controls, and restoration owner. If the site uses external media storage, CDN rewriting, or remote file references, document those separately because a local filesystem archive may not contain the complete content set.
Inventory Articles, Categories, Menus, Modules, and Routes
Joomla Articles do not define the complete public structure. Categories organize content, menu items create routes and page contexts, modules supply surrounding content, and access levels control who can view each object. Preparation should map these relationships for the pages that matter most.
| Content relationship | Preparation evidence | Ready condition |
|---|---|---|
| Article to Category | Article and Category export with IDs, aliases, language, status, and access level | Every in-scope Article has an identified Category or an intentional uncategorized treatment. |
| Menu item to destination | Menu inventory with menu type, parent item, alias, route, language, access level, and linked component/view | Priority routes have an explicit target destination and are not inferred from Article titles alone. |
| Module to page context | Module list with position, menu assignment, language, access level, and owning extension | Business-critical modules are classified as content, presentation, extension output, or retirement candidates. |
| Category hierarchy | Parent-child Category map with aliases and descriptions | Hierarchy, multilingual variants, and access restrictions are understood. |
| Redirect and SEF behavior | Current URL list, redirect records, routing extension rules, and canonical notes | High-value paths have one intended target route or redirect decision. |
Separate permanent content structure from presentation. A menu item may point to one Article, a Category Blog, a tagged-items view, a contact, a custom component, or an external URL. A module may appear on selected menu items rather than on every page using the same Article. Record the actual route and assignment logic instead of assuming that migrating the Article recreates the page.
Prioritize URLs with organic traffic, backlinks, campaign use, legal importance, account access, or frequent customer use. For each priority URL, record the current object owner, destination intent, language, and whether the route should remain direct, redirect once, or be retired.
Prepare Users, Groups, Access Levels, and Permissions
Joomla separates users, user groups, viewing access levels, and permissions. A user may belong to several groups, and group hierarchy can affect inherited access. Access levels can control Articles, Categories, menu items, modules, and component records. A simple user export is therefore not enough when the site depends on memberships, editorial roles, restricted content, or custom account types.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Classify user populations | Joomla administrator and business owner | User list grouped by administrators, authors, members, customers, partners, blocked users, and inactive accounts | Each population has an intended target role or explicit exclusion. |
| Map group membership | Access-control owner | User-to-group and group-hierarchy export | Multi-group users and inherited relationships are visible. |
| Map viewing access levels | Content or membership owner | Access-level definitions and assigned groups | Restricted content can be traced to the users who should see it. |
| Map permissions | Joomla administrator | Component and global permission summary for important roles | Administrative capability is not confused with front-end viewing access. |
| Record authentication dependencies | Identity owner | Local login, social login, LDAP, SSO, MFA, password policy, and reset workflow inventory | The target account-access approach is documented without assuming source password portability. |
Where a commerce, membership, learning, directory, or community extension creates its own profile or account records, link those records to the Joomla user ID and classify the extension as the actual owner of the business relationship. Do not flatten membership status, subscription history, course progress, vendor data, or Customer records into generic Joomla user metadata.
Prepare Multilingual Content and Language Associations
Joomla multilingual sites can assign Articles, Categories, menu items, modules, contacts, and other records to languages and connect equivalent items through associations. Preparation must preserve both the language assignment and the relationship among translated counterparts.
Create an evidence set containing enabled content languages, language tags, default language, language-specific home menu items, associated Articles, associated Categories, associated menu items, and language-switcher configuration. Identify records marked for all languages separately from records assigned to a specific language.
| Multilingual concern | Evidence | Ready condition |
|---|---|---|
| Translated Article family | Associated record IDs, aliases, titles, language tags, and routes | Every in-scope translation has a known counterpart or an intentional standalone treatment. |
| Language-specific navigation | Menus, home items, menu aliases, and module assignments by language | Each language has a defined primary navigation and home route. |
| Shared media or metadata | File references, captions, alt text, and metadata by language | Shared assets and localized fields are distinguished. |
| Untranslated fallback content | Records assigned to all languages or used as fallback | Fallback intent is documented rather than inferred from missing translations. |
Do not treat identical aliases or titles as proof of association. Use Joomla’s actual language and association records where available, then note any manually maintained cross-language links that rely on templates or extensions.
Inventory Extensions, Custom Fields, Templates, and Custom Tables
Joomla extensions can own content, transactions, profiles, forms, redirects, tags, downloads, bookings, memberships, events, directories, and integrations. Templates and overrides can also change how native records are rendered without owning the records themselves. Preparation should identify the owner of every business-critical non-core dataset.
| Extension evidence | Required detail | Ready condition |
|---|---|---|
| Component inventory | Name, version, purpose, database tables, core IDs referenced, and current owner | Every important component has a retain, replace, restructure, externalize, or retire decision. |
| Plugin and module inventory | Trigger or display role, configuration location, and related records | Behavior dependencies are separated from content records. |
| Custom fields | Field group, type, allowed values, assigned contexts, stored values, and consuming template/extension | Fields required in the Target Platform have a named implementation owner. |
| Template and override inventory | Active template, child template, overrides, custom layouts, positions, and builder dependencies | Presentation work is not mistaken for data migration. |
| Custom tables and code | Schema, primary keys, foreign keys, business purpose, and external identifiers | Active custom data can be traced to the workflow that consumes it. |
For each extension-owned dataset, prepare representative source records and a relationship map. A form extension, for example, may contain reusable form definitions, submissions, files, notifications, and CRM delivery state. A directory extension may contain listings, owners, Categories, locations, claims, and reviews. These should not be reduced to “custom fields” when they are independent entities.
Prepare Media, Files, and Embedded References
Joomla media can be referenced from Article HTML, custom fields, modules, templates, galleries, download extensions, remote storage, or third-party builders. A filesystem copy alone does not show which records use each file.
Create a media inventory that distinguishes local images, documents, audio/video, generated thumbnails, remote assets, and extension-managed uploads. Capture file path, filename, MIME type, size, owning record where known, and whether the reference appears in Article content, a custom field, metadata, a module, or an extension table.
Identify absolute URLs, relative paths, encoded filenames, duplicate files, broken references, and case-sensitive path differences. Do not rename or deduplicate source files until their references are recorded. If cleanup is necessary, maintain a source-to-cleaned path ledger so the original relationship remains traceable.
The ready condition is not a perfect media library. It is a complete enough evidence set to connect priority content and extension records to the files they require.
Separate Joomla Core Scope From Commerce and Application Scope
A Joomla site may also contain J2Commerce, J2Store, VirtueMart, membership, LMS, booking, event, directory, or custom application data. Joomla preparation should identify those domains without absorbing their record-level checklists.
| Domain | Joomla-level preparation | Separate owner |
|---|---|---|
| Commerce extension | Joomla version, users, Articles, Categories, menus, modules, plugins, template, and extension inventory | Product, Customer, Order, pricing, payment, shipping, tax, and commerce-extension records belong to the commerce checklist. |
| Membership or LMS | Users, groups, access levels, protected Joomla content, and extension inventory | Plans, subscriptions, enrollments, progress, payments, and certificates belong to the application owner. |
| Forms and CRM | Menu/module placement, user links, and extension inventory | Form definitions, submissions, files, notifications, and CRM identifiers belong to the form/CRM owner. |
| Custom component | Joomla users, menus, modules, routes, and template integration | Custom entities, workflows, and external keys belong to the custom component scope. |
This boundary prevents duplicated preparation and makes responsibility clear. The Joomla package should still record every dependency that can hide, expose, or route application-owned content.
Select Representative Migration Test Samples
Representative migration samples should expose Joomla’s most important relationships, not simply include the newest Articles. Build a sample register with source IDs, URLs, reasons for selection, linked objects, expected ownership, and the source evidence required for interpretation.
Include at least:
- an Article linked through a single-Article menu item;
- an Article reached through a Category Blog or List view;
- a multilingual Article family with associated menu items;
- restricted content using non-public access levels;
- a page whose visible output depends on modules;
- content with custom fields and embedded media;
- a priority legacy URL or redirect;
- a record owned by a major extension or custom component;
- a user with multiple groups where access meaning matters.
The sample register is ready when each record identifies the Article, Category, menu item, module, language, access level, media, extension, and route relationships it is expected to exercise. The register should remain focused on complete, traceable source evidence.
Establish the Final Readiness Gate
Before migration begins, the coordinator should be able to answer the following questions from documented evidence rather than memory.
| Readiness question | Ready condition |
|---|---|
| Can the source be recovered? | Immutable database and filesystem backups exist, with a restoration owner and external-storage notes. |
| Are priority pages traceable? | Articles, Categories, menu items, modules, languages, access levels, media, and routes are linked for high-value content. |
| Are users and permissions understandable? | User groups, access levels, permissions, and authentication dependencies are documented. |
| Are extensions classified? | Each important extension and custom table has an owner, purpose, source evidence, and target decision. |
| Are application boundaries explicit? | Commerce and other application records are assigned to their own preparation scope. |
| Are representative samples selected? | The sample register covers routing, access, multilingual, media, extension, and custom-data complexity. |
| Are unresolved items controlled? | Every unresolved dependency has an owner, decision date, and effect on scope. |
A missing cosmetic decision does not necessarily block readiness. Missing source access, incomplete backups, unknown extension ownership, untraceable restricted content, or undefined custom data should block the relevant scope until evidence is available.
Conclusion
Joomla preparation is strongest when it preserves relationships among Articles, Categories, menus, modules, users, access levels, languages, media, routes, templates, extensions, and external systems. The checklist should produce recoverable source evidence, named ownership, representative samples, and clear ready conditions rather than a generic list of exports.
When those controls are complete, the migration scope can distinguish Joomla core content from presentation, extension behavior, and application-owned data without relying on assumptions during execution.
Common Questions
What should be prepared first for a Joomla migration?
Secure Joomla Administrator, hosting, database, filesystem, and external-storage access, then create immutable backups and a dated environment inventory. Without recoverable source evidence, later content and extension analysis cannot be trusted.
Why are Joomla menus part of migration preparation?
Menu items create routes and page contexts. They can point to Articles, Category views, contacts, custom components, or external URLs, and they can carry language and access settings. Migrating an Article alone does not recreate the page through which users reach it.
How should Joomla users and access levels be prepared?
Export users, group membership, group hierarchy, viewing access levels, and important permissions separately. Also identify authentication providers and extension-owned profiles so login identity is not confused with membership, Customer, learner, or vendor records.
What should be done with Joomla custom fields?
Document each field’s group, type, allowed values, assigned context, stored values, and consuming template or extension. A field is ready only when its target owner and business use are known.
How should multilingual Joomla content be represented in the preparation package?
Record language assignments and Joomla associations for Articles, Categories, menu items, and modules. Include language-specific home items and routes, and distinguish shared content from translated counterparts and intentional fallbacks.
Which Joomla records should be chosen for representative migration test?
Choose records that exercise menus, Category views, multilingual associations, access restrictions, modules, custom fields, media, priority URLs, and extension ownership. Each sample should include the source IDs and relationships needed to interpret it.