Migration from On Premises JSS to Cloud Hosted JSS Experience and Preparation

[AFlandez]

Our company has made the decision to migrate our On Premises (Currently on v.9.96) to the Cloud Hosted JSS instance. We are slowly integrating Macs into the Enterprise environment with almost 280 Macs globally (North America, Europe, and Asia) and will be growing by end of this fiscal year. So far, the experience has not been well received by my IT Management and Systems Engineering. The documentation/guidelines are not very detailed by JAMF. I'm curious if anyone else has different experience thus far and if there are any other guidelines/documentation you have used prior to the scheduled migration session (8 Hours total; Qty: 2 - 4 hour sessions). I'm new to migrating from On Premises to Cloud Hosted JSS so there is no "Easy" button per se. We have already completed the JAMF CDBSA and next process is the actual migration process. Other than the article on Inbound/Outbound IP Range for Firewall, there isn't much information on what else needs to be performed on company side unless there is a checklist somewhere else I haven't seen here or from JAMF? Any suggestions or advice greatly appreciated.

[blackholemac]

Ill preface by noting I do not have first hand experience, but I have experience moving from one type of server host to another and migrating from a single machine to a cluster.

In short, they are simply going to take over your JSS enrollment URL somehow, your going to send them your database somehow and they are going to fine tune settings for you on the Tomcat side.

They are probably also going to do lots of talking about how you are going to get an opening to get AD integrated properly and probably a much lengthier conversation about network ports, both on your side and theirs.

It's obviously more detailed than that. I know they will likely do a lateral move on the same JSS version. They are also going to probably have an in depth discussion about uptime levels and contracts and such. Probably lots of post migration testing and verification. When we migrated to a cluster internally, it was about getting all the ducks in a row with a plan for months ahead of time, pulling the trigger for changing over in about 30 minutes or less and lots of time verifying everything was working after the cutover.

Like I said though, I defer to someone who has actually done a migration to the cloud.

[jgwatson]

We were hoping to do this until we were told we would have to unenroll everything out of our locally hosted jss, and then enroll everything back into the new one. Non starter for us until Apple allows this to happen more easily.

[RobertBasil]

@jgwatson

That's not the case if you keep the same FQDM the same as it is on your internal network. We kept the same FQDN and didn't have to re-enroll anything.

@aflandez

I'd love to give you some advice but to be honest it's been so long since we've moved I don't remember much of what we did. I do remember is was pretty painless though.

[AFlandez]

@@RobertBasil I'm hoping for the actual migration process to be painless but dealing with the logistics/paperwork is not so delightful. We aren't starting with a "fresh" Cloud Hosted JSS so we had to complete the JAMF CDBSA (Standard Formality) for migrating the On Premises db to Cloud Hosted JSS. I'm glad your experience seemed painless. Not so much on our end thus far. Thanks for the input. Much appreciated.

[RobertBasil]

@AFlandez

Feel free to shoot me an email and I'll reply with my phone number. I'd be happy to discuss our migration over a call if you are in the U.S.

basil.robert@cusd80.com

[jgwatson]

@RobertBasil no way! We heard that from our jamf buddie so just assumed it was gospel.

[psliequ]

To my knowledge all JamfCloud instances must have a URL scheme like "https://yourcompany.jamfcloud.com" so unless you've created an internal DNS SOA for jamfcloud.com in your environment a URL change will be required. for macOS, there are ways to transition that are not that painful. For example, with both Jamf environments still up, issuing one last policy from the old environment that does a fresh enrollment into the new environment (many details and particulars omitted for brevity.)

For iOS it's more difficult depending on the conditions under which they were enrolled. If they were enrolled by the user or enrolled under a BYOD scheme, the user has to be trained how to remove the MDM enrollment profile and then be issued a new one. For most types of DEP enrollment or devices that were supervised with Configurator a complete factory reset is required.

[RobertBasil]

@jgwatson and @psliequ

When we ran on premises our JSS had the address of https://jamf.ourcompany.com Now that we have it hosted by JAMF we just pointed our https//:jamf.ourcompany.com url to the https://ourcompany.jamfcloud.com ip address in our DNS A record and we didn't have to re enroll or create a new policy for any of our iOS or MacOS devices at all.

[Emmert]

Very clever!

[psliequ]

@RobertBasil Have you found that new device enrollments also work without issue? Do you direct newly enrolled devices to your company URL or directly to the JAMFCloud URL?

[RobertBasil]

@psliequ

New device enrollments work just fine.We enroll to our company URL just like we did when we hosted on site.

[psliequ]

@RobertBasil That's good to hear. Are these DEP enrollments or user initiated/Casper Imaging based enrollments?

[RobertBasil]

@psliequ

iOS we use a combo of DEP and User Initiated, MacOS we initiate the enrollment, no imaging.

Our devices are multi user and we don't allow the user many rights on them being a School District.

[rirwin1]

@RobertBasil We are just about to embark on an on premises to Jamf cloud migration. The question in front of us this morning was Standard vs. Premium Cloud hosting and which would provide the best result. We run Jamf Pro 10.6 and mostly 10.12.6 and 10.13.x. computers, not currently any iOS devices. We currently do DEP and user based web enrollment and VPP application device based assignment

Here's what they offer
Jamf Premium Cloud: Jamf will host our url and the cutover is "seamless" as per Jamf and the migration can be cutover in one fell swoop, albeit at @ 20K/Year premium above standard as per Jamf
Jamf Cloud Hosting: new url and re-enrollment required to secure user approved MDM, but cheaper. Macs can also be "batched" in this scenario, which might be good as we have different regions

However, reading your 4/19/17 Post. Looks like repointing your Corp url A record to the Jamf hosted Url has worked with preserving the enrollment, so a couple of questions:
•Has User Approved MDM remained valid in High Sierra 10.13.x? It looks like might hav done this a while ago when user approved MDM hadn't been rolled out yet. Wonder if it there were any issues with that. I know a url changed will break that.
•What Jamf/Casper version and Apple OS version(s) were you on at the time of your migration?
•Does the hosted IP address ever change and the A record require admin: assuming you're on standard cloud?

How is your migration scheme is working at this point in time, since your last post? Looking back, what might you say to someone doing this migration now.

[KSamuels]

@RobertBasil is there a reason you did the DNS via an IP in an A record vs just removing the A Record and making a CNAME to the cloud instance?
Using a CNAME would ensure if the IP of the Cloud server changed (load balancing etc) the old url would still resolve to whatever the current IP of the cloud instance was.
I'm just about to migrate and was going to make the CNAME just wondering if i'm missing something and should use the A record instead.