CMigrator - Joomla Extension

A Practical Guide to CMigrator: Moving WordPress or Drupal Content to Joomla Without Losing Control of Your Data

CMigrator is best viewed not as a button that instantly replaces one CMS with another, but as a temporary tool for moving content into a prepared Joomla environment. This guide takes that practical approach: separating data migration from design work, preparing a safe copy, building a CMigrator configuration, running a test import, and validating the output before visitors ever see the new site.

The product has historical context that should not be glossed over. The original CompoJoom page was unavailable when this material was prepared, and the available guides and discussions mostly relate to earlier generations of Joomla. For that reason, the screen names and individual capabilities mentioned below are based on preserved documentation and should be checked against the exact extension archive already held by the site owner. A separate test environment is especially important for modern Joomla: do not install CMigrator directly on a live project or promise a client automatic compatibility without testing it first.

This guide does not cover purchasing, registration, or license circumvention. Instead, it gives you a repeatable workflow: backups, a separate Joomla installation, source tables, migration configuration, data selection, image and link validation, repeat imports when the old site changes, and clear troubleshooting. This sequence is useful for both WordPress and Drupal, although the most thoroughly documented workflow applies to WordPress.

What CMigrator Actually Migrates and Where Its Responsibility Ends

Based on the extension listing in the K2 directory and the developer's webinar recording, CMigrator is intended to move categories, posts, pages, and users from WordPress or Drupal into Joomla or K2. The descriptions also mention image importing, nested category structures, tag importing when using K2, and the removal or replacement of incompatible WordPress tags. This is an important but limited job: the extension handles data and its conversion, not the transformation of a WordPress theme into a Joomla template.

It is most useful to think of a migration as four separate layers. The first is source data: posts, pages, categories, users, metadata, media links, and possibly comments. The second is the CMigrator rule set: which entities to read, which Joomla or K2 entities to create, whether to clean the destination, which table prefix to use, and where to resolve relative image paths. The third is the Joomla site itself: categories, articles, user accounts, access permissions, menus, and files. The fourth includes everything that should not be assumed to migrate automatically: the theme, layouts, widgets or modules, forms, external integrations, extension settings, caching rules, and all behavior that existed in the old site's code.

Keeping these layers separate prevents the most common disappointment after any migration. If articles appear in Joomla but the page looks different, that does not mean the import "failed." Joomla output is controlled by the template, menu item, module positions, category settings, and permissions, while a WordPress theme has no direct equivalent. If some content opens but the old friendly URLs do not work, the issue is usually not the article itself but the new routing setup and the absence of redirects.

What You Can Realistically Expect

For a standard editorial site, a sensible goal for the first run is to get readable categories and articles in Joomla, see the expected post count, verify authors where they are migrated, and confirm that basic images are available at their new locations. If you choose K2, also verify that items land in the expected K2 structure and that categories have not become a flat list. A successful first run does not mean the site is ready to launch. It only proves that the source can be read and that the basic mapping works.

You should not promise that every custom data type will migrate automatically. Content created with a page builder, third-party plugin fields, an ecommerce store, forum, membership system, specialized gallery, or custom code may be stored outside standard tables and may not have a destination in a normal Joomla article. For these elements, use CMigrator as a foundation for content, then evaluate each separate entity before launch: either it has a documented import path, or it needs to be migrated with another tool or rebuilt.

The WordPress Multiple-Category Limitation

The preserved CMigrator instructions point out an important model difference: WordPress allows a post to belong to multiple categories, while a standard Joomla article is associated with one category. In the documented workflow, only the first WordPress category is retained during migration. Do not bury that fact at the end of the project. Before importing, export a list of posts assigned to multiple categories and decide which category will be primary for each one, and where tags, related-content blocks, or separate menu items would work better. Otherwise, the category tree may appear to survive the migration while part of the site's navigation model quietly disappears.

When You Need K2 and When Joomla Articles Are Enough

The historical CMigrator listing mentions imports into K2 and tags only for K2. That does not mean K2 should be installed on every new site. Decide on the destination before configuration: if the future project will use Joomla's built-in articles, test migration into those; if the existing architecture genuinely uses K2 along with its views, fields, and categories, test K2 on a separate copy. You cannot migrate part of the project into standard content and then expect those articles to automatically acquire a K2 structure later.

Practical rule of thumb: CMigrator migrates data as raw material for a new site. Treat design, modules, menus, redirects, extensions, and business processes as separate tasks until testing proves otherwise.

Who This Workflow Is For and When a Different Strategy Is Better

CMigrator makes sense when you have access to the source WordPress or Drupal database, the new Joomla project has already been deployed separately, and the main task is moving an editorial content set: sections, articles, pages, basic author information, and images. It is particularly useful for a site where preserving publication history and section structure matters more than reproducing the old template pixel for pixel. This approach also works well when the team is ready to accept the import output, manually review edge-case content, and build a new Joomla interface afterward.

The tool is less suitable for a request like, "Build the same site on another CMS by tomorrow." If the source project relies on custom post types, complex access rules, payment flows, page-builder fields, multilingual relationships, custom tables, or dozens of integrations, a content import alone is not enough. In that situation, first create a map of data and dependencies, then choose a toolset or a custom development approach. Automated importing does not replace designing a new architecture.

