Follow-up: additional bugs found while testing the real (write) Sync engine, one severe
Since the report above, I continued testing past the dry-run issue by running the Migrator's real Sync path (per-row Sync, not dry-run) as a series of scoped canaries, working up the wizard's own dependency chain from Lookup Tables through Joomla Content & Users. The Sync/write path is NOT affected by the dry-run bug described above -- real Syncs on Currencies, Countries, Zones, Tax Profiles, Access Levels & Groups, and Users all completed and wrote plausible data. However, this testing surfaced four additional, distinct bugs, the last of which is severe (live content duplication) and the reason I stopped further testing.
Bug 3: every real Sync appears to run its per-tile batch/migration logic twice per click ("double-pass processing")
Confirmed on two tiles of very different size, both with the identical arithmetic signature. Zones (source table j2store_zones, 3,976 rows): Migration History reports Migrated: 56, Skipped: 7,896. The run's own Activity Log shows processed=7952, total_source=3976 -- processed is exactly 2x total_source. Working through it: pass 1 processed all 3,976 rows once (3,920 skips + 56 inserts); pass 2 re-processed the same 3,976 rows again, and since everything now existed in the target (including the 56 just-inserted rows), pass 2 skipped all 3,976. 3976+3976=7952 processed; 3920+3976=7896 skipped; 56 inserted (from pass 1 only). Tax Profiles (source table j2store_taxprofiles, 1 row) shows the identical signature at 1-row scale: processed=2, total_source=1, inserted=1, skipped=1.
This appears idempotent under "skip" conflict mode -- no duplicate data was created in either case, verified by spot-checking J2Commerce 6's own admin for both tiles -- but it roughly doubles wall-clock work and inflates the reported processed/skipped counters. I have not tested whether it is equally harmless under Overwrite or Merge conflict modes.
Bug 4: Zones sync has no foreign-key remap pass -- PK collisions silently repoint any table with a raw numeric FK into zones
The Zones real Sync produced a red warning banner not seen on any other tile: "56 row(s) were given a NEW target ID because their original ID already belonged to an unrelated row. Any child data still referencing the old ID may now point at the wrong parent -- review before trusting this data." The Activity Log confirms 56 WARNING lines of the form: "Natural-key miss + PK collision on j2commerce_zones: source PK 201 is already occupied by an unrelated target row. Reassigning to a new auto-increment id -- any child row still referencing PK 201 numerically will now point at the wrong parent (this engine has no FK-remap pass)."
I found no evidence of actual corruption in this dispatch, since nothing downstream referenced zones yet (Tax Rates/Geo Zones had not synced), but the tool's own message is explicit that it cannot remap foreign keys pointing at the 56 reassigned IDs. Any site migrating a table with a raw zone_id-style foreign key (shipping rates, tax rules, customer addresses, etc.) should treat this as a real data-integrity risk to check for by hand.
Bug 5: Users sync -- summary counters silently disagree with the run's own Activity Log, and skip mode drops 72 dependent child rows
Ran a real Sync on Users (249 Joomla accounts; same-server mode, so J2Commerce 6 shares the same #__users table as the v4 source -- "Migrated: 0" is the correct, expected outcome here, not a bug). Two problems surfaced only by opening the full Activity Log for this run, not from any summary UI. First, the Migration History list and the run's own result modal both report "Skipped: 0" for this run, but the Activity Log itself contains exactly 249 lines of the form "users:<id> skipped per conflict resolution" -- an exact match to the live user count. Every summary surface disagrees with the tool's own detailed log. Second, immediately after those 249 skip lines, in the same run, the tool attempts to migrate two child tables (Joomla core's own user_profiles and user_notes, swept up because Users migrates them in the same tier) and logs 8 lines of "WARNING user_profiles:0 skipped - user_id has no mapped target row" and 64 lines of "WARNING user_notes:<1-64> skipped - user_id has no mapped target row". The apparent cause: because the parent Users pass chose "skip" for all 249 already-existing rows, it never recorded an identity-map entry for any of them (even though, in same-server mode, source-id = target-id trivially) -- so the very next tier in the same run cannot resolve "target user for source user X" and drops the row instead of migrating it, logged only as a WARNING, invisible in the wizard, Migration History, or the run's own summary widget.
In my case the content lost was low-consequence -- I independently verified the 64 user_notes rows are 100% auto-generated sign-up IP/user-agent security-log entries from a third-party security plugin, not staff-written notes, and the 8 user_profiles rows are optional registration metadata for a plugin that is currently disabled site-wide -- but the mechanism itself (skip mode never populating the identity map) is a general design gap that could silently drop consequential child data on a site where these two Joomla core tables are used for something meaningful, with no way to know without manually opening every run's full Activity Log.
Bug 6 (severe): "Migrate Categories & Articles" pre-flight confirm duplicated every article on the site
This is the most serious issue, and the reason I stopped testing entirely. Content Categories is the first tile that does not Sync immediately on click -- it opens a "Migrate Categories" pre-flight modal listing every source category with a target-mapping dropdown, defaulting (per its own underlying DOM state, not just the displayed label) to "Create identical"/self for every row, except for two source categories that happen to share a display name with an unrelated category elsewhere in the tree (a nested "Grouped Products > Quilting Books" vs. a top-level "Shop > Quilting Books", and similarly for "Notions"). For those two rows, the default silently pre-selects the unrelated same-named category instead of self, which would merge two distinct categories together if confirmed as pre-filled. I did not submit that default -- I manually corrected just those two dropdowns to "Create identical" and confirmed.
That corrected confirm action completed with no error, and both tiles ("Content Categories" and "Articles") showed a clean "Synced, 0 rows" -- but it silently duplicated every one of the site's 63 published articles (new sequential IDs immediately following the prior max, alias suffix "-2", 0 hit-count vs. the originals' real hit counts, confirmed across all 63 pairs including high-traffic pages), taking total articles from 63 to 126, and separately created two brand-new, unwanted duplicate categories (cloned siblings of the two "Create identical" rows) instead of treating "Create identical" as "leave the source category as itself." There is no Migration History row and no Activity Log at all for this action -- unlike every other real Sync described in this ticket, this is a completely different code path that produces no audit trail whatsoever. The only way I detected this was by independently re-deriving the site's category and article counts by hand and diffing them against ground truth recorded before the action.
I did not attempt any further Sync steps after finding this, and remediated the live site by restoring from a full backup taken immediately before this step (restore verified fully successful, all content back to its correct pre-migration state).
Environment is the same as reported above (Joomla 6.1.3, PHP 8.4.20, MariaDB 12.2.2, J2Commerce 6.6.1, Migrator 6.1.9). Happy to provide the same kind of supplementary evidence as before -- logs, HAR files, or a screen recording -- for any of these four issues if useful. This remains a local development copy of the site, not publicly reachable, so I still can't offer direct login access.
