Migrating Jamf Pro from on-prem to cloud, any advice?

[thebrucecarter]

Greetings all,

We are migrating from our on-prem Jamf Pro to the cloud product.  We are working with Rocketman Tech as consultants, and with Jamf Support of course.  I just wanted to hear from anyone who has gone through this transition as to things to watch out for, possible problem points, things you would do differently and so forth.  Our "lift and shift" date is January 21, 2025, so we are definitely approaching the critical point in the process.  Any thoughts or comments would be greatly appreciated.

[AJPinto · Accepted solution]

We did this in 2023, my best advice is to ignore the salespeople and demand to talk to engineers BEFORE your cutover date. The salespeople really have no idea what the heck they are talking about.

In our situation, our internal domain is not publicly addressable, and we were told repeatedly that this would not be an issue by the sales and support staff. I was very confused that this would not be an issue but trusted them. Migration date comes and I am talking to the engineer, and in the first 5 minutes we are told this non publicly addressable domain will be an issue and a massive one at that as we needed to go open internet. In the end we had to wipe and load the entire fleet.

If you are migrating you're existing Jamf instance to Jamf Cloud, you need to setup a CNAME redirect to "trick" your devices that the new Jamf server is the old Jamf server. If you want to be open internet, whatever your servers URL is needs to be publicly addressable now, if it's not then the Jamf Cloud server will not be publicly addressable either.

Other than that, the engineer that worked with us was amazing and went well above and beyond to make sure we were buttoned up as best as could be done. Nearly 2 years in, and I have no regrets once so ever, and I am actually thankful we effectively restarted the environment as it allowed us to clear out a lot of tech debt.

[sdagley · Accepted solution]

@thebrucecarter Hopefully you have an on-prem test environment you're migrating first? That's really the only way to have any confidence that your Cloud migration will go smoothly. And are you going with the standard Jamf Cloud offering or Jamf Premium Cloud? You've got a lot more flexibility with the latter (e.g. control over your JSS certificate, restricting access to the JSS console, Global Accelerator so your Cloud instance has fixed IPs, specifying when updates are applied, ...)

[karthikeyan_mac · Accepted solution]

Hi @thebrucecarter ,

You can refer the blog and this video

https://www.jamf.com/blog/migrating-to-jamf-cloud-the-not-so-scary-reality/

https://www.jamf.com/resources/videos/migrating-to-jamf-cloud-without-falling-back-to-earth/

Thanks.

[pete_c · Accepted solution]

Use Prune and clean out the cruft first. Practice with your DNS provider to document how long changes will take to propagate and be prepared with a script to update or flush DNS on the endpoints if necessary. Don't decommission the on-prem side to account for any stragglers or just for post-migration reference. Ask for a sandbox / test environment and use that to verify functionality with any remaining on-prem services like certificates or AD/LDAP.

[AJPinto · Accepted solution]

We did this in 2023, my best advice is to ignore the salespeople and demand to talk to engineers BEFORE your cutover date. The salespeople really have no idea what the heck they are talking about.

In our situation, our internal domain is not publicly addressable, and we were told repeatedly that this would not be an issue by the sales and support staff. I was very confused that this would not be an issue but trusted them. Migration date comes and I am talking to the engineer, and in the first 5 minutes we are told this non publicly addressable domain will be an issue and a massive one at that as we needed to go open internet. In the end we had to wipe and load the entire fleet.

If you are migrating you're existing Jamf instance to Jamf Cloud, you need to setup a CNAME redirect to "trick" your devices that the new Jamf server is the old Jamf server. If you want to be open internet, whatever your servers URL is needs to be publicly addressable now, if it's not then the Jamf Cloud server will not be publicly addressable either.

Other than that, the engineer that worked with us was amazing and went well above and beyond to make sure we were buttoned up as best as could be done. Nearly 2 years in, and I have no regrets once so ever, and I am actually thankful we effectively restarted the environment as it allowed us to clear out a lot of tech debt.

[thebrucecarter]

Greetings AJPinto,