There is another reason to be cautious: the package's current status. The available confirmed material refers to a historical interface, and an independent Joomla community discussion suggests that CMigrator may not have continued development after older Joomla generations. Version and compatibility information found in third-party directories is not an equivalent substitute for a current statement from the developer. For Joomla, PHP, and database environments that differ from the old project's setup, make a decision only after installing the package on a copy and running a short import with cleaning disabled.

Signs You Need an Audit or an Alternative Migration Instead of CMigrator

• No access to the source database. The documented CMigrator workflow uses WordPress tables in a database available to the new Joomla installation, so a public site URL alone is not enough.
• The main value exists outside posts. For example, the source may be a product catalog, lead submissions, forum, bookings, private files, or complex profiles stored in custom tables.
• You cannot create a test environment. Running an import with the cleaning option enabled on the only live Joomla site creates an unjustified risk of data loss.
• You need zero downtime without a synchronization plan. New posts, comments, and users appear between a test import and launch. You need either a separate final delta migration or an editorial freeze period.
• Exact preservation of old URLs is required. URL mapping and redirects must be planned and tested separately; you cannot assume they will emerge from imported titles.

Do not confuse CMigrator with tools for upgrading Joomla within the same CMS family. If the task is moving from an older Joomla release to a newer Joomla release, a WordPress or Drupal migration is not the right workflow. Other solutions exist for Joomla-to-Joomla upgrades, such as MigrateMe 4, which is positioned as a separate path for moving Joomla 3 into an isolated Joomla 4 environment. That involves a different source format, different risks, and a different validation checklist.

Pre-Flight Checklist: What to Prepare Before Installing the Component

The main migration rule may sound boring, but it saves projects: a live site is not a laboratory. Prepare three independent assets: an immutable copy of the source WordPress or Drupal site, a test Joomla environment, and a decision log. The copy must include both the database and the files. A database alone does not contain the uploads directory, while files alone do not contain text, relationships, users, or categories. WordPress's official backup guidance explicitly separates the database from the files, and Joomla backup documentation likewise warns that a complete copy consists of both.

Your test Joomla installation does not need to look polished. At the beginning, it needs to be reproducible: a separate domain or subdomain, a separate database, a Super User account, a known PHP version, access to error logs, and a quick way to restore the initial state. If the team is working with a copy of an existing Joomla site, first confirm that email, payments, webhooks, and indexing bots cannot be affected. For a clean destination, it is safer to disable outgoing mail, protect the environment with basic access controls, and block indexing through the environment.

Inventory the Source Without Guessing

Do not begin by exporting everything indiscriminately. First record what actually exists on the source side. For WordPress, this means at least the number of posts, pages, published and draft items, categories, tags, users, images in the uploads directory, comments, custom post types, and active plugins. In a separate line, note posts with multiple categories, pages containing shortcodes, content built with page builders, externally hosted images, file links, and publications with non-ASCII URLs.

For Drupal, the list will be different: content types, taxonomy vocabularies, fields, views, roles, files, and modules. CMigrator claims Drupal support, but the available detailed instructions focus on WordPress. For that reason, treat all Drupal-specific entities as unverified until a demonstration import proves otherwise. Do not apply WordPress terminology to Drupal, or vice versa: sharing the word "category" does not prove that data is stored the same way or will produce the same output.

A Table Worth Completing Before Your First Import

This document is not a reporting exercise for a manager. It is a working tool for the person doing the migration. When 37 articles turn up without images after import, the log immediately shows whether they belonged to a particular directory, external domain, or type of editorial embed. When categories differ, you can investigate not an abstract "category import" but the specific rule used to select the first category.

Backups You Can Actually Return To

Create at least two restore points. The first should be made before changing anything on the source WordPress or Drupal site. The second should be made before running destination cleanup in CMigrator. For Joomla, use a backup method the team has already tested to create a complete copy, including both the database and files. Akeeba Backup's current documentation describes creating and restoring a complete Joomla backup, but choosing a tool matters less than validating the backup: you must be able to unpack it in a separate environment, or at minimum confirm that it is complete and accessible.

Do not store your only backup in the test site's directory. If cleanup, a permissions issue, or a faulty import affects the environment, the archive stored beside it may become inaccessible as well. Keep the copy outside the web root or in approved protected storage, record its timestamp and source, and provide access only to people who need it. Database passwords, SSH keys, third-party service keys, and configuration-file contents should not be included in CMigrator tasks or left in project materials.

Database Access and Table Prefixes

In the preserved practical guide, the process starts by exporting WordPress tables and importing them into the Joomla database. CMigrator then uses Database prefix to distinguish source tables from Joomla tables. This explains why the prefix cannot be guessed. In WordPress it often looks like wp_, but it may have been changed during installation. Official WordPress documentation recommends selecting tables with the actual table_prefix from wp-config.php when the database also contains tables from other applications.

Before allowing the component to access the data, make sure importing the source tables will not overwrite Joomla tables. In a test environment, it is safer to retain the source's original unique prefix and record that prefix in the log. Do not rename tables blindly after loading an SQL dump: the transformation may affect references or internal records. Even if both CMS platforms use the same database engine, that does not mean they use the same tables or the same identifier values.

