Post upgrade failed 9.3.0 > 10.0.0

Dear Michael,

We are upgrading clients local instances to the latest version 10.0.0 from 9.3.0 for the clients hosted in sugar cloud and development / QA instances are on our local server. We have created separate server with below supported platform for upgrade activity. but 5 clients instances failed in POST upgrade stage.

OS: CentOS 7

MySQL: 5.7

Apache: 2.4

PHP: 7.3.17

Elasticsearch: 6.2.4

To Check upgrade issue in SugarCRM 10.0.0, we have created default 9.3.0 instance by downloading setup files from community ( and upgraded it using silent mode to 10.0.0. In the upgrade process, we have used upgrade bundle and silent upgrade files from community site (silentUpgrade-PRO-10.0.0-dev.1,

Result: Post upgrade failed, see attached failed instance sugar and upgrade log file.

We have applied permissions on failed instance and able to login to the instance which is showing version 10.0.0 but on the click on any module it is showing “Render Failed error”. We are unable to View/create records in any module.

We have followed SugarCRM installation and upgrade guide, we have also tried to upgrade client instances but all these instances failed in post upgrade step.

We are about to upgrade all the local development and QA instance for the clients and it is important for us to resolve this issue ASAP as could hosted instances are scheduled to upgrade and some of instances are already upgraded.


We have raised case #394705 to SugarCRM support and they replied below note.

Requesting you to please check the issue in upgrade package and provide us updated upgrade package to test it again.

The upgrade was not completed successfully because of the following error

Sat, 09 May 2020 22:39:12 +0530 [Upgrader] - ERROR: Exception: An exception occurred while executing 'INSERT INTO saved_reports (id, name, date_entered, date_modified, modified_user_id, created_by, description, deleted, module, report_type, content, is_published, chart_type, schedule_type, favorite, assigned_user_id, team_id, team_set_id, acl_team_set_id) VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["0a76a768-fecb-11e9-8516-acde48001122", "Cases That Missed the First Response SLA", "2020-05-09 17:08:43", "2020-05-09 17:08:43", "1", "1", "The number of cases that missed their first response SLA in the last 7 days. The time period can be changed using the run-time filter.", 0, "Cases", "Matrix", "{\"display_columns\":[],\"module\":\"Cases\",\"group_defs\":[{\"name\":\"date_entered\",\"label\":\"Day: Date Created\",\"column_function\":\"day\",\"qualifier\":\"day\",\"table_key\":\"self\",\"type\":\"datetime\"},{\"name\":\"user_name\",\"label\":\"User Name\",\"table_key\":\"Cases:first_response_user_link\",\"type\":\"username\"}],\"summary_columns\":[{\"name\":\"date_entered\",\"label\":\"Day: Date Created\",\"column_function\":\"day\",\"qualifier\":\"day\",\"table_key\":\"self\"},{\"name\":\"user_name\",\"label\":\"User Name\",\"table_key\":\"Cases:first_response_user_link\"},{\"name\":\"count\",\"label\":\"Count\",\"field_type\":\"\",\"group_function\":\"count\",\"table_key\":\"self\"}],\"report_name\":\"Cases That Missed the First Response SLA\",\"chart_type\":\"vBarF\",\"do_round\":1,\"chart_description\":\"\",\"numerical_chart_column\":\"self:count\",\"numerical_chart_column_type\":\"\",\"assigned_user_id\":\"1\",\"report_type\":\"summary\",\"layout_options\":\"2x2\",\"full_table_list\":{\"self\":{\"value\":\"Cases\",\"module\":\"Cases\",\"label\":\"Cases\"},\"Cases:first_response_user_link\":{\"name\":\"Cases 
\\u003E First Response User\",\"parent\":\"self\",\"link_def\":{\"name\":\"first_response_user_link\",\"relationship_name\":\"cases_first_response_user\",\"bean_is_lhs\":false,\"link_type\":\"one\",\"label\":\"First Response User\",\"module\":\"Users\",\"table_key\":\"Cases:first_response_user_link\"},\"dependents\":[\"group_by_row_2\",\"display_summaries_row_group_by_row_2\"],\"module\":\"Users\",\"label\":\"First Response User\",\"optional\":true}},\"filters_def\":{\"Filter_1\":{\"operator\":\"AND\",\"0\":{\"name\":\"date_entered\",\"table_key\":\"self\",\"qualifier_name\":\"tp_last_7_days\",\"runtime\":1,\"input_name0\":\"tp_last_7_days\",\"input_name1\":\"on\"},\"1\":{\"name\":\"first_response_sla_met\",\"table_key\":\"self\",\"qualifier_name\":\"is\",\"input_name0\":[\"No\"]}}}}", 1, "vBarF", "pro", 0, 1, "1", "1", "ce2b06e2-9217-11ea-9716-525400bc1097"]:
Duplicate entry '0a76a768-fecb-11e9-8516-acde48001122' for key 'PRIMARY'

The 10.0.0 upgrade, in Step 4 will try to insert some new Reports and according to the above, one of the reports tried to use an existing/duplicate ID.

This is not something related to the platform thus the 'applied permissions' that was done after the upgrade would not solve the issue because the upgrade didn't complete all the required steps.

The upgrade contains 9 steps. The missing steps 5 - 9, apply many changes and migrations that are required for Sugar 10 to work as expected which explains why your test upgrade instance was totally broken.

When testing a 9.3.0Ent clean to 10.0.0Ent upgrade locally via silent upgrade (With the packages that are used in our Cloud environment), my upgrade is completed without any errors thus the issue could be with the 'Dev' installer/upgrader and not related to the GA release of 9.3.0 > 10.0.0.

As per the 'Sugar Cloud Developer Build Guidelines' ( ), any issue related to the developer builds should be reported there so that the team that is handling those packages can correct them.

I tested also the 'dev-1' upgrade locally and I received the same error as your test.

I would recommend posting the issue that you are experiencing in the Developer Builds community ( )