Yes, we did have direct contact with the migration engineer, as well as one of their database people, and that was great.  We did not have the private addressing situation you described as we have global gateway campuses all over the place, so we had to be world accessible from the jump.  We did indeed use the CNAME strategy to not have to change any references or redo any connections.  We also were very happy with the support team that worked with us.

[sdagley · Accepted solution]

@thebrucecarter Hopefully you have an on-prem test environment you're migrating first? That's really the only way to have any confidence that your Cloud migration will go smoothly. And are you going with the standard Jamf Cloud offering or Jamf Premium Cloud? You've got a lot more flexibility with the latter (e.g. control over your JSS certificate, restricting access to the JSS console, Global Accelerator so your Cloud instance has fixed IPs, specifying when updates are applied, ...)

[thebrucecarter]

Greetings sdagley,

We indeed do have a TEST environment on-prem, but we did not migrate it.  It has diverged from the PROD environment so severely over the years and several sets of engineers that everyone involved decided that it was not worth the effort.  We took multiple backups of the database and snapshots of the existing server, and took thorough notes about the DNS changes.  I believe we are on the standard Jamf Cloud with a few tweaks.

[sdagley]

@thebrucecarter I don't think standard Jamf Cloud includes a Sandbox environment so I could see not migrating your test environment first. Hopefully everything went smoothly for your "lift and shift". I'm sure once everything is settled down and running smoothly from the Cloud you won't miss having to deal with updates to an on-prem hosted JSS (I know I don't :-) )

[karthikeyan_mac · Accepted solution]

Hi @thebrucecarter ,

You can refer the blog and this video

https://www.jamf.com/blog/migrating-to-jamf-cloud-the-not-so-scary-reality/

https://www.jamf.com/resources/videos/migrating-to-jamf-cloud-without-falling-back-to-earth/

Thanks.

[thebrucecarter]

Greetings karthikeyan_mac,

Thank you for the references!

[pete_c · Accepted solution]

Use Prune and clean out the cruft first. Practice with your DNS provider to document how long changes will take to propagate and be prepared with a script to update or flush DNS on the endpoints if necessary. Don't decommission the on-prem side to account for any stragglers or just for post-migration reference. Ask for a sandbox / test environment and use that to verify functionality with any remaining on-prem services like certificates or AD/LDAP.

[thebrucecarter]

Greetings pete_c,

Thank you for the Prune reference.  We've been using that for a while, but sometimes we get some wailing from field support staff about how we killed something they were not currently using but planned to use again in the future, so we've had to get a bit more selective about that (as well as encouraging Github repositories).  DNS propagation was kinda spotty for a while, but fortunately the migration team had a bunch of people with different internet providers, so we could keep an eye on that.  Of course, on campus started working right away.  The on-prem is still alive although currently dormant.  We do have a TEST instance set up, although currently it is pretty much empty.  We were fortunately able to disassociate with LDAP and AD and only had to worry about the Okta connection.

[dlondon · Accepted solution]

Maybe you could explain whether your migration will have a change in DNS name or not.  Ours retained the same name and port so that made the transition to the new system easier because as far as the clients were concerned, it was the same system. 

Also does it need access to info on your site regarding users and computers from e.g. a Microsoft Domain?  Do people log in to the Server using Microsoft Domain accounts?  If so, then some form of LDAP proxy will need to be set up.

We engaged with Jamf to work with us on our migration and the Engineer was very competent

[thebrucecarter]

Greetings dlondon,

The DNS name is going to remain the same, and yes, it did make things easier all around.  The Okta integration just carried over all by itself, and once the DNS information propagated beyond campus everything looked pretty good.  No, we don't use much Microsoft infrastructure, although we do have a campus agreement and the Windows guys do use their build and management software.  People log in using our IdP Okta.  We managed to detach from the need to connect to the campus LDAP, which was nice because we didn't have to use Infrastructure Server.  We had consultants (Rocketman Tech) as well as Jamf engineers on for the morning and they were great.

[thebrucecarter]

Greetings all,

Apologies for the delay in responding, we were all caught up in actually planning for the migration.  D-Day was today, and it seems to have gone pretty well, although it's only been a few hours.  I'll drop responses to each of the replies above, thank you for your thoughts!