Critical expected state: before installing CMigrator, you can identify the exact test domain, the location of the latest complete backup, the source table prefix, and the person who confirmed access to those resources. If even one answer is missing, postpone the run.

Installing CMigrator on a Test Joomla Site and Verifying the Component

Once you have obtained the CMigrator archive from a legitimate source, do not unpack it into the Joomla core or manually replace files. The standard Joomla extension installation path is to upload the archive through the Extension Manager. Historical interface versions may use different section names, and navigation has changed across current Joomla releases, so follow the extension installation area for your version rather than copying a label from an old screenshot word for word.

1. Sign in to the test administration panel with an account permitted to install components.
2. Open the system area for extension installation and select the CMigrator archive.
3. Wait for the successful installation message; do not refresh the page while the archive is being unpacked.
4. Confirm that CMigrator appears in the Components area and that opening it does not cause a server error.
5. Record the archive name and the version shown in the interface or package in the migration log.

If Joomla rejects a large archive upload, do not work around the issue by copying unknown files into system directories. Joomla documentation provides an alternative installation-from-folder method when upload limits apply, but the workflow depends on the environment and requires careful validation of paths and permissions. First identify the cause: upload size limits, temporary-directory permissions, a corrupted archive, an unsuitable PHP version, or an outdated package that is incompatible with the current Joomla release. Mechanically raising limits on a production server for a one-time import is usually worse than deploying an appropriate test environment.

What to Check Immediately After Installation

Open the component, but do not start a migration. In the available training material, the path begins with Components > CMigrator and then uses the CMigrator Configuration button. On the first page, make sure the component can open the configuration page and save an empty test record without an error. If the administration page does not open or displays obsolete-code warnings, that is already a compatibility test result: do not force the tool to run in a live environment.

Also confirm that the test Joomla site does not contain unneeded sample content, or that you know exactly how it will be protected. Later, the Clean Migration setting may remove selected existing destination data. The component cannot know which test items the team considers important. A preserved copy before each experiment matters more here than any checkbox.

CMigrator Configuration: Table Prefix, Source URL, and the Risky Cleanup Mode

CMigrator's strength is that it requires you to define the source-to-destination relationship explicitly. Its historical configuration screen uses at least a configuration name, table prefix, and source site base URL. You can then select the entities to migrate. The documentation shows this as CMigrator Configuration - Create new configuration - complete the fields - Save & Close. If your package uses a different sequence or different names, do not substitute assumptions for the fields: map them according to their purpose.

Use the Configuration Name as Part of the Log, Not a Decorative Label

In the Configuration name field, use a name that makes the planned action clear without relying on memory. A good option describes the date or stage, source, destination, and run type: wp-staging-content-no-clean. Poor choices include test, new, or a client name without context. A week later, you will need to know which configuration handled a trial import, which one ran without cleanup, and which one was intended only for the final migration.

One configuration should not simultaneously serve as an article test, a user migration, and a repeat synchronization before launch. Create separate records whenever the goal or risk changes. This makes settings easier to review and helps prevent rerunning an old profile with cleanup enabled. Before launching, take a screenshot of key fields and save it with the log, but do not include credentials in the screenshot if they appear in your build.

How to Set Database prefix Correctly

The Database prefix value refers to the imported source CMS tables, not the Joomla table prefix. If the source database contains wp_posts, wp_terms, and wp_users, the prefix will usually be wp_. If the hosting provider or installer used a custom name, it may look different. Use the actual table names and the source configuration. A one-character mistake produces a very recognizable symptom: the component cannot find the expected data, selects an empty set, or ends with an SQL error.

Do not try to solve the problem by adding another underscore, rearranging characters, or switching to the Joomla prefix. Stop and inspect the database map. In a safe environment, you can compare several expected tables: for WordPress, those include post, term, and user tables; Drupal has its own set. If they are not present, CMigrator cannot obtain the data, no matter how polished the configuration screen looks.

Why Base site URL Matters

In the preserved instructions, the Base site URL field is used to build image links inside imported articles. When post content contains relative paths, the component needs a base address to determine where the file is located. If no address is provided, the instructions warn that only images with absolute paths can be processed. This is not a minor cosmetic setting. An incorrect protocol, a staging domain instead of the live source, or an omitted installation directory can easily produce dozens of broken images after an apparently successful import.

Enter the address of the source copy that the test Joomla site can actually reach at the time of import. It does not have to be public, but it must expose the file structure that matches the imported tables. If the database was copied a week ago but images on the server have already been deleted or moved, the tables will contain links to files that no longer exist. Record how access will be verified: open several absolute and relative media links from the test environment, then inspect the final img elements in imported articles.

Selecting Entities and Keeping the First Run Small

The old instructions recommend leaving the default selections for categories, tags, user groups, and users. In practice, a narrower first run is more useful. If the project is large or your CMigrator version has not been tested in the current environment, begin with categories and a small sample of articles if the interface allows it. The goal of the first run is to prove the path from source tables to configuration to Joomla articles, not to move everything in one attempt.

