2 Replies Latest reply on Sep 12, 2014 9:27 AM by fitchsoccer342

    Use migrate.zip for EPO migration


      Dear all


      Hope I could have some answers


      I have a EPO 4.6.7 sitting on a Windows 2003 32bit using an external DB.


      Like to install EPO 5.1 on a new server running W2008 64bit

      This new installation will be using a new SQL server running SQL 2008R2


      Now my question is in which order would I run a migration?

      If I understand it all, it should be

      Backup DB on old SQL

      Run the UpgradeCompatibility.exe on old EPO

      Restore the DB on the new SQL

      Install EPO 5.1 on new server, point to the new DB

      Then execute UpgradeCompatibility.exe on new EPO server


      Have I got it wrong or is the above order correct?

      then by following above I dont need to use anything like KB71078 or KB66616

      I also  like to say that in the current configuration I have EEPC not compatible with EPO5.1, when it comes to EEPC I would have to upgrade in 4.6.7 before running UpgradeCompatibility.exe to create the migrate.zip

      Will this then give me in EPO 5.1 system tree, assignments, tasks basically the same configuration as I had in EPO 4.6?

      And do I need to in dbproperties on the new EPO 5.1 do any changes? Or changes in any other location? to make it work


      Reason for asking, I have seen different ways of doing the above


      answers would be most appreciated

        • 1. Re: Use migrate.zip for EPO migration

          Hi again


          Looks like this migration tool causes a lot of issues

          I seen more threads on the community.

          Would be nice to have somebody from McAfee that could clear out things about this migration option

          Is there a clear instruction? 

          • 2. Re: Use migrate.zip for EPO migration

            I am actually in the process of migrating one of our ePO environments as well.


            I stood up a brand new ePO server and DB, then added the new server as a registered server in the old. This will allow you to transfer all the systems from the old to the new. For the system tree, client tasks, policies, queries, users, tags, etc. I just exported all of it from the old, then imported into the new. Once you have the new server all setup, you can start transferring systems from the old -> new and tailor as needed.


            If you need to use your old DB, create a .bak of it, attach it in the new SSMS, configure ePO to point to it, and then perform the above. Or just use a brand new setup and retain a .bak of the old setup.