Migrating FIM dev to production


  • Hi,

    We have looked at the migration documentation for FIM, but just wondering if this is another approach we could use to move our configuration from dev to production:

    - backup databases in dev & restore FIMSync and FIMService databases to production

    - install FIM Sync and Portal in production, using the existing databases

    - manually move the code over

    will the above work - why the need to run the powershell migration scripts?



    Friday, June 15, 2012 12:48 AM

All replies

  • Hi there,

    I seem to recall seeing posts from others with optimised migration processes - I use a slightly adapted process using some tools to assist, but its largely the process described by Microsoft.

    Having said that the powershell scripts are probably the easiest way to do it as you can use them to export all the configuration from both environments, it will work out what changes need to be made and then apply them that way.  It is a bit tedious but works well (in most cases) - the other benefit of doing this is that you have an export of everything before you started making changes, and have a changes file with all of the changes that you made.  

    - backup databases in dev & restore FIMSync and FIMService databases to production

    I doubt this would be supported for one, but also the database contains your entire environment - so doing this would result in you losing all your users (and other objects) in the production environment and replacing them with the ones from your test environment.

    - install FIM Sync and Portal in production, using the existing databases

    you'd run into the same problems as above.

    - manually move the code over

    by this do you mean extension and workflow DLLs?  If so you need to do this anyway.  Or do you mean Portal config objects like MPRs, Sets etc - you can do this, as it can sometime be quicker for small changes but the powershell process has the advantage of giving you "backup" and changes files.


    Friday, June 15, 2012 1:47 AM
  • whether it's supported or not I'll leave in between. But if you go with backup/restore of complete DB's your MA's probably will need reconfiguration to match the other sql or AD server names.

    Either way, that's a one shot migration… What will you do when you need a config change? I prefer to use the powershell aproach. You can use it for small and big changes. If you for particular change you think it's overkill, you can still do it manully by performing your changes in two environments. But I'll Always want to have the PowerShell aproach ready in case of a big change you want to migrate over.

    Friday, June 15, 2012 12:31 PM
  • Actually from my experience gathered over a time best way to approach it is to have Powershell scripts to import configuration on environment as a build script. And I don't mean these powershell scripts to export \ compare \ import approach from MSDN, which also works with some efforts but with incremental upgrades and changes made over a time this approach is more and more time consuming with subsequent changes. What I mean is developing a FIM configuration "build" which will deploy your changes on an environment either this is existing one or a new one. 

    Some efforts required upfront but it is rewarding afterwards

    Monday, June 18, 2012 8:31 AM