Users require a separate decision. Even if the tool can import them, that does not mean roles, passwords, activation, and access permissions will automatically be correct in the new Joomla site. First determine whether historical authors are needed only as article bylines or whether users must actually sign in. In the second case, run a separate test with several anonymized accounts and do not send notifications until the new access policy has been approved.

Why Clean Migration Should Not Be Enabled by Default

The preserved practical instructions state directly that with Clean Migration selected, existing Joomla articles, categories, users, and tags may be removed if their corresponding types are included in the migration. That makes the mode useful only for a deliberately prepared clean destination that can be fully restored from a backup. It is not a "better" or "more complete" import.

For the first test, keep cleaning disabled. Confirm what is created, how items are named, how the counts compare, and whether any system content is affected. Before a controlled final import, either remove test output through a documented and understood method or restore a clean Joomla copy. Do not run cleanup over editors' work. If you need to bring in new articles from an active WordPress site, cleanup is especially dangerous: instead of importing a delta, you may destroy already verified new content.

Configuration summary: the correct prefix answers "what should be read," the base URL answers "where should media be found," selected entities answer "what should be migrated," and Clean Migration answers "what may be deleted." Before pressing the launch button, the team should be able to answer all four questions out loud.

How CMigrator Converts Content Structure: Categories, Articles, Tags, and Media

A migration rarely fails because of one major event. More often, it is shaped by small mismatches between data models. On the WordPress side, posts belong to categories and tags, may be pages or posts, and can contain shortcodes and relative URLs. On the Joomla side, there are categories, articles, menus, and display settings. CMigrator can move basic entities, but it does not eliminate the differences between them. That is why you need to validate not only the total article count but also the relationships.

The Category Tree and Its Connection to Articles

CMigrator's description claims that category relationships, including nested relationships, are preserved. You can and should test that claim on a real example with at least three levels, several neighboring branches, and articles at different levels. After import, open Joomla categories and compare their parent, alias, publication state, and article count. Then open one article from each branch being reviewed. A tree is not ready simply because names appear in the administrative list; the articles must actually be in the expected sections and usable in the new navigation.

The multiple-category issue in WordPress requires a separate decision. If a source article belonged to both "News" and "Analysis" but appears in only one Joomla category, do not automatically create a duplicate article. Duplicates make maintenance harder and can create two URLs with identical text. More often, teams select a primary category and represent the secondary connection with a tag, related-content module, or menu item that displays a collection. The correct approach depends on the future information architecture, not on the urge to retain every checkbox from the old CMS.

Articles, Pages, and HTML Inside Content

After a test run, do not select five attractive news posts with simple text. Use a representative sample instead: an article with headings and a table, a long article with images, an old post with nonstandard formatting, a page with several internal links, and a publication containing a WordPress shortcode. Open them in the Joomla editor and on the public side of the test site. Compare more than visible text: headings, lists, links, images, nested elements, videos, galleries, buttons, and unprocessed fragments all matter.

Outdated WordPress tags and shortcodes do not mean anything in Joomla on their own. The CMigrator webinar and a third-party tutorial mention removing or replacing incompatible WordPress tags through a parser. This is a reason to create a conversion list, not to assume every embed will look good automatically. If old content included a gallery code, table, form, or plugin button, the new site needs either an appropriate Joomla equivalent or manual article editing. After import, search content for recognizable markers from old embeds and process them in batches.

Tags: Do Not Confuse Labels with Menu Architecture

Tags are useful for cross-topic relationships, but they do not replace categories or build menus automatically. In CMigrator's historical description, tag importing is tied to K2, so with standard Joomla articles you should not assume tags will migrate without testing. If tags have editorial value, create a validation sample: a rare tag, a tag with Cyrillic characters or spaces, a tag attached to dozens of articles, and labels with similar names. Check whether duplicates appear because of case differences, transliteration, or old synonyms.

If tags exist only as a trace of the old CMS and no one uses them in the new navigation, do not migrate them by inertia. First agree on their purpose: search, related content, index pages, or internal editorial work. Migration should reduce technical debt, not carry every historical entity into Joomla without an owner.

Images and Absolute URL Validation

Media validation has two separate parts. The first is the link behavior inside an article: according to the training material, CMigrator uses Base site URL to resolve relative paths. The second is the physical availability of files. Even a correctly constructed URL is useless if the old server is closed, the uploads directory has been deleted, or request protection prevents the image from being retrieved. After importing, inspect network responses for several images and distinguish between a 404, 403, redirect, slow load, and substitution of a small thumbnail.

Do not start rewriting URLs throughout the Joomla database until you have identified the problem category. If only articles with relative links fail to load, inspect the base URL. If every image from a specific subdomain fails, inspect source access and the file directory itself. If images open but point to the old domain, decide whether temporary external loading is acceptable or whether legally available media needs to be copied into a new managed directory. Test large media libraries in small batches and monitor disk usage and execution time.

Comments as a Separate Integration

The CMigrator instructions state directly that WordPress comment migration is possible only with CompoJoom's CComment component installed. Do not turn that requirement into a promise for every package and version. If comments are valuable data, first confirm compatibility for your exact CMigrator, CComment, and Joomla versions using several test threads. Check authors, dates, nested replies, moderation, closed comments, and public display. Without that validation, mark comments in the plan as a separate non-automated scope of work.

