in-place upgrade GMS 14r2 to 18 supported?

I see in the docs that the only path is a new box, but has anyone done an in place upgrade as I thought some here had done so. (I searched but came up with everything else but)

upgrade path from Mobility 2.x/14.x to 18.x is to create a new Mobility server and install Mobility 18.x on that server.

while that is a good idea for any system that has been up a while, is it really needed, and why?

The client I am looking at has a fairly new GMS box on SLES12.4 (built as 12.3 and soon updated to .4), so am trying to understand how necessary is it for us to go through that effort.  I was also hoping to get this one upgraded before 'Fall back' as I'll be in a good spot to monitor this system during that repeated hour where I've seen GMS problems before (one part appeared to stop running in that hour, please set your GMS logging to debug during this time if you can).


  • Wow, that's new. There used to be documentation how to upgrade inplace to 18, and while you had to be careful to strictly follow the docs, it was (is) absolutely doable if you understand the system.
    I did it as recently as a month ago, and since there has been no new code since then, it obviously must still work.

    I have to assume that too many customers throught they could shortcut the documented way, failed and then complained. For instance, if you update from SLES11 / GMS2014 too, you *MUST* upgrade to SLES12 *SP2* first. Absolutely no exception, if you use any other media than SLES12 SP2, it'll break.

    As you are already on a supported SLES12 version, I see totally no reason why the upgrade shouldn't work.

  • I'd guess this part of the docs has recently been added due to the reasons Massimo mentioned (i.e. people skipping steps and furtheron blaming the product). Many people (including me) have successfully upgraded many times. You might also want to check this one


  • ah ha,  TID7024020

    that is what I was looking for.  had seen it on my hunt and then closed that tab and the search tab I found it in by mistake.

    Thank you both of you for restoring some of my sanity (as little as there is).  I'd done the whole new box at other clients who were making the bigger jumps, where as this one had to do it for other reasons before the rest of system was on 18 and I thought I was ready for it.   

  • Upgrade done and superficially looking OK, but high device sync rates,  with total Device Requests per minute hovering at 300 and some users reporting buzzing devices where folders and contacts are disappearing and reappearing, though with no correlation to their device's  request rate (some with zero showing have this happening and others with high rates are just fine.)


  • Any correlation to device types and their OS version? Sometimes devices start behaving crazy if they're facing a new ActiveSync version.


  • Any correlation to device types and their OS version? Sometimes devices start behaving crazy if they're facing a new ActiveSync version.

    So far have only seen it on some droids of differing versions.   pity we can't readily see a list of all devices with versions as GMS sees it.

    Things appear to have settled out overnight. with no more reports beyond one of the 2nd person to report as her Android 9 device still shows as Activesync 14.1 and only the last week of email vs the 30days we are set to,  where as others who had issues show as ver 16.0

    Perhaps this 'fun' was one of the reasons the docs withdrew the upgrade path beyond what has been discussed here already