CPanel Transfer Tool Messages about Cpanel Versions and RoundCube

Operating System & Version
Centos 6 and 7
cPanel & WHM Version
86 and 88

RetiredAF

Active Member
Sep 16, 2018
26
5
3
Tucson, AZ
cPanel Access Level
Website Owner
We are moving to a new server to upgrade from Centos 6 to Centos 7 and are at the point of transferring the CPanel accounts. We are using the Home »Transfers »Transfer Tool and when we clicked the Scan Remote Server button we got some messages about which we have some questions. The first message was:

Source: version “86.0.22” …
Target: version “88.0.11” …
The source server is not running the same major version as the target server. cPanel highly recommends that the source server runs the same major version for at least 24 hours to ensure any data conversions have completed.



We don’t understand this as this link https://docs.cpanel.net/knowledge-base/cpanel-product/upgrade-blockers/ tells us we cannot upgrade from CPanel version 86 to 88 on Centos 6. The only way to get to 88 is to get to Centos 7 which is what we are trying to do with this transfer tool. Seems like a catch 22. Any thoughts on this. Are we missing something?

The second message was:

Source: Roundcube database type is “mysql” …
Target: Roundcube database type is “sqlite” …
The source server is not running the same Roundcube database type as the target server. cPanel highly recommends that the source server run the same Roundcube database type at least 24 hours to ensure that email accounts using Roundcube will transfer properly.



This link https://docs.cpanel.net/knowledge-base/webmail/how-to-convert-roundcube-to-sqlite/ provides instructions on how to convert Roundcube to SQLite. It discusses two ways. One would be to convert to SQLite on the source (old server) which appears only to require running a script. The other titled Migrate a Roundcube MySQL database to a SQLite database seems to say to do the transfer and then do the conversions on the target, a much more complicated procedure involving moving the MYSQL database. Is there any benefit in doing it the second more complicated way?
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,304
1,252
313
Houston
Source: version “86.0.22” …
Target: version “88.0.11” …
The source server is not running the same major version as the target server. cPanel highly recommends that the source server runs the same major version for at least 24 hours to ensure any data conversions have completed.



We don’t understand this as this link https://docs.cpanel.net/knowledge-base/cpanel-product/upgrade-blockers/ tells us we cannot upgrade from CPanel version 86 to 88 on Centos 6. The only way to get to 88 is to get to Centos 7 which is what we are trying to do with this transfer tool. Seems like a catch 22. Any thoughts on this. Are we missing something?
Note that this is a warning it is not a failure. It's a warning letting you know that this is not the recommended method of moving forward but in your instance, it is not possible to move to the identical version so in order to move forward you'll need to perform the transfer with different versions.

Source: Roundcube database type is “mysql” …
Target: Roundcube database type is “sqlite” …
The source server is not running the same Roundcube database type as the target server. cPanel highly recommends that the source server run the same Roundcube database type at least 24 hours to ensure that email accounts using Roundcube will transfer properly.



This link https://docs.cpanel.net/knowledge-base/webmail/how-to-convert-roundcube-to-sqlite/ provides instructions on how to convert Roundcube to SQLite. It discusses two ways. One would be to convert to SQLite on the source (old server) which appears only to require running a script. The other titled Migrate a Roundcube MySQL database to a SQLite database seems to say to do the transfer and then do the conversions on the target, a much more complicated procedure involving moving the MYSQL database. Is there any benefit in doing it the second more complicated way?
I would choose to do the first way, the only instance you might need to do the second way in my opinion would be in the event you couldn't make these modifications on the source server for some reason.
 
  • Like
Reactions: RetiredAF