Practical Example: Moving an Editorial WordPress Blog to a New Joomla Site

The repeatable example below is for a site with the sections "News," "How-To," and "Knowledge Base," nested categories, several authors, and images inside articles. It does not assume that the theme, forms, or store will migrate. The goal is to create a verifiable copy of editorial content in Joomla that can serve as the foundation for a new public-facing site.

Goal and Readiness Criteria

Before launching, define a measurable outcome. For example: Joomla contains all published articles from the selected period; the tree of three main sections is preserved; every test article has a title and body text; all ten reviewed images open; an internal link from each of five control articles does not lead to an error in the test environment; and editors have a list of exceptions. Do not use a criterion such as "it looks like everything migrated." It does not help you determine what needs to be fixed or whether it is safe to move on to design work.

Preparing the Source and Destination

1. Create a complete WordPress backup: the database and file directory, not just an XML export from the dashboard.
2. Record the actual source table prefix in the migration log.
3. Deploy a separate Joomla installation that does not need to serve visitors and create a backup restore point.
4. Import WordPress tables into a database available to the test Joomla site without allowing them to overlap with Joomla tables.
5. Verify that several files from the image directory are available at their actual URLs.
6. Create a sample of 20 control articles: simple and long pieces, content with images, multiple categories, external links, and old markup.

With this approach, the next step does not become a blind gamble. If the tables did not import, you will see that before CMigrator is involved. If the images are inaccessible, you will discover that before producing hundreds of broken links. If the sample includes one complex article, you can analyze it before the same issue appears across a thousand publications.

Creating a Configuration for the First Run

In the Joomla administration panel, go to CMigrator, open configuration, and create a new record through Create new configuration if your archive uses that label. In Configuration name, state the purpose of the run. In Database prefix, enter the actual prefix of the imported WordPress tables. In Base site URL, enter the test or source copy address where media files are available. Select only the entities needed to prove the workflow.

Do not enable Clean Migration on the first run. Save the configuration with Save & Close or its equivalent. Then return to the migration function, select the configuration you created, and read every parameter once again. This second review matters because administrators are often no longer looking at the configuration page at that point, but at the launch page, where it is easy to select a neighboring profile.

Launching and Monitoring the First Wave

Click Migrate only when the source and destination are known and you can monitor the execution window. Do not close the tab out of impatience or start another identical process in a neighboring window. If the server responds slowly, wait for the outcome first, then inspect Joomla logs and database state. Two simultaneous imports often create duplicates, partially processed data, and a poor foundation for troubleshooting.

After completion, do not move directly to template styling. Open the administrative list of categories, then articles, then the public page of the test site. Record the counts and any messages shown by the component. Compare all 20 articles in the preselected sample. Review connected elements: category, title, date, author, text, image, links, tags, and any unresolved shortcode. Assign each defect a class, such as media-relative-url, multi-category, shortcode, or author-mapping. This keeps fixes manageable.

What to Do When Articles Look Good Only in the Editor

An article may import correctly into Joomla but display incorrectly on the public site. Validate both sides. The editor may show the text and HTML, but the template, category settings, menu, cache, and access permissions affect what visitors see. If an article opens without its introductory image, first determine whether the image should be rendered by the template or is located inside the content. If a title appears twice, do not immediately remove it from the article: the template may be outputting a system title above the imported one. Fix the issue at the layer that created it.

A Separate Pass for Users

Once the content import has been proven, decide whether users are needed in the new Joomla site. If the only goal is to retain author names on old articles, a simpler model may be appropriate: create corresponding authors in a controlled way and assign them to articles after validation. If users must sign in, migration becomes an identity and security task: evaluate matching email addresses, roles, recovery methods, password policy, notifications, and personal data. Do not test with other people's real passwords, and do not declare password migration successful without a confirmed test using an anonymized account.

Common Pitfall: Multiple Categories and Choosing a Primary Section

In this example, one setup article belonged to both "How-To" and "Knowledge Base." Before importing, the team designated "Knowledge Base" as the primary category and decided to implement the second relationship through a topic collection in the new Joomla site. After the run, the article appeared in the expected primary category, and the editor added it to the collection. That outcome is better than duplicating the article and better than an arbitrary selection that might go unnoticed until launch.

Workflow validation: if you can repeat the import from a clean test copy and obtain the same result for the control sample, the process is under control. If the result depends on undocumented manual actions, document them as separate steps first.

Validating the Outcome: Count, Open, Compare, and Do Not Rely Only on a Success Message

A successful completion message means only that the process reached the end without a recorded critical error. It does not prove that every relationship is correct. Real validation works as a chain: compare counts, open a sample, verify relationships, inspect public output, review logs, and record exceptions. The earlier this chain is defined, the less tempting it becomes to overlook partial losses.

Comparing Counts and Sample Boundaries

Start by comparing the total number of categories and articles being migrated with the expected source count, taking into account drafts, system pages, and content types excluded in advance. A mismatch does not always mean there is a defect: status filters may differ, a particular type may not migrate, or some items may lack an eligible category. But every difference should have an explanation. Also check the newest and oldest publications, as well as posts with special characters in their titles.

