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.
A usable Joomla page may depend on Categories, menus, modules, access levels, languages, media, templates, plugins, components and routes. A stored content record can still be:
- Unreachable through its intended route.
- Hidden from the intended audience or assigned to the wrong language.
- Dependent on an extension absent from the destination.
The readiness evidence must cover those relationships as well as the records themselves.
Use the actual Source’s records and identifiers to explain the intended Joomla result. Record missing or different Source structures explicitly instead of inventing Joomla evidence.
Each major task needs:
- An accountable owner.
- A dated evidence artifact.
- A ready condition.
Preparation separates Joomla core, extension and external ownership and identifies useful test records. It does not require the complete target design in advance.
Source access, evidence and recovery
Identify the actual Source and intended Joomla environment separately.
- Joomla Source: confirm administration, hosting, database, filesystem, media, DNS and external storage/delivery access with their owners.
- Another Source: collect its available content, identity, route and application evidence; retain its original keys.
- Joomla Target: confirm the build, compatible required extensions, template, languages, roles and implementation owners.
Record Source versions. Access and recovery methods must support inspection of the required records within their documented limits.
| 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.
Protect the actual Source evidence before cleanup:
- Joomla with suitable access: retain complete database and filesystem backups.
- Another Source: retain available exports, files or platform-managed recovery evidence, with explicit recovery limits.
Record the date, scope, protected location, access controls and recovery owner. Verify the covered recovery method independently of the live site.
External storage, CDN rewriting and remote references need their own evidence; a local archive may omit required assets. Resolve a required gap, agree an explicit exclusion or hold the affected scope.
Inventory Articles, Categories, Menus, Modules, and Routes
Joomla Categories organize content; menu items define routes and page context; modules supply surrounding output; viewing access controls its audience. Use actual Source equivalents in the table below to plan those Joomla relationships.
| Content relationship | Preparation evidence | Ready condition |
|---|---|---|
| Article to Category | Actual Source content and classification evidence with original IDs, aliases, language, status and access where available; document absent structures | Every in-scope Joomla Article has an agreed Category, including Uncategorised where intended; source classification or its absence is documented. |
| 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. |
Record the actual menu destination:
- Content views: a single Article, Category Blog or tagged-items view.
- Other destinations: a contact, custom component or external URL.
Module assignment is separate: the same Article can appear in different menu contexts with different supporting modules. An Article transfer alone does not recreate the page.
Prioritize URLs used for:
- Organic traffic, backlinks or campaigns.
- Legal information or account access.
- Frequent customer tasks.
In the URL and redirect plan, record each priority path’s current owner, destination intent and language. Decide whether it stays direct, redirects once or is retired.
Prepare Users, Groups, Access Levels, and Permissions
Prepare the actual Source rules and intended Joomla access model separately:
- Identity and groups: users, multi-group membership and hierarchy.
- Viewing: the intended audience for each restricted object.
- Actions: what each role may do, including explicit and inherited decisions at the relevant scope.
Retain representative users and content. A group label alone proves neither audience nor authority.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Classify user populations | Actual Source administrator and business owner; Target Joomla access 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 | Actual Source user-to-group and hierarchy evidence where present; intended Joomla representation and any gaps | 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. |
Retain extension profiles’ actual Source keys and each applicable account or intended Joomla user relationship. Commerce, membership, learning, directory or community components own business state such as:
- Membership status and subscription history.
- Course progress and vendor data.
- Customer records.
Do not flatten that meaning into generic user metadata. Plan password-verification continuity for the exact Source-to-Target path, or the required reset, activation or first-login outcome, with identity-provider and communication owners.
Prepare Multilingual Content and Language Associations
Prepare two multilingual evidence sets:
- Associations: language assignments and supported counterpart links for Articles, Categories, menu items, contacts and other supported component records.
- Modules: language, access, menu assignment and translated content.
Modules are not core association items. Third-party components need their own supported association model and owner.
Capture:
- Language setup: enabled content languages, tags and default language.
- Counterparts: associated Articles, Categories and menu items.
- Menu paths: language-specific home items and language-switcher configuration.
Identify all-language records 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 menu paths | Menus, home items, menu aliases, and module assignments by language | Each language has a defined primary menu 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
Extensions can own several kinds of data:
- Content, tags, downloads and redirects.
- Transactions, profiles, bookings, memberships, events and directories.
- Forms and integrations.
Name the owner of each business-critical dataset. Templates and overrides may change rendering without owning the underlying records.
| 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. |
Prepare representative records and a relationship map for each required extension dataset. Examples include:
- Forms: reusable definitions, submissions, files, notifications and CRM delivery state.
- Directories: listings, owners, Categories, locations, claims and reviews.
- Custom fields: compatible definitions, permitted values, context, access and the active template/plugin consumer.
These records are not interchangeable generic fields. Stored values alone do not prove that the intended destination can use them.
Prepare Media, Files, and Embedded References
A media copy needs record-level reference evidence. Files may belong to Article HTML, custom fields, modules, templates, galleries, download extensions, remote storage or third-party builders.
Use a media register with three parts:
- Asset class: local image, document, audio/video, generated thumbnail, remote asset or extension-managed upload.
- File evidence: path, filename, MIME type, size and owning record where known.
- Reference location: Article content, custom field, metadata, module or extension table.
Flag reference differences before cleanup:
- Absolute URLs and relative paths.
- Encoded filenames and case-sensitive path differences.
- Duplicate files and broken references.
Record references before renaming or deduplicating files. Keep a source-to-cleaned path ledger for any approved cleanup.
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
Separate application domains where used:
-
Commerce
Identify the actual installed component. VirtueMart, J2Store and EShop are examples of distinct Joomla commerce implementations; confirm each actual component and required record type against the selected migration path.
-
Other applications: membership, LMS, booking, event, directory or custom data.
Identify their Joomla dependencies without absorbing the applications’ 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 needs compatible consumers for the agreed content, access and language relationships. Check the current supported Joomla release, runtime requirements, and compatibility of each required commerce or business extension as one target readiness decision, not as independent inventory entries. An Article export does not create menu context, modules or extension behavior. Confirm the required build and owners without treating preparation as completed site design.
Use the Joomla migration approach to resolve actual record coverage, and confirm the direction on the Joomla migration page. Commerce and other application transactions retain their own scope; hosting an extension does not make its Orders Joomla core content.
| 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.
Choose patterns relevant to the agreed scope:
- Content and routes: an Article reached through a single-Article item; another through a Category Blog or List view; a priority legacy URL or redirect.
- Languages: an Article family with its associated menu items.
- Access: restricted content and a multi-group user whose access meaning matters.
- Page assembly: module-dependent output and content with custom fields and embedded media.
- Applications: a record from a major extension or custom component.
For each sample, record applicable content, Category, menu, module, language, access, media, extension and route relationships. Include original values, intended representation, agreed exclusions and a reviewer.
For restricted content, retain evidence for the object and alternate routes, not just menu visibility. Later validation owns migrated proof and launch decisions.
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 protected, unaltered database and filesystem backup copies. 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. |
Accept a missing cosmetic decision only when its noncritical impact, boundary and owner are agreed.
Required gaps in Source access, recovery, extension ownership, restricted-content traceability or custom data hold the affected scope. Resolve them or record an agreed exclusion in the migration scope. 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 held scope into Joomla validation. Preparation defines what must be tested; migrated proof and acceptance belong to that 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?
Collect available Source users, group membership, hierarchy, viewing access and important permissions through exports or other evidence. Record missing structures and define their intended Joomla representation separately.
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 a 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 menu 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.