locked
data migration between environments RRS feed

  • Question

  • What is the best-practice for installing and configuring multiple environments ? Currently we have 3 seperate environments (DEV, STAGING, PRODUCTION) and each server was installed by creating a new organization. The problem is that each environment has different guids for default units, currencies, etc. and prevents us from migrating product data between environments (products have references to currencies etc. with guid's from DEV that don't exist in STAGING and PROD). I'm tempted to create a new 'vanilla' organization in DEV, make a backup of the org database, and import the organization on the other two environments using the Deployment Manager. 

    Is this a good solution ? Any drawbacks or foreseable issues I might encounter ?

    Thursday, October 3, 2013 2:40 PM

All replies

  • Yea, backup and restore from prod. Assuming all your orgs are unmanaged, that provides you with a snapshot of the data from prod as well.

    I find it's often helpful when making changes in dev to first restore a backup from prod so that you can work with the most up to date data. This also means if any changes have been made directly in prod (best not to but you never know), they will be pulled into dev as well.

    The only problem I can think of is that if you've done any customizations in dev that haven't been deployed to prod then your backup will not be the latest version. But otherwise it's definitely worth it to get all the GUIDs matching etc.


    If my response helped you find your answer please show your thanks by taking the time to "Mark As Answer" and "Vote As Helpful".

    Twitter LinkedIn Facebook Blog Magnetism

    Friday, October 4, 2013 7:33 AM
  • Hi Paul,

    Is this considered 'best-practice' by Microsoft ? We're at the initial stage of the project and all the custom code and customization has been done on entities on the Development server, can I reverse your process and import the organization from DEV => Staging => Prod ?

    Friday, October 4, 2013 7:35 PM
  • I wouldn't recommend going the other way. When going forward (Dev => Staging => Prod) always use solutions to deploy changes. If down the line you need to make some more changes, you can refresh Dev and Staging from Prod so that you have the most up to date data/customizations, and you know that Staging will be an exact copy of Prod.

    The reasons I wouldn't recommend restoring from Dev => Staging => Prod for your initial release is because firstly it will deploy with it any test/dummy data you've created, and secondly it means you won't have tested the deployment process. Sometimes you can build a system which works fine, but you find there's something wrong when it gets imported to another system. You would want to make sure issues like this are picked up straight away going from Dev => Staging rather than down the line when you're making a minor change and need to deploy the solution.

    I can't find anywhere that Microsoft has said this is best practise, however it's definitely supported, and means you get a true copy of Prod after your initial go live when making future changes.

    Hope that helps

    Paul


    If my response helped you find your answer please show your thanks by taking the time to "Mark As Answer" and "Vote As Helpful".

    Twitter LinkedIn Facebook Blog Magnetism

    Friday, October 4, 2013 8:03 PM