After the overall count, move to the control sample. The sample should be repeatable: save a list of source IDs or URLs rather than selecting articles by eye. It should include the longest content, articles with many images, pages without a category, posts with multiple categories, old publications, links to internal documents, and articles with unusual markup. Edge cases are where you see the actual behavior of the conversion.

Checking Images, Links, and Unprocessed Markup

Open every test article on the public Joomla site and make sure images do not redirect to an unexpected login page, return an error, or point to a domain that will be disabled. An external image may be visible today but become unavailable after the old hosting is shut down. If the plan includes moving files, validate not only the thumbnail but also the original-size image and images embedded in the body content.

Check internal links in at least five articles from different categories. They may point to old WordPress URLs that still exist for now but will disappear after the domain switch. Do not rewrite every URL without a redirect map. First assemble a list of the most visited and important old URLs, map them to new destinations, then test the paths in the staging environment. If the content shows WordPress code fragments, widgets, unprocessed galleries, or empty blocks, add them to the manual adaptation queue.

Checking Permissions and Public Access

Open a set of pages while signed out, under a test account with a limited role, and as an administrator. Content may have been imported but hidden by category permissions, or it may be accessible where it should not be. Users and groups are especially important when they were migrated along with content. Do not rely on what an editor with Super User privileges can see: checking as a regular visitor often exposes the real issues.

The Exceptions Log as a Deliverable

At the end of validation, create a list that is not merely a collection of complaints but a decision table: source URL or identifier, issue class, severity, owner, selected fix, and closure criteria. For example: "page containing a gallery shortcode - manually rebuild the Joomla gallery - editor - closed when all 12 photos open on the new page." This turns migration from an unpredictable event into a manageable queue.

A critical validation outcome is achieved not when there are no differences at all, but when every difference has either been fixed or consciously accepted, has an owner, and does not conceal a risk to visitors, access, or data integrity.

Repeat Migration Before Launch: How Not to Overwrite Completed Work

Between the first import and publication, the old WordPress or Drupal site often remains active. Editors add articles, users leave comments, and images change. This creates a delta problem: how can you bring over new data without destroying work on the new design or creating confusing duplicates? The question cannot be left until the evening of the switch.

In a Joomla Stack Exchange discussion, a user described rerunning CMigrator with clean migration disabled. The result created distinguishable copies of both new and existing items, which then required manual cleanup and relocation. This is useful evidence of possible behavior in an old tool, but it is not a universal procedure. It proves the opposite: repeat imports must be rehearsed on a copy in advance, because disabling cleanup does not create intelligent synchronization of changes on its own.

Three Practical Strategies

Editorial freeze. This is the simplest option for a small site: publishing on the source stops during a short agreed window, a fresh export is made, a clean test Joomla copy is restored, the validated final process runs, and the site launches after a final check. This approach requires discipline but avoids complex duplicate-handling behavior.

Delta from a recorded list. This works when only a small number of articles have been added after the first wave. The team records new and changed posts, moves them through a separate pretested method or manually, and then repeats sample validation. Do not assume CMigrator can update only the records that changed unless that behavior has been confirmed in your build.

A new full migration into a clean destination. This is suitable when there has been a large volume of changes and the new Joomla site has not yet received manual edits that need to be retained. The entire project is rebuilt from the recorded latest copy. The advantage is repeatability. The drawback is that all manual settings must be documented well enough to reproduce.

Choose one strategy before developing the template and menus. If the new Joomla site is being actively populated manually alongside a live WordPress site, a late full import can erase that work. If the migration is run only once while editorial publishing continues, there will be a data gap at the moment of launch. A mature plan always has an owner for the final decision and an exact cutoff time.

URLs, Search, and Launching the New Public Site

CMigrator can place content in Joomla, but it does not create a complete URL transition strategy. In WordPress, URLs often depend on permalinks, dates, categories, or post type. In Joomla, a URL is determined by menu structure, aliases, routing settings, and the output template. The same article title therefore does not guarantee the same path. Losing old URLs is especially painful for inbound links, bookmarks, and organic traffic.

Build the Map Before Creating Redirect Rules

Compile old URLs from analytics, the sitemap, server logs, and the most important sections. For each one, choose a new URL or the decision that the page will not be migrated. Do not create dozens of broad redirects to the homepage: that does not help users and sends a weak signal to search engines. Test each specific pair: the old URL should lead to the relevant new article with the expected response status.

In a Joomla Masterclass case study, CMigrator was used temporarily to move WordPress blog content, while the team separately mapped URLs and prepared redirects. This is a good example of proper separation of responsibilities: importing articles and images was one stage, while preserving routes was another. It is worth following the same approach even on a small site, or the issue will surface after the old project is disabled.

Joomla Menus Are a Presentation Layer, Not a Category List

In Joomla, a menu item is more than a link: it defines context and how content is displayed. For that reason, do not automatically create a menu item for every old category after importing categories. First define user paths: a section homepage, archive, knowledge base, individual articles, search, and author pages. Then create the required menu items, assign their display type, and check how the page URL and title change.

