[Vtigercrm-developers] Upgrade bug - 6.5.0 to 7.5.0

[Alan Lord]

Search code.vtiger.com issues for "migration". I've reported loads of 
issues. I am amazed it works at all sometimes.

https://code.vtiger.com/vtiger/vtigercrm/-/issues/?search=migration&sort=updated_desc&state=all&first_page_size=20

HTH

Al


On 19/05/2023 14:44, Steve Kenow wrote:
> Tried it with a fresh 6.5.0 install - same thing.
> image.png
> 
> /*Steve Kenow*/
> Retail Data Systems of Minnesota
> End-User Services & Support Manager
> Direct: (952) 392-2686
> Office: (952) 934-4002
> skenow at rdspos.com <mailto:skenow at rdspos.com>
> 
> 
> 
> Support Questions/Issues? Email rdshelp at rdspos.com 
> <mailto:rdshelp at rdspos.com> (non-emergencies) or call (952) 934-4002 24/7
> 
> 
> On Thu, May 18, 2023 at 10:06 PM Steve Kenow <skenow at rdspos.com 
> <mailto:skenow at rdspos.com>> wrote:
> 
>     It could actually happen when starting at anything less than 7.3.0,
>     from what I can tell.
> 
>     I've been cleaning up and getting ready for upgrading a 650 instance
>     and looking at what should be there and wasn't. One of the things I
>     found missing was the ability for each user to set a default landing
>     page, which was introduced in 7.3.0. My process is to have a clean
>     install of the target version, copy in the custom module files,
>     disable all the custom modules, and then point the new instance at
>     the existing database. Then, open up a browser and navigate to
>     /index.php?module=Migration&view=Index&mode=step1.
> 
>     Everything appeared to go as desired, with the above notable
>     exception. Repeating these steps, I notice that the results page
>     after the migration is complete doesn't have any database upgrade
>     results for 7.2.0 to 7.3.0. Verified files, permissions, etc.
>     Looking at /modules/MIgration/schema/, I notice 73_to_740.php and
>     730_to_740.php, the former just including the latter. This is where
>     that feature should be added, among other things.
> 
>     /modules/MIgration/models/Module.php includes both in the allowed
>     migration versions, which is what caused my problems. The migration
>     gets to 7.2.0 and the next version isn't 7.3, but 7.3.0. So, this
>     step gets skipped. Removing array('73' => '7.3') from the list and
>     starting the migration over does successfully apply all the changes
>     in that step.
> 
>     This led me to look for any other differences in the database
>     schemas of a fresh 7.5.0 install and an instance upgraded to 7.5.0,
>     other than custom fields and modules. There are a lot more than I
>     expected. Some appear to be just cosmetic - like indexes having
>     different names. In other places, foreign keys are added and/or
>     removed, data types are changed, there are even some missing fields.
> 
>     Performance and data integrity are critical to us - how can we
>     improve them both? Are there better options for migrating to newer
>     versions? I'm willing to test more and provide results and feedback,
>     now that I've got a test environment that can load a copy of our
>     database and do a migration in under an hour.
> 
>     /*Steve Kenow*/
>     Retail Data Systems of Minnesota
>     End-User Services & Support Manager
>     Direct: (952) 392-2686
>     Office: (952) 934-4002
>     skenow at rdspos.com <mailto:skenow at rdspos.com>
> 
> 
> 
>     Support Questions/Issues? Email rdshelp at rdspos.com
>     <mailto:rdshelp at rdspos.com> (non-emergencies) or call (952) 934-4002
>     24/7
> 
> 
> _______________________________________________
> http://www.vtiger.com/