SOTI Pulse Logo

Smartphone migration without losing Play Store apps

Solved
GB
Giuseppe, Brando
Aton Spa

Good morning all,

I have a situation I'd like to understand how to solve. 

One of our customers is moving its devices from an old MobiControl instance to a new one. We couldn't opt for an upgrade of the old one for variuous reasons.

Now he needs to move the devices and to do that we sent the mcsetup.ini file with the enrollment ID of the new instance to all the devices currently enrolled in the old one.

With this, the customer can choose when to actually migrate them by simply unenrolling them from the old instance. The agent will look for the mcsetup.ini and then enroll the device again in the new instance.

This is working, no fuss.

The issue is on the applications which were installed from the managed Play Store: in the new instance we had to change the enterprise binding with a new Google account, which means when the devices enroll in the new instance they lose the old enterprise binding and acquire the new one. Even if I selected the exact same applications in the new App Policy, the apps are first uninstalled and then installed again. This is very problematic because the data of all apps are lost, which means the customer needs to configure again every app.

Is this avoidable in some way? The goal would be to DO NOT uninstall the apps.

Thank you

migration application App Policy
2 years ago
SOTI MobiControl
ANSWERS
RC
Raymond Chan Diamond Contributor
2 years ago

Hi Giuseppe,

You have stated clearly you are starting a new instance.  Why waste your time hearing uncertain answers from careless and casual source.

For me,  I am actually quite surprised to see your question and approach.  If what you want  to achieve to retain data of enterprise app from MGP store is easily doable when transferring a device from one MDM server instance to another one, then what level of data security can be enforced by a platform that is named and claims  to target "Enterprise" use.     Can you imagine the consequence of a lost/stolen device with confidential company data from company A get re-enrolled to another MDM server of a competitor company B with the same MGP apps, but the data can still  be read?   

Only in very exceptional cases should one justify to re-enroll a whole fleet of devices from one MDM server instance to another instance, especially for system really designed for enterprise-grade operations such as AEDO or Apple DEP supervised devices.   Building a new instance from scratch not only results in possible loss of private data of individual apps on the device managed by the old instance, but may also result in subtle errors to duplicate back the right control hierarchy and policies with correct parameters, and also loss of log/analytics data collected in the past.      Being able to migrate seamlessly without any devices getting out-of-control of course required expertise and experience, as well as sensible implementation planning ready for unexpected architectural changes in the various device platforms of interest.

One of my customers started from a small all-in-one implementation of a few hundred devices, evolving in steps to multiple DS HA system with many tens of thousands of devices in a period of about ten years. Over the years,  their MobiControl server started from v10.x and incrementally got upgraded to v15.x, MS SQL from 2008 express to 2016 Enterprise, tens of different Android device models from Android 4.x gradually to 12.x  introduced/retired at different paces, host Windows server hardware replaced and IP address changed several times, and changes in some other dimensions too.   However, we've been and are still performing seamless migration/upgrade on the SAME MDM server instance without affecting any of the already enrolled devices and users' data.     This should be the typical way how a good MDM system is to be used  stably within an organization.

Solution
GB
Giuseppe, Brando
2 years ago

Hi Raymond,

I understand and agree with you. We already did, multiple times on both cloud and onpremise instances, the migration from an old to a new instance with the SOTI professional services. I know that is the right way to do it.

In this case it was not possible, because the customer was not willing to pay for the professional services. We warned him about the possible consequences (like this one), but nevertheless I thought it would be nice to try to give him the least "painful" solution. I understand there isn't, but it was worth a shot in order to give the customer a proper service.

As I did in the first place, I'll tell him this is not feasable and he must reinstall all apps from scratch.
Best regards.

Solution
RS
Rafael Schäfer
2 years ago

Not 100% sure but i think you can't, when you do it this way, because:

When you send the "unenroll" (or the "delete") command, always all provided settings (including the  generic managed playstore account) will be removed. With the removal of the generic managed playstore account, the apps will be uninstalled (expected behavior) and only installed again when the device is enrolled to the new Instance when it get's the new generic managed playstore account from there

GB
Giuseppe, Brando
2 years ago

Thank you Rafael,

this was my fear too.

Isn't there any workaround available? For example: if I send the same apps through the packages/profiles disabling the option that uninstall them upon profile revocation, will they "survive" the migration?

RS
Rafael Schäfer
2 years ago

Not sure, but would be easy to test for you on a test device but it could be.

I don't know if there's maybe another possibility to "reassign" (wihch may keep all of thiese things) the devices to the new instance but that should definitely known by Soti.

Just because of interest: It sounds like you don't integrate the "old database" (including all the device information) into the new instance. Is there a reason for that?

GB
Giuseppe, Brando
2 years ago

Hi Rafael,

this is not a clone between two instances where we imported the old DB. They are just two separate instances: old and new. The new one is a clean instance. 

The migration with the DB clone would have required the SOTI professional services, but this was not the case.

We will try the package/profile workaround, if there isn't anything else.

Thank you

RS
Rafael Schäfer
2 years ago

Then, even Raymond can't stop blaming others, he got it in general if you are talking about a completely re-setup. I was assuming that you just want to "transfer" the devices from one server-instance to another. And sorry to say, if you need then the Soti professional services involved (i don't know why this is needed, maybe because you currently use Soti cloud and want to switch to on-prem), that's something to include into that "project" (from technical and cost perspective).

But as just said except the first paragraph, Raymond already said it.

GB
Giuseppe, Brando
2 years ago

Hi Rafael,

I got it, thank you.
Unfortunately the professional services were not an option this time, like we did for other customers. See my reply to Raymond below.

Best regards.

M
MNMOD@SOTI
2 years ago

Hi Guiseppe,

Thank you for posting on SOTI Pulse!

I see that couple of suggestions are made in the discussion. Do any of these work for you? Did you get the information that you were looking for?

If you require any more assistance, please feel free to let us know. If not, feel free to mark the post that solved this issue as solution.

Kind regards,

Technical Support Specialist | SOTI | +1 905.624.9828 | SOTI.net lDiscussion Forum | Log a Case Online l Facebook l LinkedIn l Twitter 

GB
Giuseppe, Brando
2 years ago

Hi, 

in the end I confirmed the idea that what I asked is not feasable, as I thought: newly bought devices will be enrolled directly in the new istance, the old ones still in use will have to be re-enrolled with the inevitable loss of data.

Thank you, best regards.

Similar Discussions