Jamf-migrator tool

Data won't be deleted from the source server. It'll only be copied to the target server.

Awesome. That is what I thought.

Yes @dan.snelson , mySQL BU before the migration of course ;)

Thanks All!

I wasn't even aware of it until you mentioned it here.....

This will be extremely useful to us, so thank you very much!

Welcome to the Nation, @scottlep! Glad to have you here.

I have used a different JSS Migration tool with great success in the past.
https://www.jamf.com/blog/make-your-jss-feel-new-again-with-the-help-of-api/

How does the JAMF tool compare? Also, I noticed you can migrate the endpoints in the JAMF version. How does this work with FV keys, cert based trusts between JAMF instance etc?

Both @jcompton's script and @leslie's app use the Jamf API. One is a script you must run in Terminal and the other has a GUI.

Jeff's script is not written to migrate computer, mobile device or user objects. But it migrates most every other type of object such as configuration profiles, policies, groups, advanced searches, etc.

Leslie's app will migrate computer, mobile device and user objects. But it still needs some work to get more of the objects related to mobile devices such as advanced mobile device searches.

I use either depending on what works better for my needs at the time. If Leslie's app won't migrate something, I'll use Jeff's script.

Leslie may correct me, but I don't believe FileVault keys can be migrated with computer objects.

@leslie Will your migration tool pull Computer FV keys?

Hi @talkingmoose ,

If you could share the Jeff's script here , it would be really helpful . Since I am involved in the process of migrating from casper instance into Jamf Pro.

Also if you could help me to pull complete policies details instead of pulling it from JSS summary , i would like to export only the policy details in excel .

@talkingmoose, etc...

Where might one find Jeff's script, I would like to try it.. I got "most" of the data migrated using JAMF Migrator, but only 500 of 900 plus polices, and every box is checked (except Computers, which one would think you do not need). Thx in advance, jk

FileVault recovery keys are not accessible via the API, so no migration tool which uses the API will be able to access or export FileVault recovery keys. For more information on how Jamf secures FileVault recovery keys, please see the link below:

https://www.jamf.com/jamf-nation/articles/314/security-of-filevault-2-recovery-keys

@johnpklimeck One thing that may not be clear about Jamf Migrator is that you'll have things fail to copy if something they depend on doesn't already exist on the destination server. For example, a Smart Groups that contain other Smart Groups and one or more of the nested groups was added after the containing group was created is a problem because it requires an item with a higher ID than its own. Running Jamf Migrator multiple times with just Smart Groups selected should eventually succeed in transferring all of them. Once that's done you might have better luck with migrating your Policies.

@johnpklimeck, you'll find Jeff's scripts here:

https://github.com/igeekjsc/JSSAPIscripts

It's also linked in the blog post mentioned above.

@talkingmoose do you know how @leslie 's app handles enrolling devices into the new environment?

@tylalonde, Jamf Migrator isn't an enrollment tool. It simply copies data from from one Jamf Pro server to another. If you need to migrate to a different server, you can still copy policies, profiles, scripts, etc., and you can copy computer records too. But if the second server's URL is different, you'll need to re-enroll.

@talkingmoose got it, thanks. Was hoping to not have to enroll 1000 devices on the new (differently name) server :S

@tylalonde Are the devices you need to migrate Macs, or iOS devices? If they're Macs, were they enrolled manually or via DEP/ADE? There is another tool for re-enrolling Macs with a different JSS, but I don't know that it'll work with DEP/ADE enrolled Macs, and you may also need a Jamf Professional Services contract for access to the tool.

@sdagley They are iOS devices manually enrolled.

@tylalonde That is unfortunate

@talkingmoose : I have 1000+ mac devices in my current domain jss.old.com and I'm going to migrate completely new server jss.new.com. I can copy all the settings using JAMF Migrator tool, However all the clients needs reenrollment right?

Is there any easiest way to do this without user interaction on the reenrollment part ?

@gsabari, there is no magic answer to migrating devices from one Jamf Pro server to another. The solution you choose depends on a few things:

1. Can the MDM profile on your Macs be removed by clicking the minus button ( - ) below the list of profiles and entering an administrator password? If so, you could create a Policy on the old server to run a script to remove the old profile and install a QuickAdd package for the new server. But someone will still need to click the Approve button for the new MDM profile. If the profile can't be removed this way, you'll need to remove it by sending a command from your old Jamf server and then coordinate to enroll into the new server as quickly as possible to remain managed.

2. Are your Macs enrolled in Apple Business Manager or Apple School Manager? If so, are you able to associate them to your new Jamf Pro server and run /usr/bin/profiles renew -type enrollment to enroll them to the new server?

3. Are you comfortable including your end users in the process to migrate? You can put a script to remove the old profile and the QuickAdd package into a Self Service policy.

4. Do you have technicians who can assist end users with the migration? Maybe they can do the work instead of the end users.

5. Is it possible to wipe the Mac, re-install the macOS and allow end users to proceed through the Setup Assistant on their own? This would ensure an approved MDM profile.

6. Is your goal simply to move to new server hardware or to Jamf Cloud? If so, you can migrate the MySQL database to keep everything and then point your Jamf Pro URL to the new server. This is the easiest to do and you keep all settings, logs, etc.

You have several options, but each has its benefits and drawbacks.

@gsabari you should follow the advice in this Jamf Nation article. In summary: backup and restore the database to a new server, then alter the DNS records to point “jss.acme.com” to the new server.

https://www.jamf.com/jamf-nation/articles/122/migrating-to-another-server

If this is about https://github.com/jamf/JamfMigrator, I'd say it's not the most robust to my environment but it does most of the important work while leaving some items requiring manual work on the destination, such as the stuff I pasted below. As for config profiles involving a system extension, I had to delete and re-create it on the destination server to get it to push without errors. Rebuilding the LDAP user groups is also quite a pain if the permissions are heavily customized because jamf-migrator currently converts LDAP user groups to standard groups on the destination server.

One important lesson learned for me that I'd like to share is when migrating again from scratch or for real, do all devices first, then do smart/static computer groups (which has its own migration issues with jamf-migrator if any of them reference another computer group) before doing config profiles and policies. If any of your policies have any users and user groups in the scope, migrate those first before the policies. These suggestions are just to minimize "yellow" statuses as much as possible.

Here are the limitations from the above website and I'm pasting here for everyone's convenience:
Passwords can not be extracted through the API which impacts migrating distribution points, computer management account, account used for LDAP - credentials must be reset on the destination server.
Icons associated with Mac App Store apps are not migrated (can't be migrated).
Only AFP and SMB shares can be migrated.
Patch management is not available through the API impacting smart groups dependent on patch management extension attributes.
Buildings - the API only allows the name to be migrated.
If endpoints (computers, policies, configuration profiles...) have duplicate names on the source server issues will arise if the app is used to update those items from the source to destination server. As each item is migrited it will overwrite the previous item with the same name.
Migrating smart/static groups with criteria containing groups will fail if the parent group tries to migrate before the group in the criteria. Migrating groups several times should allow all the nested groups to migrate before the parent group.
Institutional disk encryptions that contain the private key cannot be migrated.
Approved Kernel Extension payloads that contain bundle IDs will be dropped from the Configuration Profile.
Approved Kernel Extension - the display name for the Approved Team ID does not migrate.