Skip to main content
Question

Jamf Pro on-prem to cloud migration

  • August 27, 2018
  • 6 replies
  • 32 views
P
Forum|alt.badge.img+13

We've finally got approval to transition to the Jamf Cloud when our contract renews at the end of September. I'd really like to start fresh and run an enrollment package on existing devices to not carry over the bloat from our current JSS and make sure only active Macs get registered. We have 905 Macs in our inventory, but only 797 have checked in within the last 90 days (what we consider to be active). Being charged per-device, I want to get a true look at our numbers when we move over. I would also like to clean up some of the inventory data and only track what is absolutely necessary and not all the extension attributes that we have now.

I know Jamf offers a day long migration with them, but I'm wondering what people have done when they migrated. My main questions are:

  • Is there any advantage to just essentially copying/pasting the existing DB and then trying to clean up that?
  • Does re-enrolling devices bring the FileVault recovery key over, or would I have to run a script to generate a new one? Is the key in plaintext in the DB so we could run a SQL command to output the serial number and key?
  • I'm sure there would have to be MDM push cert and VPP/DEP cert enrollments as well, what is that process like in regards to transitioning and having the devices recognize the new ones vs old ones?

    6 replies

    G
    Forum|alt.badge.img+16
    • gachowski
    • Honored Contributor
    • 1054 replies
    • August 27, 2018

    When we moved, Jamf strongly recommend moving the database... I think it's only way to move the FDE keys and that was the only thing I was really worried about. The key is encrypted in the DB. I do know that they do "check/verify" the database before upload it to the new server...and in our case with about 3,000 machines it did take a few hours...

    After thinking about all the details you bring up I kinda guessed that it would take more time to manually clean up the database, but it would be an much easier transition to the cloud keeping get old DB... less over all downtime and I wouldn't miss anything trying to set up a new environment.

    Sorry I didn't answer your questions : )

    C

    N
    Forum|alt.badge.img+4
    • nelsonpark
    • Contributor
    • 16 replies
    • August 28, 2018

    There is a migrator, search for it in marketplace.jamf.com
    We were iOS only, so extremely simple for us to either migrate or start again. If doing macOS also, then I would recommend paying for the migration service. They can tell you the ins and outs of how and why to do each migration. The more devices and more complex the scenario, the greater need for ‘manual intervention’. This may range from:
    -Start fresh
    -Using the migrator for selected migration
    -Direct dB import
    -Db import with a clean and fixup such as dropping old inventory data, etc

    The FileVault keys definitely add to the mix and I’m not sure how they migrate. You would have to at minimum migrate all computers over I believe.

    Make contact with your jamf support buddy and they can steer you in the right direction

    K
    Forum|alt.badge.img+3
    • KSamuels
    • New Contributor
    • 4 replies
    • September 28, 2018

    The migrator tool seemed to work fine for me. Now how do all the devices get pointed at the cloud and not the old on premise server?
    I tried making a CNAME entry in the DNS server to point our old URL to the new jamfcloud.com one, but that doesn't seem to be working.

    J
    Forum|alt.badge.img+7
    • joelande
    • Contributor
    • 35 replies
    • September 28, 2018

    We just migrated to cloud this past summer. We had been managing our on-premise server for a decade.
    We decided to start from scratch.
    But we had a couple of advantages: we were already planning on nuking and paving our iMacs that summer, and we were on a new iPad cycle, so those were also starting from scratch.

    Is there any advantage to just essentially copying/pasting the existing DB and then trying to clean up that?
    - you doin't have to rebuild everything again.
    - on the other hand, if you are looking at cleaning everything up and maybe doing things a new way, nuke and paving can be nice too.

    Does re-enrolling devices bring the FileVault recovery key over, or would I have to run a script to generate a new one? Is the key in plaintext in the DB so we could run a SQL command to output the serial number and key?
    - do not know this one, we do not use File Vault

    I'm sure there would have to be MDM push cert and VPP/DEP cert enrollments as well, what is that process like in regards to transitioning and having the devices recognize the new ones vs old ones?
    - because we were starting out with nuke and paved devices, this was not an issue

    I like that we nuked and paved, because:
    - we know we did not bring any cruft over from previous installs and years and years of configurations
    - it leaves you with a nice clean feeling
    - we kept our on-premise online, which allowed us to continue to use the old devices until we were prepared to nuke and pave them — they continued to function off of the old JSS, then when we wiped and re-enrolled they used the new JSS; also we could compare and copy our old configurations as we rebuilt the new server
    - a JAMF engineer told us that a database as old of ours was might actually have issues migrating due to old table formats — they would have a way to "fix" that, but I felt better knowing that everything started out nice and fresh - no bad configs, no corrupt databases, etc

    S
    Forum|alt.badge.img+11
    • swapple
    • Valued Contributor
    • 164 replies
    • November 29, 2018

    During our migration, Jamf copied over the database and offered up a "ReEnroller" script that you would run on your onprem Macs. That script would point the Mac to the new cloud instance. We got 90% migrated that way with nothing on the user side to do. We are still trying to figure out why the remaining 10% do not like the script and are hand enrolling them into the cloud.

    Nuke and pave: lots of setup work and hope you don't forget something (remember that 1 off software package scoped to a special group?)
    Move and clean: cleaning up a familiar config and hope you find everything that needs a tweak.

    S
    Forum|alt.badge.img+5
    • sk25
    • Contributor
    • 64 replies
    • February 25, 2023

    We just migrated to cloud this past summer. We had been managing our on-premise server for a decade.
    We decided to start from scratch.
    But we had a couple of advantages: we were already planning on nuking and paving our iMacs that summer, and we were on a new iPad cycle, so those were also starting from scratch.

    Is there any advantage to just essentially copying/pasting the existing DB and then trying to clean up that?
    - you doin't have to rebuild everything again.
    - on the other hand, if you are looking at cleaning everything up and maybe doing things a new way, nuke and paving can be nice too.

    Does re-enrolling devices bring the FileVault recovery key over, or would I have to run a script to generate a new one? Is the key in plaintext in the DB so we could run a SQL command to output the serial number and key?
    - do not know this one, we do not use File Vault

    I'm sure there would have to be MDM push cert and VPP/DEP cert enrollments as well, what is that process like in regards to transitioning and having the devices recognize the new ones vs old ones?
    - because we were starting out with nuke and paved devices, this was not an issue

    I like that we nuked and paved, because:
    - we know we did not bring any cruft over from previous installs and years and years of configurations
    - it leaves you with a nice clean feeling
    - we kept our on-premise online, which allowed us to continue to use the old devices until we were prepared to nuke and pave them — they continued to function off of the old JSS, then when we wiped and re-enrolled they used the new JSS; also we could compare and copy our old configurations as we rebuilt the new server
    - a JAMF engineer told us that a database as old of ours was might actually have issues migrating due to old table formats — they would have a way to "fix" that, but I felt better knowing that everything started out nice and fresh - no bad configs, no corrupt databases, etc


    @All We are planning to migrate from On prem to Cloud and we are new to this. What would be the recommendation for migrating macOS to cloud. I mean we need to wipe (factory reset) and re-enroll the macOS to cloud or without factory reset can be done? 

    Appreciated any type of answers. Thanks.


    Terms & ConditionsCookie settingsAccessibility statement