# Mautic 6.0.2 to 6.0.3 Update Can’t DROP INDEX \`mtc\_company\_match\` Error **URL:** \ **Category:** Mautic 6 Install/Upgrade Support\ **Created:** [July 15, 2025, 3:46pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084 "2025-07-15T15:46:13Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [July 15, 2025, 3:46pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/1 "2025-07-15T15:46:13Z")
Hello, Mautic update 6.0.3 has recently been released and I have been eager to install it. However when you try and upgrade Mautic 6.0.2 to 6.0.3 then it fails with the same error as this post below. > [@Mautic 6.0.0 to 6.0.2 Update Can't DROP INDEX \`mtc\_company\_match\` Error](https://forum.mautic.org/t/mautic-6-0-0-to-6-0-2-update-cant-drop-index-mtc-company-match-error/35787): > > I originally downloaded the Mautic 6.0.0 zip from the Mautic GitHub release page and successfully installed it manually without using composer. Mautic 6.0.0 was working. To upgrade to Mautic 6.0.2 I have run the following commands as documented. php bin/console mautic:update:find It identified that I was running Mautic 6.0.0 and there was an update available to Mautic 6.0.2. I then applied the update with: php bin/console mautic:update:apply However when I run the next command it failed wi… Looks like the code to do the actual upgrade has not been fixed in the 6.0.3 release. This confirm my suspicion that very little testing effort is being done to confirm upgrades will install error free putting users databases at risk. Yes I know Mautic 5.x is the favored release and 6.x should be by passed however if its an official release then at the very least the upgrade process should work. And if there is a bug in the upgrade code then it should be fixed in the next release so that users databases are not put as risk. Thanks. ---
**Author:** ![joeyk](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/joeyk/32/11164_2.png) [@joeyk](https://forum.mautic.org/u/joeyk)\ **Post date:** [September 2, 2025, 7:56am UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/2 "2025-09-02T07:56:13Z")
> [@andrew\_c3](#): > > This confirm my suspicion that very little testing effort is being done to confirm upgrades will install error free putting users databases at risk. Hello! Thank you for pointing it out, I think there is never enough testing. One of the reasons is, that Mautic users are not aware how to start with tests and how to communicate with developers during testing. I would be happy to onboard you next week, if you are interested in helping out in that area. You can any time PM me. Joey ---
**Author:** ![johnwick](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/johnwick/32/3279_2.png) [@johnwick](https://forum.mautic.org/u/johnwick)\ **Post date:** [September 3, 2025, 9:04pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/3 "2025-09-03T21:04:41Z")
Just installed 6.0.4 yesterday and upgraded to 6.0.5 today, and got this same error. The composer upgrade procedure needs to be clearer and enhanced. ---
**Author:** ![johnwick](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/johnwick/32/3279_2.png) [@johnwick](https://forum.mautic.org/u/johnwick)\ **Post date:** [September 3, 2025, 10:26pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/4 "2025-09-03T22:26:28Z")
I have fixed the error in the two problem files and completed the migration successfully. I include the two fixed files. Download the file, rename its extension to .php, and then upload it to your 6x instance. Finally, re-run the command. > > > \[Version20211020114811.txt\](https://github.com/user-attachments/files/22127820/V…ersion20211020114811.txt) > \[Version20230621074925.txt\](https://github.com/user-attachments/files/22127821/Version20230621074925.txt) > > \### Mautic Series > > 6.0.x series > > \### Mautic installed version > > 6.0.5 > > \### Way of installing > > I installed with composer using https://github.com/mautic/recommended-project > > \### PHP version > > 8.3 > > \### What browsers are you seeing the problem on? > > \_No response\_ > > \### What happened? > > Summary > > Two migrations in 6.x assume a pristine schema and unconditionally execute DROP/CREATE/ALTER statements. > On instances where migrations were partially applied or schema was changed manually, rerunning migrations fails with MySQL errors (e.g., 1091, 1050). > Root cause: > PreUpAssertionMigration::preUp() > only skips when all assertions are true. If any one assertion fails, the migration proceeds and unguarded SQL may attempt to drop or create objects that already don’t/do exist. > Environment > > Impacted files > docroot/app/migrations/Version20211020114811.php > docroot/app/migrations/Version20230621074925.php > > Related helper: docroot/app/bundles/CoreBundle/Doctrine/PreUpAssertionMigration.php (behavior context) > Observed errors (examples) > > \*\*From > Version20211020114811.php\*\* > (companies index adjustments): > SQLSTATE\[42000\]: 1091 Can't DROP INDEX mau\_company\_match; check that it exists > > \*\*From > Version20230621074925.php\*\* > (points groups): > SQLSTATE\[42S01\]: 1050 Table 'mau\_point\_groups' already exists > Columns and FKs may also cause “already exists” errors when partially applied. > Reproduction steps > > Prepare a DB where one or more of these conditions are true: > \*\*mau\_company\_match\*\* index already dropped or never existed. > \*\*mau\_point\_groups\*\* table already exists (along with related columns/FKs), or only some of them exist. > > Run: > php bin/console doctrine:migrations:migrate --no-interaction > Actual behavior: migration fails with 1091 (DROP INDEX missing) or 1050 (table exists), or similar duplicate column/FK errors. > > Expected behavior: migrations should be idempotent and safely no-op when objects already exist or are missing. > Root cause details > > PreUpAssertionMigration::preUp() > skips only if all skip assertions pass. If any assertion fails (i.e., something still needs to run), the migration continues. > > Inside > up() > , SQL is unconditionally executed (DROP/CREATE/ALTER). This breaks on partially applied schemas. > > \*\*Proposed resolution\*\* > > Make migration SQL idempotent via Doctrine SchemaManager introspection: > Only DROP an index if hasIndex() is true. > Only CREATE an index if hasIndex() is false. > Only CREATE TABLE if it doesn’t exist (tablesExist(\[...\])). > Only ADD COLUMN if hasColumn() is false. > Only ADD CONSTRAINT if hasForeignKey() is false. > This complements > preUpAssertions() > and ensures safe reruns. > Concrete examples (files) > > Version20211020114811.php > Currently: unconditionally executes DROP INDEX and CREATE INDEX for mau\_company\_match and other indexes. > Fix: guard with $this-\>connection-\>createSchemaManager()-\>introspectTable(...)-\>hasIndex(...) before DROP/CREATE. > Version20230621074925.php > Currently: unconditionally executes CREATE TABLE (mau\_point\_groups, mau\_point\_group\_contact\_score), ADD COLUMN group\_id, and ADD CONSTRAINT FKs. > Fix: guard with tablesExist(\[...\]), hasColumn(...), and hasForeignKey(...) accordingly. > Testing notes > > Test on: > Fresh DB (no objects exist) — migration creates everything as intended. > Partially applied DB (some objects exist) — migration performs only missing steps and completes without error. > Fully applied DB — migration essentially no-ops without error. > Why this matters > > Production systems may pause/rollback migrations mid-flight or apply manual schema changes. Non-idempotent migrations cause fragile upgrades and support incidents. > Idempotent migrations are a safe default and reduce maintenance burden. > Attachments (if maintainers want) > > I can open PRs for: > Version20211020114811: guard DROP/CREATE INDEX. > Version20230621074925: guard CREATE/ALTER/FKs. > Happy to extend the same pattern to any other migrations flagged by maintainers. > > \### How can we reproduce this issue? > > Step 1: Update Mautic > Step 2: Run command \*\*php bin/console doctrine:migrations:migrate --no-interaction\*\* > > \### Relevant log output > > \`\`\`shell > \[2025-09-03T20:51:54.744434+00:00\] console.CRITICAL: Error thrown while running command "doctrine:migrations:migrate --no-interaction". Message: "An exception occurred while executing a query: SQLSTATE\[42000\]: Syntax error or access violation: 1091 Can't DROP INDEX \`mau\_company\_match\`; check that it exists" {"exception":"\[object\] (Doctrine\\\\DBAL\\\\Exception\\\\DriverException(code: 1091): An exception occurred while executing a query: SQLSTATE\[42000\]: Syntax error or access violation: 1091 Can't DROP INDEX \`mau\_company\_match\`; check that it exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/API/MySQL/ExceptionConverter.php:117)\\n\[previous exception\] \[object\] (Doctrine\\\\DBAL\\\\Driver\\\\PDO\\\\Exception(code: 1091): SQLSTATE\[42000\]: Syntax error or access violation: 1091 Can't DROP INDEX \`mau\_company\_match\`; check that it exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/PDO/Exception.php:28)\\n\[previous exception\] \[object\] (PDOException(code: 42000): SQLSTATE\[42000\]: Syntax error or access violation: 1091 Can't DROP INDEX \`mau\_company\_match\`; check that it exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:71)","command":"doctrine:migrations:migrate --no-interaction","message":"An exception occurred while executing a query: SQLSTATE\[42000\]: Syntax error or access violation: 1091 Can't DROP INDEX \`mau\_company\_match\`; check that it exists"} {"hostname":"hosting.domain.net","pid":875537} > > > \[2025-09-03T21:13:30.989519+00:00\] console.CRITICAL: Error thrown while running command "doctrine:migrations:migrate --no-interaction". Message: "An exception occurred while executing a query: SQLSTATE\[42S01\]: Base table or view already exists: 1050 Table 'mau\_point\_groups' already exists" {"exception":"\[object\] (Doctrine\\\\DBAL\\\\Exception\\\\TableExistsException(code: 1050): An exception occurred while executing a query: SQLSTATE\[42S01\]: Base table or view already exists: 1050 Table 'mau\_point\_groups' already exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/API/MySQL/ExceptionConverter.php:45)\\n\[previous exception\] \[object\] (Doctrine\\\\DBAL\\\\Driver\\\\PDO\\\\Exception(code: 1050): SQLSTATE\[42S01\]: Base table or view already exists: 1050 Table 'mau\_point\_groups' already exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/PDO/Exception.php:28)\\n\[previous exception\] \[object\] (PDOException(code: 42S01): SQLSTATE\[42S01\]: Base table or view already exists: 1050 Table 'mau\_point\_groups' already exists at /var/www/vhosts/domain.net/subdomains/hello/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:71)","command":"doctrine:migrations:migrate --no-interaction","message":"An exception occurred while executing a query: SQLSTATE\[42S01\]: Base table or view already exists: 1050 Table 'mau\_point\_groups' already exists"} {"hostname":"hosting.domain.net","pid":884124} > \`\`\` > > \### Code of Conduct > > \- \[x\] I confirm that I have read and agree to follow this project's Code of Conduct > > \
\ > Care about this issue? Want to get it resolved sooner? If you are a \member of Mautic\, you can add some funds to the \Bounties Project\ so that the person who completes this task can claim those funds once it is merged by a member of the core team! Read the docs \here.\ ---
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [September 4, 2025, 8:55am UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/5 "2025-09-04T08:55:03Z")
Hello **[johnwick](https://forum.mautic.org/u/johnwick),** Great news you have found the root cause of this issue and hopefully it will be applied to future releases in due course. I’m currently running a production version of M6.0.3 and have not yet run an upgrade on this instance, Will the above files also work for migrating from M6.0.3 to the latest version of M6.x ? I thought it a good idea to ask before making an attempt. Thanks. ---
**Author:** ![diamondtheta](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/diamondtheta/32/14396_2.png) [@diamondtheta](https://forum.mautic.org/u/diamondtheta)\ **Post date:** [September 6, 2025, 12:01pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/6 "2025-09-06T12:01:08Z")
I had same “can’t drop index” errors and my “mautic expert” hosting company aslo could NOT solve it.. even with all ChatGPT + Claude AI help, and i also did all commands as they told and searched all forums, etc. and the “can’t drop index” came up even after full composer install, and even on full empty and new database on mautic 6.0.5 with very new almost 100% compozer fresh install also. So please solve that because it seems that bug is comiing up again and again in different forms (indexes) with every upgrade when someone migrated through from an earlier non compozer mautic.. ☹ ---
**Author:** ![diamondtheta](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/diamondtheta/32/14396_2.png) [@diamondtheta](https://forum.mautic.org/u/diamondtheta)\ **Post date:** [September 6, 2025, 12:34pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/8 "2025-09-06T12:34:52Z")
Thanks, i tried it, but it did not solve my problem. So this is also one confirmation for me that this whole ‘can’t drop index’ is NOT just in this or that “VersionXY” file from migrations folder, because MAYBE you could solve that those 2 files IF your “can’t drop index” was caused by THOSE 2 files, but this “can’t drop index” can be caused by MANY THINGS, so not just from those 2 files, because your 2 file did not solve mine, and on every forum the “can’t drop index” is coming up for many different mautic tables, and for MANY different mautic versions, so thanks for your 2 files but even if they work for those who’s “can’t drop index”-es are caused by those 2 migrations this is just a very little “surface level partly solution” because every guy seems to have a slightly different “can’t drop index” problem, i checked many many forums, BUT in every version, so many files could cause the cant drop index not just those 2 files what you fixed! And even if the first time the schema update finises "with green ok” on fresh new empty database even after the same command instantly it gots the can’t drop index again… and if everybody ran into different shared hosting limits when was migrating from mautic 2 then the hole ROOT must be solved of this problem not just the “1-2 surface instances” every time.. because if the root is not solved than EVERY mautic upgrade ALSO IN THE FUTURE will be a NIGHTMARE even if every time someone solves it “ON THE SURFACE” but it really would need the REALLY DEEP LEVEL ROOT cause CURE! IF you all want mautic to spread like wildfire because it is i am sure the real root blocking problem to that because every other problem can be solved with chatGPT or other AI or “good mautic host” but that “can’t drop index” or other similar MAPPING problems from ENTITIES like doctrine:schema:validate seems not, like: ## Mapping [FAIL] The entity-class Mautic\DynamicContentBundle\Entity\DynamicContentLeadData mapping is invalid: - The association Mautic\DynamicContentBundle\Entity\DynamicContentLeadData#dynamicContent refers to the inverse side field Mautic\DynamicContentBundle\Entity\DynamicContent#id which is not defined as association. ” ---
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [September 11, 2025, 6:44am UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/9 "2025-09-11T06:44:40Z")
Hello, More and more end users are encountering these Mautic upgrade errors. I have been reporting them for a while and the developers are ignoring the problem. I don’t understand why the developers expend time and effort releasing new versions if we cannot install them because of this upgrade error. Are you hoping that M7 when released will resolve the problem ? Surely the developers priority should be to focus their attention on fixing this problem so that we can install new version as and when they are released. Could a developer please explain their rational for not fixing this problem quickly ? Thanks. ---
**Author:** ![mcpatcher](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/mcpatcher/32/14241_2.png) [@mcpatcher](https://forum.mautic.org/u/mcpatcher)\ **Post date:** [November 16, 2025, 3:42am UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/10 "2025-11-16T03:42:36Z")
Hi all, These migration issues have been plaguing me for a while now. I’ve been putting them on the “deal with later list” for as long as I could. Unfortunately (or fortunately depending on how you look at it), I finally had to sort it out as I’m running Mautic in a Kube cluster and can’t have restarting pods failing due to this. I tried a few things including forcing “migrated” status on each migration, but that appears to cause some missing schema. I was on a fresh install of Mautic using the 6.0.5 docker image. **NOTE: I found out the docker image environment variable option** `DOCKER_MAUTIC_RUN_MIGRATIONS` **does not do anything in 6.** The migrations that were failing for me were: - Version20211020114811 - Version20211209022550 **Version20211020114811 -** Failing due to the missing index (can’t drop) I shelled into the container, patched the file then proceeded - this only works because the migration is recorded as succeeding so it doesn’t run again when the container restarts and clears the patch. Docker: `docker run -it --entrypoint /bin/bash mautic/mautic:6.0.5-20250904-apache` Kuberenetes `kubectl exec -it -- /bin/bash` Patch the file: ```auto patch app/migrations/Version20211020114811.php << 'EOF' > 58,64c58,67 < $this->addSql( < sprintf( < $dropIndexQuery, < self::INDEX_COMPANY_MATCH, < $this->getPrefixedTableName(self::COMPANIES_TABLE) < ) < ); --- > if($schema->getTable($this->getPrefixedTableName(self::COMPANIES_TABLE))->hasIndex(self::INDEX_COMPANY_MATCH)) > { > $this->addSql( > sprintf( > $dropIndexQuery, > self::INDEX_COMPANY_MATCH, > $this->getPrefixedTableName(self::COMPANIES_TABLE) > ) > ); > } EOF ``` Or if you’d prefer to patch manually: Install an editor: ```auto apt install nano ``` And add a check for the index before attempting to drop it: ```auto if($schema->getTable($this->getPrefixedTableName(self::COMPANIES_TABLE))->hasIndex(self::INDEX_COMPANY_MATCH)) { // Original code around line 58 $this->addSql( sprintf( $dropIndexQuery, self::INDEX_COMPANY_MATCH, $this->getPrefixedTableName(self::COMPANIES_TABLE) ) ); } ``` That solved that first issue. Some people reported flagging it as migrated already. Since I attempted flagging all as migrated first and it did not work I was concerned about schema consistency. **Version20211209022550** - Failing due to roles table not existing. This took a little more work. I inspected the migration and noticed that this migration was using Doctrine to get the Model instead of the table directly. It seems that process doesn’t apply the table prefix. I’m not sure if there is another setting that could be changed but my solution was to remove the table prefix entirely and update my configuration. Shell into the container again (see previous patch) and modify the config: ```auto nano /var/www/html/config/local.php ``` Set: ```auto 'db_table_prefix' => '' ``` Save and exit the shell. Now connect to your database directly. This will vary depending on your set up, but for example: ```auto mysql -h 127.0.0.1 -P 3306 -u root -p ``` Enter your password. Set your database, e.g. ```auto use mautic; ``` Now rename all tables to remove the prefix you had before. In my case I used `mautic` so all of my tables were `mauticsomething` which needed to be changed to `something` Depending on your version you may have a different list of tables. **I recommend running `show tables;` to get the full list.** For each table you’ll need to: ```auto ALTER TABLE mauticsomething RENAME TO something; ``` For my version it was the following: ```auto ALTER TABLE mauticasset_downloads RENAME TO asset_downloads; ALTER TABLE mauticassets RENAME TO assets; ALTER TABLE mauticaudit_log RENAME TO audit_log; ALTER TABLE mauticbundle_grapesjsbuilder RENAME TO bundle_grapesjsbuilder; ALTER TABLE mauticcache_items RENAME TO cache_items; ALTER TABLE mauticcampaign_events RENAME TO campaign_events; ALTER TABLE mauticcampaign_form_xref RENAME TO campaign_form_xref; ALTER TABLE mauticcampaign_lead_event_failed_log RENAME TO campaign_lead_event_failed_log; ALTER TABLE mauticcampaign_lead_event_log RENAME TO campaign_lead_event_log; ALTER TABLE mauticcampaign_leadlist_xref RENAME TO campaign_leadlist_xref; ALTER TABLE mauticcampaign_leads RENAME TO campaign_leads; ALTER TABLE mauticcampaign_summary RENAME TO campaign_summary; ALTER TABLE mauticcampaigns RENAME TO campaigns; ALTER TABLE mauticcategories RENAME TO categories; ALTER TABLE mauticchannel_url_trackables RENAME TO channel_url_trackables; ALTER TABLE mauticcompanies RENAME TO companies; ALTER TABLE mauticcompanies_leads RENAME TO companies_leads; ALTER TABLE mauticcontact_export_scheduler RENAME TO contact_export_scheduler; ALTER TABLE mauticcontact_merge_records RENAME TO contact_merge_records; ALTER TABLE mauticdynamic_content RENAME TO dynamic_content; ALTER TABLE mauticdynamic_content_lead_data RENAME TO dynamic_content_lead_data; ALTER TABLE mauticdynamic_content_stats RENAME TO dynamic_content_stats; ALTER TABLE mauticemail_assets_xref RENAME TO email_assets_xref; ALTER TABLE mauticemail_copies RENAME TO email_copies; ALTER TABLE mauticemail_list_excluded RENAME TO email_list_excluded; ALTER TABLE mauticemail_list_xref RENAME TO email_list_xref; ALTER TABLE mauticemail_stat_replies RENAME TO email_stat_replies; ALTER TABLE mauticemail_stats RENAME TO email_stats; ALTER TABLE mauticemail_stats_devices RENAME TO email_stats_devices; ALTER TABLE mauticemails RENAME TO emails; ALTER TABLE mauticemails_draft RENAME TO emails_draft; ALTER TABLE mauticfocus RENAME TO focus; ALTER TABLE mauticfocus_stats RENAME TO focus_stats; ALTER TABLE mauticform_actions RENAME TO form_actions; ALTER TABLE mauticform_fields RENAME TO form_fields; ALTER TABLE mauticform_submissions RENAME TO form_submissions; ALTER TABLE mauticforms RENAME TO forms; ALTER TABLE mauticimports RENAME TO imports; ALTER TABLE mauticintegration_entity RENAME TO integration_entity; ALTER TABLE mauticip_addresses RENAME TO ip_addresses; ALTER TABLE mauticlead_categories RENAME TO lead_categories; ALTER TABLE mauticlead_companies_change_log RENAME TO lead_companies_change_log; ALTER TABLE mauticlead_devices RENAME TO lead_devices; ALTER TABLE mauticlead_donotcontact RENAME TO lead_donotcontact; ALTER TABLE mauticlead_event_log RENAME TO lead_event_log; ALTER TABLE mauticlead_fields RENAME TO lead_fields; ALTER TABLE mauticlead_frequencyrules RENAME TO lead_frequencyrules; ALTER TABLE mauticlead_ips_xref RENAME TO lead_ips_xref; ALTER TABLE mauticlead_lists RENAME TO lead_lists; ALTER TABLE mauticlead_lists_leads RENAME TO lead_lists_leads; ALTER TABLE mauticlead_notes RENAME TO lead_notes; ALTER TABLE mauticlead_points_change_log RENAME TO lead_points_change_log; ALTER TABLE mauticlead_stages_change_log RENAME TO lead_stages_change_log; ALTER TABLE mauticlead_tags RENAME TO lead_tags; ALTER TABLE mauticlead_tags_xref RENAME TO lead_tags_xref; ALTER TABLE mauticlead_utmtags RENAME TO lead_utmtags; ALTER TABLE mauticleads RENAME TO leads; ALTER TABLE mauticmessage_channels RENAME TO message_channels; ALTER TABLE mauticmessage_queue RENAME TO message_queue; ALTER TABLE mauticmessages RENAME TO messages; ALTER TABLE mauticmigrations RENAME TO migrations; ALTER TABLE mauticmonitor_post_count RENAME TO monitor_post_count; ALTER TABLE mauticmonitoring RENAME TO monitoring; ALTER TABLE mauticmonitoring_leads RENAME TO monitoring_leads; ALTER TABLE mauticnotifications RENAME TO notifications; ALTER TABLE mauticoauth2_accesstokens RENAME TO oauth2_accesstokens; ALTER TABLE mauticoauth2_authcodes RENAME TO oauth2_authcodes; ALTER TABLE mauticoauth2_clients RENAME TO oauth2_clients; ALTER TABLE mauticoauth2_refreshtokens RENAME TO oauth2_refreshtokens; ALTER TABLE mauticoauth2_user_client_xref RENAME TO oauth2_user_client_xref; ALTER TABLE mauticpage_hits RENAME TO page_hits; ALTER TABLE mauticpage_redirects RENAME TO page_redirects; ALTER TABLE mauticpages RENAME TO pages; ALTER TABLE mauticpermissions RENAME TO permissions; ALTER TABLE mauticplugin_integration_settings RENAME TO plugin_integration_settings; ALTER TABLE mauticplugins RENAME TO plugins; ALTER TABLE mauticpoint_group_contact_score RENAME TO point_group_contact_score; ALTER TABLE mauticpoint_groups RENAME TO point_groups; ALTER TABLE mauticpoint_lead_action_log RENAME TO point_lead_action_log; ALTER TABLE mauticpoint_lead_event_log RENAME TO point_lead_event_log; ALTER TABLE mauticpoint_trigger_events RENAME TO point_trigger_events; ALTER TABLE mauticpoint_triggers RENAME TO point_triggers; ALTER TABLE mauticpoints RENAME TO points; ALTER TABLE mauticpush_ids RENAME TO push_ids; ALTER TABLE mauticpush_notification_list_xref RENAME TO push_notification_list_xref; ALTER TABLE mauticpush_notification_stats RENAME TO push_notification_stats; ALTER TABLE mauticpush_notifications RENAME TO push_notifications; ALTER TABLE mauticreports RENAME TO reports; ALTER TABLE mauticreports_schedulers RENAME TO reports_schedulers; ALTER TABLE mauticroles RENAME TO roles; ALTER TABLE mauticsaml_id_entry RENAME TO saml_id_entry; ALTER TABLE mauticsms_message_list_xref RENAME TO sms_message_list_xref; ALTER TABLE mauticsms_message_stats RENAME TO sms_message_stats; ALTER TABLE mauticsms_messages RENAME TO sms_messages; ALTER TABLE mauticstage_lead_action_log RENAME TO stage_lead_action_log; ALTER TABLE mauticstages RENAME TO stages; ALTER TABLE mauticsync_object_field_change_report RENAME TO sync_object_field_change_report; ALTER TABLE mauticsync_object_mapping RENAME TO sync_object_mapping; ALTER TABLE mautictweet_stats RENAME TO tweet_stats; ALTER TABLE mautictweets RENAME TO tweets; ALTER TABLE mauticuser_tokens RENAME TO user_tokens; ALTER TABLE mauticusers RENAME TO users; ALTER TABLE mauticvideo_hits RENAME TO video_hits; ALTER TABLE mauticwebhook_events RENAME TO webhook_events; ALTER TABLE mauticwebhook_logs RENAME TO webhook_logs; ALTER TABLE mauticwebhook_queue RENAME TO webhook_queue; ALTER TABLE mauticwebhooks RENAME TO webhooks; ALTER TABLE mauticwidgets RENAME TO widgets; ``` Upon success I quit and restarted my container. All migrations passed after that and I was able to log back it without resetting my installation again. **Final thoughts** I do think it is unfortunate that this hasn’t been officially fixed. I do understand trying to cover all use cases across multiple major releases in all environments is challenging, but this seems very entry level. It is so easy to reproduce. i.e. fresh install + restart container. I haven’t tested version 7 at all, but I’m not sure if I’ll be sticking with Mautic long term due to some of these sorts of issues and scalability challenges due to it’s architecture. Hopefully that helps a few people. ---
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [November 18, 2025, 4:38pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/11 "2025-11-18T16:38:37Z")
Hello **[mcpatcher](https://forum.mautic.org/u/mcpatcher),** Thanks for your hard work in identifying the root cause of the M6.x migration errors. I’ll try your solution on a test instance shortly and will report back with the results. At this point I have very little confidence in the reliability of the upgrade process. I’ve stopped performing Mautic upgrades altogether and instead retrofit later bug fixes into my current version, as this remains the safest way to protect the valuable data in the database. Across this post and others, I’ve highlighted a recurring concern: the Mautic development team is simultaneously upgrading Symfony, delivering minor M6 fixes, and building out new features for the upcoming M7 release. They’re also actively looking to hire developers to add even more new features. Yet it’s clear that testing is not a high priority—otherwise these longstanding issues would have been addressed. The core problem is that upgrade-related issues are consistently overlooked. The team continues forward with new development despite the fact that upgrading from one Mautic version to another remains unreliable. This isn’t simply a matter of limited time or resources; it reflects a lack of focus and will to prioritise and resolve these fundamental problems that affect the entire community. I strongly encourage the development team to refocus their attention on ensuring the current features and upgrade paths work reliably before investing further effort into new functionality, Symfony upgrades, or other major changes. A stable foundation will benefit everyone far more than additional features built on top of unresolved issues. Thanks. ---
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [March 11, 2026, 7:30am UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/12 "2026-03-11T07:30:19Z")
Hello **[mcpatcher](https://forum.mautic.org/u/mcpatcher),** I haven’t tried your solution on M6.x because I didn’t see a need to upgrade minor versions given all the added complexity. Yesterday, I attempted an upgrade from M6 to the latest M7 release and, to my surprise, encountered the same exact upgrade error. To make matters worse, the upgrade process to M7 actually broke the M6 installation, leaving it unusable. I rolled the system back to M6 and everything is working again. > [@Mautic Upgrade Issue: M6.0.3 → M7.0.1 Fails with SQL Error and 500 Internal Server Errors](https://forum.mautic.org/t/mautic-upgrade-issue-m6-0-3-m7-0-1-fails-with-sql-error-and-500-internal-server-errors/37469): > > Hello, I recently attempted to upgrade my Mautic test instance from 6.0.3 to 7.0.1, but unfortunately the upgrade failed and left the system in a partially broken state. I’m posting here to see if anyone has encountered the same issue or has advice on how to resolve it. Environment Mautic version before upgrade: 6.0.3 Attempted upgrade to: 7.0.1 PHP version: 8.3.17 Database: MariaDB 11.4 The upgrade process fails with the following database error: An exception occurred while exe… It’s frustrating to see that after all the effort put into adding new functionality to M7, this issue appears not to have been caught in testing. I can install the update to M7, which stops the system from working, roll back to M6, and then repeat the upgrade—yet it fails for the exact same reason every time. This is only a test instance with sample data, but the upgrade process should still work reliably. I don’t understand why this critical problem seems to be ignored by the developers while attention appears to be focused on fundraising efforts instead. Please fix Mautic upgrades ! Will you fix for M6 upgrades work on M7 ? Thanks ---
**Author:** ![andrew\_c3](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/andrew_c3/32/13547_2.png) [@andrew\_c3](https://forum.mautic.org/u/andrew_c3)\ **Post date:** [March 12, 2026, 2:32pm UTC](https://forum.mautic.org/t/mautic-6-0-2-to-6-0-3-update-can-t-drop-index-mtc-company-match-error/36084/13 "2026-03-12T14:32:56Z")
Hello everyone, I just wanted to share that I’ve managed to successfully upgrade my Mautic test instance from M6.x to M7.0.1. Everything including the UI is now running on **M7.0.1** without any apparent data loss or UI errors. I haven’t tested every feature just the basic UI. It took a bit of troubleshooting and testing, but I eventually found a working approach for the upgrade process that works on my platform every time. If anyone else is struggling with upgrading between versions, there **is definitely a solution**. And I did not have to remove any table prefixes either. I’m happy to share more details if people are interested or facing similar issues if the developers won’t help. Thanks!