Transitioning from on-prem to Jamf cloud stories

Commenting to see people's responses.

Its actually super easy if you plan it well in advance, here's what I suggest :

1. Enrollment/ Re-Enrollment, you can actually have your cloud instance created while your on prem is still up and running if am not wrong, replicate all your polices, configuration profiles, patch management policies and so on... reverify everything is in place and then create a enrolment package using recon connected to your cloud instance, deploy/push the same using your on prem server.

Trust this solves your major part...!!

@PhillyPhoto Just so you have the Jamf-y answer too :) We do have Jamf Professional Services - Migration Services available to help with the transition especially for URL changes that might occur. Also when you go with Jamf Cloud you do receive Jamf Cloud Distribution service (JCDS) as part of the subscription license therefore no need for you to create another box/FTP account somewhere else. Third if deferral of the Jamf Pro upgrade is major for you, we just introduced Jamf Cloud Premium that allows you to control the upgrade cycle of Jamf Pro: https://www.jamf.com/resources/product-documentation/jamf-premium-cloud/ I hope this helps a little. I'm sure others will fill you in on their experiences.

no hyjack...just additional interest: Speeking of software and package deployment. How long will it take to up/download - lets say - and Office package? Because cloud means internet and internet means external internet speed.
Thats my biggest consern having Jamf Pro and the Package Distribution onot on premise.

Thanks for the feedback everyone. Part of me would want to make a clean transition and start with fresh policies and smart groups etc and cut down on all the "fluff" that's built up over the years lol. I can only imagine the work involved in recreating most of it though. I actually have some Jamf people stopping by here in the next hour or so, and hopefully they can give me some insight as well.

@tsossong That worries me a little too. I guess you could script it to go to macadmins.software or pass the URL as a variable and have the end user's machine run a CURL script and download it. Something that big might timeout on the D/L though...

We used professional services to help migrate. I've been told that they learned a lot with our migration.

We didn't have to re-enroll as we had our DNS name point to the new server. Once we made the cut over, everything worked like it should. No re-enrollments needed.

We have JIM set up in our environment, which is working fine. Our security team wouldn't allow us to have a direct link, even just read only, into our LDAP environment so the JIM was the best solution for us.

We still have some on-prem DPs as well as the JCDS. We use the JCDS for our general software including the Adobe Suite and Office.

For updates, we schedule with them once we've see there are no issues and so we can arrange it with our internal teams. We sometimes go quicker depending on what bug fixes are done with the current version. Jamf has been very accommodating with that for us.

We paid for Dev/test hosted server, because we put Jamf though the security ringer for years (yes years). That allowed us to test the download speeds and how our network behaved. I bet if you ask nice they will let you demo a hosted environment or you could test in the beta program.

C

PS it's slower than on prem, but only we only noticed it on the big .pkgs like Office in our environment. All the pro's (namely me sleeping better at night) completely outweigh any downsides we could find when we moved. We are way beyond happy that we moved to hosted.

PSS if you are using Azure AD/Intune you can ldap sync to that now... There is a post here about that...

PSS

I started out wanting a new clean database, but after thinking about FileVault keys I gave up and and moved the "fluff" in-use database to the hosted "new" environment.

@gachowski We are researching moving to Jamf Cloud and our initial thinking is also to start with a new clean database. For one, our server is NAT'ed so any off-prem devices cannot talk to our on-prem JSS but we also likely have quite a few Macs sitting in storage for many months of have been replaced but not deleted from the JSS. The thinking is that starting clean would weed out those devices that we actually no longer have. However, like you I also have thought about the FileVault key issue and we would have at least half of our 4500 Macs to rekey if we started clean.

I also recently thought about how we would get all of our iPads re-enrolled AND re-supervised on the new clean Jamf Cloud setup. Wouldn't we have to wipe/reset the iPads and walk through DEP enrollment all over again to make sure they are supervised with the new server?

Since you decided to move "fluff" and all to the Jamf Cloud did you see any issues, or has it been running better than expected?

@spalmer

Way better, I don't really think about the "fluff"anymore. I think when they move the database they "clean it up" too. That said we did have some issues with a few machines that didn't sync up to the new server, but I am blaming the "fluff" and it wasn't enough to have our support team panic. jamf manage or sudo jamf reenrol fixed them up...

I am not sure on the iPads we only have macOS devices. However from a logic point of view if you start with a new database then you have to start over with all your iPads, moving the database you get to keep them up and running.

C

C

We currently have two JAMF Services, Pro and Cloud and are looking to merge the two.

JAMF Pro - ~450 MacOS, ~900 iOS
JAMF Cloud (Keep) ~4000 iPads now

From reading this and other threads the Mac Side is less of a problem it can be done as part of our annual lab refresh and for staff devices a script to unmanage then add to the new service we'd do it with a package then have 2nd line pick up any that don't transition and pick it up when a mobile user needs to install something from Self Service.

For iOS devices what is the user experience going to be? I'm assuming worst case is every device has to be erased re-DEP'd

Is this possible?
Would setting up a third and migrating both work better?
What sort of timeframe would we need for the migration?
Does anyone have any experiences merging JAMF instances?

Quick question for those who have already completed this migration, or are planning to. How are you addressing DEP enrolled devices where the Pre-Stage does not allow the removal of the MDM? Are you actively erasing and restoring those devices to move them o the new environment, or is there another way that this can be done on the back end/through scripting?

@cpresnall We had a conference call with the Jamf Cloud sales people early last fall and we are getting close to pulling the trigger on moving to Jamf Cloud as well.

You will want to look at Jamf Premium Cloud, https://www.jamf.com/resources/product-documentation/jamf-premium-cloud/, as it allows you to have a custom URL, including using your existing URL/DNS name.

In a followup email after the conference call the Jamf Cloud sales person told us the following:

Lastly, when it comes to why we don’t have to re-enroll your iOS devices when using JamfCloud Premium, I was told that in most cases, they’ll continue to use your current Jamf Pro URL and certificates in JamfCloud.

If you have enough iOS devices it will be well worth it not to have to touch every device, wipe it, and re-enroll it. Especially in scenarios like ours (Higher Ed) where those devices may be checked out for many weeks by students, off campus, or even out of the country with faculty that travel.