<div dir="ltr">Alan, my understanding was that when you execute, for example, the migration script from 6.4 to 6.5, the vtiger.zip gets first unzipped with the files that are changed/new in vt 6.5. So you effectively have vtiger 6.5 code. THEN the database migration script gets executed. And my assumption was that such script would rely on being executed in the vtiger 6.5 code context. Using your method, all those database migration scripts would be run against your final target vtiger version (say 7.5). But from what you say, it seems that there is no such dependency  and that all database migration scripts can be run against vtiger's last target version (say again 7.5). Are we on the same page?  </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 26, 2023 at 9:47 AM Alan Lord <<a href="mailto:alanslists@gmail.com">alanslists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nope I've never had an issue actually, and if you think about it, when <br>
you start the upgrade process from the UI, the first thing it does is to <br>
extract the latest vtiger upgrade zip file which overwrites the changed <br>
core files anyway - so if a function was dropped the file would be <br>
changed anyway?<br>
<br>
I've only had this issue really when going from v5. So I do a 2 stage <br>
process from v5 to v6, then v6 to v7. But then I need an old server to <br>
do that anyway because getting v5 to run on anything more than php5 is a <br>
PITA ;-)<br>
<br>
HTH<br>
<br>
On 26/07/2023 16:21, Rubén A. Estrada Orozco wrote:<br>
> Hi Alan,<br>
> <br>
> I've always been hesitant to follow the procedure you mention (and have <br>
> in fact never tried it) because of the following: What if one migration <br>
> script along the chain relies on code of a specific version that is not <br>
> the latest you are migrating to?<br>
> Hypothetical example: I migrate from 6.2 to 7.5. Following your <br>
> procedure you have vtiger 7.5 code base when executing all the migration <br>
> scripts. Now let's say that the migration script from 6.4 to 6.5 relies <br>
> on vitger's 6.5 code. And that the same code wouldn't work using Vtiger <br>
> 7.5 code.<br>
> <br>
> Haven't you had that situation?<br>
> <br>
> On Wed, Jul 26, 2023 at 1:03 AM Alan Lord <<a href="mailto:alanslists@gmail.com" target="_blank">alanslists@gmail.com</a> <br>
> <mailto:<a href="mailto:alanslists@gmail.com" target="_blank">alanslists@gmail.com</a>>> wrote:<br>
> <br>
>     On 25/07/2023 18:50, Steve Kenow wrote:<br>
>      ><br>
>      > Having gone through a migration using all the steps of the UI, I<br>
>     know<br>
>      > that I get prompted to deactivate any custom modules before<br>
>     proceeding.<br>
>      > What's the 'right' way to do this and have the menu entries built?<br>
>      ><br>
> <br>
>     I generally to use a modified set of migration scripts when moving from<br>
>     significant version to version, e.g. v5.x to v7.x or v6.x to v7.x, and<br>
>     run them from the command line.<br>
> <br>
>     The process I use is something like this...<br>
> <br>
>     1. Install a completely new and clean 7.x. system (or whatever is the<br>
>     latest version)<br>
> <br>
>     2. Copy the custom module code into this clean vtiger and then modify<br>
>     the code/port the extensions so they work correctly in your new vtiger<br>
> <br>
>     <a href="https://docs.google.com/document/d/1ud-ddTHFfKeuJ6DciVJHNr8B5IR_v_gEBvPXa9TFbZs/edit" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1ud-ddTHFfKeuJ6DciVJHNr8B5IR_v_gEBvPXa9TFbZs/edit</a> <<a href="https://docs.google.com/document/d/1ud-ddTHFfKeuJ6DciVJHNr8B5IR_v_gEBvPXa9TFbZs/edit" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1ud-ddTHFfKeuJ6DciVJHNr8B5IR_v_gEBvPXa9TFbZs/edit</a>><br>
> <br>
>     2. Extract your source system and copy over the /storage and /test<br>
>     directory contents (You can install it alongside - sometimes that helps<br>
>     when testing stuff).<br>
> <br>
>     3. Drop the clean vtiger database and import the source vtiger database<br>
>     into the clean system<br>
> <br>
>     4. Run the migration scripts, in-order, within the new system<br>
> <br>
>     5. Clean up anything that's broken ;-)<br>
> <br>
> <br>
>     HTH<br>
> <br>
>     Al<br>
> <br>
> <br>
>     _______________________________________________<br>
>     <a href="http://www.vtiger.com/" rel="noreferrer" target="_blank">http://www.vtiger.com/</a> <<a href="http://www.vtiger.com/" rel="noreferrer" target="_blank">http://www.vtiger.com/</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> <a href="http://www.vtiger.com/" rel="noreferrer" target="_blank">http://www.vtiger.com/</a><br>
_______________________________________________<br>
<a href="http://www.vtiger.com/" rel="noreferrer" target="_blank">http://www.vtiger.com/</a></blockquote></div>