A Joomla preparation package should explain how a visitor reaches content and why that visitor can see or use it. Articles alone do not capture route context, module assignments, language families, or application ownership. Preserve those relationships as source evidence and confirm their intended destination owners before execution.
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 destination site.
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 a representative migration test.
Source access, evidence and recovery
Identify the actual Source Platform and the intended Joomla environment separately. When the Source is Joomla, confirm who can access administration, hosting, database, filesystem, media, DNS, and external storage or delivery services. For another CMS, collect equivalent content, identity, route, and application evidence without inventing Joomla IDs. Access must support recovery and inspection of required records. Record source versions and separately confirm the destination build, enabled compatible extensions, template, languages, roles, and implementation owners.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm actual Source administrative access | Actual Source site owner or administrator; Joomla administrator when Joomla is the Source | Working administrator account and role summary | Required actual Source content, identity, routes, applications and configuration can be inspected; for a Joomla Source, this includes menus, users and extensions. | Actual Source administration; Joomla Administrator access applies to a Joomla Source. Intended Joomla Target roles and access are confirmed separately. |
| Confirm hosting and database access | Actual Source hosting, infrastructure or platform-recovery owner | Available Source control-panel/data access and recovery owner; PHP/database versions and direct database access when provided by that Source | Required Source evidence can be collected and recovered using the available backup, export or managed-recovery method. For a Joomla Source with suitable access, this includes a current database export and filesystem backup; restoration limits are explicit. | Available actual Source infrastructure and recovery method. Another hosted CMS need not provide PHP, database or filesystem access, and a partial export does not establish full-site restoration. |
| Capture the Joomla environment | Source technical owner; Target build owner separately | Actual Source software and component inventory; for a Joomla Source, Joomla version, PHP version, database version, active template, enabled languages, and caching/CDN notes | The source environment is documented in one dated inventory. | Actual Source software, languages and components. Native Joomla environment details are conditional on that Source; intended Target versions and compatibility are independent. |
| Record external dependencies | Source and continuing system owners | DNS, CDN, object storage, email, search, forms, CRM, analytics, and authentication list | Every external dependency has an owner and continuing target decision. | Actual Source and continuing external dependencies. Future Joomla Target endpoints and operating responsibilities require their own owner and decision. |
| Freeze source identifiers | Migration coordinator | Actual Source content, classification, route, user, application and external keys; for a Joomla Source, 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. | Actual Source keys and relationships. Joomla IDs apply only when present in the Source; do not create destination IDs in the source evidence ledger. |
The recovery decision follows the actual Source, while the implementation decision follows the intended Joomla site. Recovering selected content is different from restoring a complete site with its extensions and remote assets. Keep each method’s coverage and limits visible in the evidence ledger, and retain original Source keys so content, access, language and application relationships remain interpretable.
Before cleanup, protect the actual Source evidence through its available recovery method. For a Joomla Source with suitable access, create and retain a full database and filesystem backup. For another Source, preserve its available exports, files or platform-managed recovery evidence and record what they can and cannot recover. Keep the original evidence dated and protected, with its scope, location, access controls and recovery owner recorded; confirm coverage independently of the live site. External storage, CDN rewriting and remote file references need separate evidence because a local archive may not contain every required asset. Resolve a required recovery gap, agree an explicit exclusion or hold the affected scope.
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 action permissions. A user may belong to several groups, and hierarchy can affect the effective permissions. Prepare both the intended audience for each restricted object and the actions each role may perform; a group label alone settles neither. Record inherited and explicit permission decisions at their relevant scope, together with representative users and content.
| 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 them 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 user metadata. Resolve account access separately through the exact Source-to-Target password-verification path or required reset, activation, or first-login plan, with identity-provider and communication owners.
Prepare Multilingual Content and Language Associations
Joomla multilingual preparation needs both language assignments and supported associations between translated counterparts. Articles, Categories, menu items, contacts, and other supported component records can have association relationships. Modules instead need their language, access, menu assignment, and translated content recorded; do not assume they participate in the core association model. Third-party components require their own association support and owner.
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 actual supported association records and language assignments, then record manually maintained cross-language links. A translated Article, its associated menu item, and the module displayed on that route are separate evidence relationships. Confirm each intended destination consumer rather than inferring language readiness from the number of translated records.
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 may contain reusable definitions, submissions, files, notifications, and CRM delivery state; a directory may contain listings, owners, Categories, locations, claims, and reviews. These are independent records rather than generic custom fields. For fields, separately record the compatible definition, permitted values, assigned context, access, and active template/plugin consumer. Stored values alone do not establish that the intended destination can use them.
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.
Confirm Joomla Target implementation prerequisites
The intended Joomla site must be able to use the agreed content relationships, access model and language scope. A Source Article export does not create its menu context, module consumer or extension behavior. Confirm the required destination build and those consumers without treating preparation as a completed site design. Commerce and other applications retain their own record-level owners; Joomla core preparation does not acquire Orders or application transactions merely because the site hosts an extension.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended environment and access | Target technical and site owners | Joomla build, administration, template, compatible required extensions, hosting/storage access and recovery responsibilities | The intended site and required components are available to their owners. |
| Prepare content, routes and access representation | Target content and access-control owners | Article/Category relationships, menu destinations, module assignments, users/groups, viewing access, action permissions and intended authentication path | Priority content has a reachable destination and explicit audience/action treatment, including alternate routes to restricted objects. |
| Prepare language and media consumers | Target multilingual and media owners | Enabled languages, supported counterpart associations, language-specific home/menu context, module language/assignment, file references and external storage | Required translated and shared content, modules and media have compatible consumers; matching titles alone do not establish associations. |
| Confirm extension and application ownership | Target extension, site and application owners | Custom-field definitions/contexts/consumers, components, templates/overrides, external integrations and separately owned commerce or other application prerequisites | Required fields and application data have usable consumers and declared boundaries; presentation and live behavior remain separately implemented. |
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 content, Category, menu, module, language, access, media, extension, and route relationships it is expected to exercise. Include original values, the intended representation, agreed exclusions, and a reviewer. For restricted content, prepare evidence for the object itself and its alternate routes, not only the visibility of a navigation link. Later migrated proof and launch decisions belong to validation.
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? | Dated, protected actual Source recovery evidence exists, with method, coverage, limits, recovery owner and external-storage notes. For a Joomla Source with suitable access, this includes immutable database and filesystem backups. Required gaps are resolved, explicitly excluded by agreement or held. |
| 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? | Required gaps are resolved, explicitly excluded by agreement, or held; accepted noncritical exceptions state their owner, decision date, boundary, and scope effect. |
| Can the intended Target use the agreed scope? | The Joomla build, access, compatible content/language/media/field consumers, site/application boundaries and implementation owners are confirmed for required relationships. |
A missing cosmetic decision need not block readiness if its boundary, impact, and owner are accepted. Missing source access, incomplete recovery evidence, unknown extension ownership, untraceable restricted content, or undefined custom data should block the affected scope. Resolve the required gap or agree an explicit exclusion before proceeding; an owner and decision date alone are insufficient.
The final preparation decision requires both adequate actual Source evidence and a usable intended Joomla implementation. Hold a required menu, restricted-object access, translation, media or extension dependency that lacks a destination consumer, just as you would hold missing Source evidence. Resolve it or agree its explicit exclusion before execution. Later validation must test the resulting routes, audience and behavior.
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.
Carry the evidence package, intended Target decisions and any held scope into Joomla Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first for a Joomla migration?
Identify the actual Source CMS and intended Joomla environment. Secure source content, identity, route, media, and recovery evidence, then record versions and owners before cleanup. When Joomla is the Source, include administration and applicable hosting/database/filesystem/external-storage access; separately confirm the destination build and required extensions.
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 supported associations for Articles, Categories, menu items, and relevant component records. Record module language, access, menu assignment, and translated content separately. Include language-specific home items and routes, and distinguish shared content, 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.
Do Joomla modules have multilingual associations like Articles?
Modules need language assignments and translated content, but they are not core multilingual-association items like Articles and menu items. Record their language, menu assignment, access, position, and consuming route separately. A third-party component may implement its own association support; verify that owner rather than infer it from translated module titles.
Does hiding a menu item prepare restricted content safely?
No. A hidden or restricted navigation link does not establish the viewing access of its destination object or surrounding modules. Prepare the object-level access, relevant groups, action permissions, and alternate routes, then document the intended destination treatment. Restricted content with an unexplained audience or route should hold the affected scope.