If part of the old site was built around WordPress widgets, Joomla will need modules and template positions. CMigrator cannot determine which sidebar you intended to show alongside which article. Plan this layer after content has been proven but before final URL validation. That way, you will not need to change routing again because of menu items you have already created.

Pre-Switch Validation

• Check the primary old URLs, important categories, and a dozen popular articles against the redirect map.
• Open images and attached files after changing the test domain to the future public URL.
• Confirm that the staging environment contains no links to internal domains, internal directories, or test forms.
• Check sign-in, access recovery, and permissions if users are genuinely moving to the new Joomla site.
• Check metadata, titles, canonical links, and indexability using the methods adopted for the project.

Do not describe this as a guarantee that search rankings will be preserved. Migration affects many factors, and the quality of redirects and content only reduces predictable risks. The team's job is to make the path clear for visitors and bots, then monitor errors and fix real discrepancies.

Safe Improvements After Import: Use Only Standard Joomla Tools

After a successful migration, it is tempting to edit imported articles in bulk directly in the database. Do not do that. Mass SQL replacements can damage serialized values, links, HTML, or revision history, and the work can become difficult to reproduce after another run. It is safer to use Joomla's built-in editors, search filters, language overrides, and template overrides when they match the goal.

How to Carefully Replace a Repeated External Label

If dozens of imported articles contain the same outdated text label, first confirm that it is ordinary text rather than system code or an old CMS shortcode. Then make a copy of the test database, find every occurrence through administrative search or an exported list, and correct several articles manually. Once the outcome is clear, choose the batch-editing mechanism approved for your Joomla version, or ask a developer to create a safe one-time script only on a copy, with a change log and rollback option. Do not place untested code in the template or modify the Joomla core.

Keep Template and Language Changes Separate from Data

If imported text is correct but the user-facing button label, date format, or tag output is unsuitable, look for a built-in language string or template setting. If you need to change the markup of an article list, use a documented template override instead of editing core or component files. This approach survives updates more reliably and does not mix data migration with design work. For every change, record the location, expected effect, verification step, and rollback procedure.

CMigrator provides no basis for inventing hooks, classes, or settings. The available material does not confirm a public API for safely extending the process. That is why this guide contains no "CMigrator PHP snippet." It is more dependable to use the component configuration, backups, and Joomla tools than to insert appealing but unverified code.

Troubleshooting CMigrator: Symptoms, Root-Cause Checks, and Safe Fixes

Troubleshooting starts with one rule: do not run another import over an unclear outcome. First save the error message, configuration name, timestamp, counts before and after the run, and several examples of affected articles. Then identify where in the chain the symptom appeared: the component archive, Joomla, access to tables, CMigrator behavior, media files, the public template, or the launch plan. The checks below are not generic advice; they are tied to how CMigrator has historically worked.

The Component Will Not Install or Its Page Will Not Open

Symptom: Joomla rejects the archive, ends installation with an error, or CMigrator shows a blank page, a 500 error, or warnings after installation.

Possible cause: a corrupted package, upload or temporary-directory restrictions, directory permissions, an unsuitable PHP version, or an old extension that is incompatible with the current Joomla release. Since there is no confirmed current official CMigrator compatibility matrix, treat the last cause as a real possibility rather than an exception.

What to check: the archive integrity from a legitimate source, the Joomla system message, server error logs, and the Joomla and PHP versions in the test environment. Compare behavior on a clean copy without modifying the live site.

How to fix it: resolve the specific environment limitation or deploy an isolated environment whose compatibility can be confirmed. If the component does not open after installation, do not edit its source code or disable CMS security mechanisms. Record the incompatibility and choose another migration path.

When to roll back: immediately, if installation damages the test Joomla site, changes unexpected data, or requires manual core edits.

CMigrator Cannot See the Source Data

Symptom: the entity list is empty, migration completes without articles, or an SQL error appears for missing tables.

Possible cause: the wrong prefix was entered in Database prefix, WordPress or Drupal tables were not imported into an available database, they belong to another source, or the SQL import completed only partially.

What to check: the actual source table names, the WordPress table_prefix setting, the presence of expected post, term, and user tables, and the CMigrator configuration record. Do not confuse the Joomla prefix with the source prefix.

How to fix it: restore the source SQL dump in the test environment, retain its unique prefix, create a new configuration with the correct value, and run a small test without cleanup. If the source is Drupal, confirm the supported structure using a Drupal sample rather than entering a WordPress prefix.

When to roll back: if earlier attempts created partial data and it is unclear what has already been imported, restore a clean Joomla test restore point rather than launching again over it.

Categories Appear, but Articles Are in the Wrong Place or Lost Their Second Category

Symptom: the category tree exists, but some articles appear in an unexpected section, or WordPress posts assigned to multiple categories display in only one.

Possible cause: a difference between the WordPress and Joomla models. Available CMigrator instructions warn that a Joomla article cannot belong to several categories at once, and their workflow selects the first source category.

What to check: ten source posts with one category and ten with multiple categories, their category order in the source, the future purpose of the second category, and the parent tree in Joomla.

