[Vtigercrm-developers] Upgrade bug - 6.5.0 to 7.5.0

Steve Kenow skenow at rdspos.com
Fri May 19 17:51:21 GMT 2023


So, are you using custom scripts for migrating?

*Steve Kenow*
Retail Data Systems of Minnesota
End-User Services & Support Manager
Direct: (952) 392-2686
Office: (952) 934-4002
skenow at rdspos.com



Support Questions/Issues? Email rdshelp at rdspos.com (non-emergencies) or
call (952) 934-4002 24/7


On Fri, May 19, 2023 at 9:28 AM Alan Lord <alanslists at gmail.com> wrote:

> 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/
> _______________________________________________
> http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20230519/69cc85c5/attachment.html>


More information about the vtigercrm-developers mailing list