For a move into Joomla, identify who owns the required content, commerce or membership records. Then define the access, permissions and route relationships the result must preserve. The platform name alone does not establish Next-Cart coverage.
Start with the supported DataTypes and fields for the exact Source-to-Target path. Joomla core ownership does not establish coverage for every article, category, menu, user, media item or access rule.
The selected commerce component has its own Products, Customers, Orders and dependencies. Next-Cart lists Joomla as a KitConnect-connected Source and Target selection, while its documented Joomla commerce-data modules include VirtueMart, J2Store and EShop. Confirm the actual component and selected Source-to-Target path before treating a connected site as covered for Products, Customers or Orders.
Select the approach on two axes:
- Scope: supported records and eligible enhancements, or requirements needing tailored handling.
- Execution: customer-led actions or agreed expert execution.
Two projects with identical Article counts can still differ substantially in access rules, language associations, commerce relationships and implementation work. Compare Next-Cart Migration Services by those axes rather than site size.
The customer supplies business meaning, retains manual access and verifies the result under every Migration Service. Agree separate target implementation and acceptance owners before execution.
Start With Joomla Scope Ownership
Classify core records, extension data, site configuration, custom components and integrations by their source owner and intended target use. The table below separates migration coverage from implementation work.
Do not infer relationships from matching labels or counts:
- Viewing: access levels and user groups determine who can see an item.
- Actions: permissions determine what a user may do.
- Routes: menu and component context matters alongside the article alias.
- Languages: associations connect corresponding items; matching translation counts do not.
Prove these outcomes through supported migration, target setup or agreed tailored handling as applicable.
| Scope area | Typical owner | Approach implication |
|---|---|---|
| Articles, categories, menus, users, media, tags, custom fields | Joomla core | Confirm supported DataTypes and fields individually; Joomla core ownership alone does not establish migration coverage. |
| Modules, template assignments, overrides, layout dependencies | Joomla configuration and presentation layer | Assign target setup or manual rebuilding separately; review Custom Migration for tailored data behavior and Managed Migration for agreed supported actions needing expert execution. |
| Commerce products, customers, orders, coupons, tax, shipping, payment, stock | Commerce extension or custom component | Requires extension-specific scope review; unsupported records may need Custom Migration. |
| Forms, directories, downloads, memberships, galleries, SEO/routing tools | Extension-owned systems | Include only when supported or intentionally scoped for Custom Migration. |
| Custom tables, custom components, outside IDs, bespoke business rules | Custom implementation | Check supported field or eligible database mapping first. Use Custom Migration when required extraction, relationships or rules exceed that behavior. |
This classification prevents the approach from becoming either too light or unnecessarily heavy. Not every Joomla migration needs Custom Migration, but extension-owned or custom implementation data should never be hidden inside a generic content scope.
Match Joomla Scope to the Service Path
Joomla complexity should not be translated directly into a more intensive service path. First distinguish supported core records, execution burden, bounded mapping or filtering needs, and extension-owned or custom data that requires tailored handling.
| Scope or execution choice | Best fit for a Joomla migration | Joomla-specific boundary |
|---|---|---|
| Standard Migration | Confirmed supported records with clean structure and customer-led execution and final verification | The customer confirms content, menus, users, media, metadata, and target behavior. |
| Managed Migration | Supported scope whose agreed Migration Actions need expert execution, with customer verification | Expert handling does not expand data coverage or include general project management and target implementation automatically. |
| Add-ons | A bounded supported need involving a data type condition, a field-value expression, or a compatible target destination for a supported source field | The request fits Data Filter, Data Transformation, Advanced Data Mapping, or eligible Advanced Database Mapping and remains within supported behavior. |
| Custom Migration | Custom components, extension tables, bespoke relationships, page-builder data, external identifiers, or other non-standard records requiring tailored extraction or transformation | Target extension installation, theme work, live integration deployment, and operational configuration remain separate unless expressly included. |
A large Joomla site can fit Standard Migration or Managed Migration when its required records and relationships are supported. A small site may need tailored handling when a critical component, table, route or external reference exceeds that coverage. Storage location and record volume alone do not decide the service.
When Standard Migration May Be Enough
The Standard Migration service is intended for customer-led execution of the supported path. It does not turn an unqualified Joomla extension table into a supported record.
Standard Migration may fit when:
- Required records and fields are explicitly supported and their meaning is clear.
- The customer can prepare, execute and verify the migration.
- Separate owners cover any target configuration or implementation.
Check each article, category, account, media reference, alias or other field by its covered migration role. Menus, access, modules and extension behavior are not automatically ordinary transferred records.
| Standard Migration readiness signal | Why it matters for Joomla |
|---|---|
| Core content records are organized and current. | Articles, categories, menus, and media can be reviewed without heavy cleanup. |
| Menus and URLs are understandable. | Route and SEO validation can be performed with clear examples. |
| Users and access levels are simple. | Identity and visibility behavior are easier to confirm. |
| Multilingual structure is limited or well documented. | Language-specific pages and menus can be validated without custom interpretation. |
| Extension-owned records are confirmed supported or deliberately outside scope. | The required project remains within confirmed supported behavior; core ownership alone does not prove coverage. |
| The merchant can review Demo Migration samples. | Customer-led validation is realistic. |
Standard Migration should not be chosen simply because the site looks small. A small Joomla site can still require deeper handling if it depends on a page builder, membership extension, custom component, restricted content rules, custom routing, or a commerce extension with unsupported records.
When Managed Migration Fits the Execution Need
Managed Migration may fit when the Joomla scope is supported but experts should perform the agreed setup, Migration Actions and migration-result checking. That service choice does not independently extend supported data coverage. Relationships among content, routes, users and extensions can increase the execution workload, while customer owners define acceptance and coordinate target setup. Expert execution does not automatically include Joomla implementation or wider launch management.
| Managed Migration signal | Joomla scenario |
|---|---|
| Many relationships need coordinated review. | Articles, menus, modules, users, access levels, and media must be checked together. |
| Stakeholders lack migration bandwidth. | Experts perform agreed Migration Actions while named customer owners remain available for sample review and final verification. |
| URL and SEO continuity are business-sensitive. | High-value routes, redirects, aliases, menu metadata, and language URLs need structured review. |
| Multilingual structure is active. | Language-specific menus, modules, associations, and defaults need careful validation. |
| Joomla is connected to commerce or membership behavior. | Core CMS and extension-owned records must be reviewed without mixing responsibilities. |
| Launch timing requires additional migration activity. | New records may appear after the first run and need controlled revalidation. |
Managed Migration supplies expert execution within the same supported capability as Standard Migration. The customer retains manual access, business approval and final verification. Unsupported extension data needs Custom Migration review, which can use Self-Execute or Expert Handle. Name any additional coordination or implementation responsibility explicitly.
When Add-ons Are the Right Support
Standard Add-ons address bounded supported operations:
- Filter a DataType through available field-based conditions.
- Transform supported field values through expressions.
- Route eligible source or transformed values to compatible destinations without changing them during mapping.
The exact migration path and available fields determine eligibility.
| Add-on need | Joomla example | Boundary condition |
|---|---|---|
| Data Filter | Apply conditions to a supported migration DataType and its available fields; Joomla record ownership alone does not make it filterable. | Filtering should not remove records needed for routes, access, SEO, or extension relationships. |
| Data Transformation | Apply expressions to transform supported Joomla-bound field values during migration. | The expression and expected value must remain within supported capability. |
| Advanced Data Mapping | Route an eligible source or already transformed value unchanged to a compatible supported Joomla destination. | Mapping must preserve meaning and stay within supported field behavior; the Tax DataType is excluded. |
| Advanced Database Mapping | Route an eligible source or already transformed value unchanged to a supported compatible Joomla database destination. | Joomla supports the Add-on as Target. The exact Source setup and eligible data type, table, field, column and Value Type must also be supported and compatible; the Tax DataType is excluded. |
| Bounded special handling | Identify an actual supported filtering, transformation or mapping operation; generic special handling is not an additional Standard Add-on. | Use Custom Migration when required records or handling exceed confirmed support and eligible Add-ons. Extension ownership alone is not a Custom trigger. |
A supported content-field filter may fit Data Filter. Unsupported membership rules do not become eligible because their data lives in Joomla. Use the Add-ons comparison to distinguish the bounded capabilities; confirm data storage and relationship configuration separately.
When selected together, Standard Add-ons run in this order:
- Data Filter: selects records.
- Data Transformation: changes supported values.
- Advanced Data Mapping: routes eligible source or transformed values unchanged to compatible target fields.
- Advanced Database Mapping: applies eligible database-level routing after Source, Target and schema qualification.
Combining supported Add-ons does not itself require Custom Migration. The Tax DataType is excluded from both mapping Add-ons. The current Add-on compatibility reference lists Joomla as a Target for all four Add-ons, but Advanced Database Mapping remains conditional on exact Source setup, Target role and supported schema and value types.
When Custom Migration Should Be Considered
Use the Custom Migration service to assess a required Joomla result that exceeds supported behavior and eligible Add-ons. An unfamiliar extension field alone does not establish that need. Examples include:
- Unsupported component or extension records and relationships.
- Custom extraction, bespoke transformation or migration-logic adjustment.
- Custom tables or outside-system identifiers whose required handling has no compatible supported path.
Long-lived Joomla customizations warrant review, not automatic escalation.
| Custom Migration trigger | Why it changes the approach |
|---|---|
| Custom components or custom database tables | Check the exact schema and eligible mapping first; tailored extraction or relationships need Custom scope when supported handling is insufficient. |
| Extension-owned records outside standard coverage | Records may require custom extraction, interpretation, or mapping. |
| Page-builder or layout data that must remain editable | The output may be presentation logic rather than normal article content. |
| Membership, booking, form, event, or directory records | Confirm the actual extension and covered records. Tailored scope is needed only for required handling beyond support and eligible Add-ons. |
| Commerce component data outside supported scope | Products, customers, orders, payment/shipping logic, or custom fields may require extension-specific review. |
| External IDs and integrations | ERP, CRM, accounting, access-system or reporting IDs need tailored preservation only when compatible supported mapping cannot preserve the required meaning. |
| Custom routing or SEO rules | URLs may depend on plugins, overrides, or custom SEF behavior. |
Scope tailored work through relevant examples:
- A custom component or extension-owned record and its source owner.
- A user or Customer relationship and any custom field meaning.
- A route and the expected usable target result.
Include exceptions. Each example should connect source meaning, handling rule and acceptance evidence; vague requirements cannot be estimated or validated reliably.
Custom Migration can use Self-Execute or Expert Handle for agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the included file workflow covers Products only. Other DataTypes need explicit agreement.
That selection differs from a supported platform’s File Upload connection method. A Product export alone does not establish the complete Joomla scope.
How Demo Migration Should Guide the Approach
Use Demo Migration to inspect available standard samples and expose gaps in the proposed Joomla approach.
- Unavailable in Demo: Add-ons, Customization, Reviews and Coupons.
- Paid-scope proof: agreed enhanced or tailored data output.
- Target implementation proof: routes, access enforcement, modules, extension behavior and live operations beyond the standard sample.
The contexts below identify decisions to investigate; they do not promise that every record type is available in Demo.
| Context to assess | Decision it should support |
|---|---|
| Standard article with media and metadata | Checks available supported content fields; required media or metadata outside the sample needs separate proof. |
| Menu-linked page | Checks available supported fields; menu and component route behavior requires separately assigned target proof. |
| Restricted content example | Identifies needed group, viewing-access and action-permission outcomes; prove target enforcement separately. |
| Multilingual page | Checks available language fields and identifies separate menu/association acceptance. |
| Module-dependent page | Identify content depending on modules; assign setup and output proof to the target implementation owner. |
| Extension-owned record | Confirm record coverage for the actual path, then decide whether it is supported, excluded, rebuilt or custom-scoped; sample presence alone is insufficient. |
| Commerce example | Identifies commerce ownership; resolve the extension’s actual covered records and prove target routes separately. |
| Custom field or outside ID | Identify an eligible compatible field destination or database operation, verifying exact Source setup and schema/Value Type support. Demo cannot run either Add-on; prove the agreed output in the paid migration. Use Custom Migration when required handling exceeds those limits. |
A populated standard sample can reveal relationship gaps without proving the full Joomla result. Assign routes, access enforcement, modules and language associations to their target owners. Use paid-scope proof for eligible Add-on or custom output. A gap should change the specific scope or ownership decision rather than cause blind continuation.
Entity Points and Joomla Scope Planning
Entity Points measure eligible migration capacity, not Joomla complexity or record support. Classify a record by its covered Product, Customer, Order or Blog Post role. CMS Pages and other supporting data do not independently consume Entity Points.
Eligible records consume Entity Points after their first successful migration within the same purchased, fixed Source-to-Target path. Already counted records are not counted again merely because the action changes or a related table is used. Target-state effects and structural complexity remain separate decisions.
| Planning question | Why it matters |
|---|---|
| Which eligible records are new to the purchased migration? | Newly eligible records may consume Entity Points. |
| Which records were already recorded previously? | They should not consume Entity Points again only because another action occurs on the same path. |
| Does the target result need to be continued or replaced? | The operational action affects validation scope, not only Entity Points planning. |
| Are Joomla records standard, extension-owned, or custom? | Entity Points planning does not prove supportability. |
Size eligible records only after confirming their supported migration roles; an Entity Points estimate cannot resolve an unsupported component or missing target implementation.
Migration Actions and Launch Timing
Joomla can change between runs:
- Publishing: articles, media, menu items and redirects.
- Accounts and applications: users, form submissions and custom records.
- Commerce: Products and Orders.
Choose the later action from the actual changes and the earlier target result that must be retained or replaced.
| Current action | Use it when | Joomla revalidation focus |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid; choose the source-data window independently. | Recheck affected content, users, Products, Orders, media and routes, including earlier relationships changed by the later run. |
| Continue the Migration with a New Configuration | Mapping, filtering, field handling, or supported configuration needs to change. | Revalidate every affected article field, menu relationship, access rule, language association, commerce record, and custom-field destination. |
| Perform a New Migration | Run the first paid migration or create a distinct result on the fixed purchased path; agree the intended target effect. | Recheck the full representative sample, including menus, aliases, access, multilingual structure, extension boundaries, URLs, and commerce records. |
Extension-owned data that continues changing should still be evaluated for supportability. Migration Actions do not convert unsupported extension records into supported records and do not replace Custom Migration when the project needs custom extraction, bespoke transformation, or custom migration logic.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose later-run data handling separately from the Migration Action. The Additional Option Continue the previous migration carries the most recent migration state into the next pass. For selected supported data types, records not represented as transferred in that state form the new-data delta, and supported relationships can use the carried context. The delta is not defined solely by when a source record was created.
Reusing configuration does not establish newly-added-only processing. Edited source records and earlier records processed again need explicitly supported handling; the option does not provide general synchronization of edits. Keep this state decision separate from interruption recovery, compare earlier and later output together and protect accepted target-side changes. An action name does not authorize broader clearing or deletion. The Additional Options reference explains the carried-state dependency.
Signals That the Joomla Approach Is Too Light
A Joomla approach is too light when it treats relationship-sensitive data as ordinary content. The issue may not appear in counts. It appears when the target contains records but cannot reproduce page meaning, route behavior, access restrictions, extension records, or business workflows.
| Warning signal | Likely response |
|---|---|
| Menus and aliases are not included in preparation or validation. | Strengthen scope before Full Migration. |
| User groups and access levels are assumed to be ordinary account fields. | Add restricted-content samples and permission checks. |
| Multilingual content is reviewed only by article count. | Validate language-specific menus, modules, associations, and defaults. |
| Extension-owned records are listed without supported-scope confirmation. | Confirm actual coverage, then use eligible Add-ons, agreed Custom Migration, exclusion or separate rebuilding as needed. |
| Custom components or custom tables contain business-critical data. | Check compatible supported handling and eligible mapping first; review Custom Migration for the remaining unsupported requirement. |
| Demo Migration samples include only easy content records. | Add available standard samples; assign route, access, module, language, extension and custom contexts to separate target or paid proof where needed. |
| The team cannot state what a later migration action should change. | Define continuation or new migration expectations before launch. |
These warning signs should be resolved before Full Migration. Otherwise, the target may look populated but remain unreliable for real publishing, access control, commerce, or operational use.
Choosing the Practical Joomla Path
Use the Migration Services overview to compare Standard Migration, Managed Migration and Custom Migration after the Joomla scope is clear. Supported Add-ons refine eligible data; Custom Migration supplies tailored handling with Self-Execute or Expert Handle.
Assign viewing access, action permissions, routing and live extension behavior to explicit acceptance owners. Service selection alone does not supply target implementation.
A Joomla approach is ready when the merchant can state:
- which Joomla-bound DataTypes and fields are confirmed supported and expected to migrate;
- which extension-owned records are in scope or out of scope;
- which target-side settings, templates, modules, menus, access rules, or extensions must be configured separately;
- whether Add-ons or Custom Migration are needed;
- what available standard Demo samples can show, and what requires paid or target-side proof;
- how later migration activity will be handled before launch.
Conclusion
Protect content meaning, access intent and route context, with commerce or membership ownership resolved separately:
- Supported scope: Standard Migration for customer-led execution, or Managed Migration for expert execution of agreed actions within that capability.
- Bounded enhancements: eligible Standard Add-ons.
- Tailored requirements: Custom Migration with Self-Execute or Expert Handle.
Use limited standard Demo evidence to identify gaps, agreed paid proof for enhancements or customization, and target checks for viewing access, action permissions, menus, language associations and live extensions. For later runs, choose the action and source-data window independently and check affected earlier and later output together.
Common Questions
What evidence should be prepared for Custom Migration review in a Joomla migration?
Prepare Joomla examples from custom components, extension-owned tables, and builder or layout data that must remain usable after migration. Trace each example to its public or administrative use, intended target representation, and the evidence required to accept the Custom Migration result.
When should Managed Migration be considered for Joomla?
Managed Migration fits confirmed supported Joomla scope when experts should perform the agreed Migration Actions. The customer defines content, route and access expectations, coordinates business approvals and verifies the result. Wider project coordination, launch management or extension setup must be included expressly if needed.
How are Add-ons different from Custom Migration in Joomla migration?
Standard Add-ons filter records, transform supported values or route eligible values to compatible fields or database destinations. Confirm exact Source setup, Target eligibility and schema compatibility for Advanced Database Mapping.
Custom Migration applies when required extraction, interpretation, relationships, transformation or migration logic exceeds supported behavior. A custom field, table or external identifier alone does not establish that need. Extension-owned data still requires explicit coverage review.
What should Demo Migration prove for Joomla?
Demo can inspect available standard records and expose gaps in the proposed Joomla representation. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Routes, access enforcement, modules, commerce extensions and language associations need paid or target-side proof where they exceed the standard sample.
Does a migrated Joomla user group prove viewing access and editing permissions?
No. Viewing access determines which items a user can see; permissions determine which actions the user can perform. Match the intended group relationships, visibility and allowed actions separately in the target. A copied label or stored value does not prove that the website enforces the required rules.
Does the Joomla Target automatically include every commerce extension?
No. Joomla core ownership and a generic Target identity do not establish coverage for extension-owned Products, Customers, Orders or custom tables. Resolve the actual commerce environment and supported records separately. Use agreed tailored scope where needed and assign live extension implementation explicitly.