How to fix it: agree on a primary category for these articles and implement the second relationship with a tag, collection, related article, or menu item. Do not create duplicates without an architectural decision, and do not change categories in bulk until the selection rule has been confirmed.

When to roll back: if an incorrect mapping rule was applied at scale, it is cheaper to restore a clean destination, refine the category map, and repeat a validated run.

Images Are Missing from Articles or Point to the Old Domain

Symptom: Joomla shows empty spaces, loading errors, relative URLs, images from a test domain, or links that will stop working after the source is disabled.

Possible cause: the Base site URL is wrong, source files are inaccessible, old content used nonstandard paths, images belonged to an external service, or only links were migrated rather than files themselves.

What to check: compare the original HTML with the imported version, open a specific image URL in the browser, and check the protocol, domain, directory, and server response. Start with three images that use different path structures.

How to fix it: correct the base URL in a new test configuration, provide legitimate access to the file copy, or create a separate media-library migration plan. Run a repeat import only in a clean copy or against a deliberately isolated sample so that old and new links are not mixed.

When to roll back: if mass substitution created hundreds of incorrect URLs and there is no precise change history, return to a backup restore point instead of performing global string replacements in the database.

WordPress Shortcodes, Empty Blocks, or Broken Markup Are Visible in an Article

Symptom: internal constructs are visible on the public page, a gallery is missing, a table has become text, or a link turns into an empty space.

Possible cause: CMigrator may remove or replace some incompatible WordPress tags, but an old plugin, page builder, or shortcode has no direct Joomla equivalent.

What to check: the saved original HTML for the specific article, the name of the plugin or builder, the number of repeated instances of the same construct, and its business value.

How to fix it: choose a Joomla equivalent and rebuild the template element manually, or agree on a simplified presentation. Maintain a replacement list by construct type. Do not paste WordPress code into Joomla or add unverified executable code to an article.

When to roll back: roll back a mass import only if a parser rule damaged the main content. For a few individual blocks, it is safer to address them as an editorial queue.

A Repeat Run Created Copies or Affected Already Verified Content

Symptom: after a second run, similar titles appear, items have CMigrator appended to their names, categories are duplicated, or a new wave of content appears over manual edits.

Possible cause: CMigrator is not a confirmed bidirectional synchronization system. In a community-known case, a repeat import without cleanup required manually separating new items from copies.

What to check: which configuration was selected, whether Clean Migration was enabled, when the source database copy was made, which Joomla items changed after the first run, and whether a delta rule had been defined in advance.

How to fix it: stop further runs. On a copy, classify items by source identifiers and creation time, then choose one of three paths: a manual delta, a repeat migration into a clean destination, or an agreed editorial freeze. Do not delete everything indiscriminately until a backup restore point has been preserved and the scope of manual edits is understood.

When to roll back: if the volume of duplicates exceeds the amount of manual cleanup, restore the previous verified Joomla copy and rehearse the final strategy separately.

Content Imported, but Visitors See a 404, a Different Layout, or a Restricted Page

Symptom: the article exists in the administration panel, but its public link opens an error, the old URL does not work, the output differs from expectations, or only administrators can access it.

Possible cause: the problem is in menus, aliases, category permissions, the template, module positions, or the redirect map rather than in CMigrator's reading of tables.

What to check: open the article using its direct new route, verify publication status, category, permissions, menu item, template assignment, and the specific redirect rule from the old URL.

How to fix it: restore the correct Joomla route, create a relevant redirect, and test it in a clean browser session. Keep routing and presentation defects separate in the log so that you do not rerun the import because of a menu error.

When to roll back: migration rollback is unnecessary if the data is correct and the problem is limited to public configuration. Roll back only changes that caused loss of access or permission failures.

Developer Webinar: Where to See CMigrator's Historical Workflow

To understand the historical interface specifically, the recorded CMigrator webinar with component creator Daniel Dimitrov is useful. It relates to an early generation of the product, so it does not prove support for current Joomla releases. However, it still helps validate this guide's main point: first installation and configuration, then WordPress migration, images, and handling of incompatible tags. Watch it alongside a test copy, pause after every step you understand, and compare it with the interface in your own package rather than following it literally on a live site.

The video's value lies in the practical cluster of "how to configure CMigrator for a WordPress-to-Joomla migration": it shows the configuration and media-migration workflow rather than offering an abstract CMS overview. Treat any tab names missing from your package as evidence of a version difference, not as a reason to search for a hidden button.

When CMigrator Is the Right Choice

CMigrator is justified when its specific build passes testing on a separate Joomla installation, you have complete access to the source, and the task is clearly limited to migrating editorial data from WordPress or Drupal. Its value is not a promise of magic but a controllable configuration: tables with a known prefix, a base URL for media, selected entities, a deliberate cleanup setting, and repeatable validation. When all of that is in place, migration becomes a series of controlled steps instead of a risky leap between CMS platforms.

Before launching the new site, return to the log: have all exceptions been closed, has the final workflow been rehearsed, are backups available, and is there a URL map? After that validation, you can download CMigrator for use on a test copy and begin with a small, safe run. If critical data lives in nonstandard entities or the package fails compatibility testing, the right outcome is not an attempt at any cost but the choice of an alternative migration path.