Wednesday, May 02, 2012 4:29 PM
I am new to Sharepoint, and my organization is, too. We are using a hosted environment. We have 3 environments, Dev, Stage, and Prod.
The current project is setting up a records center. We have it set up in Prod but it is only pseudo-live, meaning we are still training users and there are some documents stored in Prod, but not a lot. We're trying to get this all up and running this month.
We have Dev and Stage sites as well, so we're trying to do classic development/migrations, meaning we are making changes in Dev, testing them, then would like to migrate the changes to Stage, then finally to Prod. This is pretty classic in standard software development, but SharePoint is different.
If we change options to our Dev site, make changes to the site options, library and list options, add or change workflows, etc., how do we migrate those to the other environments without wiping out the content that is already in those environments? I know we can perform a backup/restore to copy a site, or create a template with or without content and create a new site in our other environments, but how to we migrate our changes to Prod without impacting the prod data (content) that is already there?
SO far it looks like we tell our hosting partner what chages we have made, and they have someone manually make the same changes to our other developments. This seems like a poor process, but I don't see any better way. I assume and hope someone has a better solution. Thanks.
Wednesday, May 02, 2012 4:40 PM
It could have been pretty easy to setup with some limitations (Content Only - No Configuration)if you were using SharePoint on premises using Content deployment. We could also be able to use any third party data migration or governance tool to manage it but that option is also not available due to hosted environment.
Based on that I dont think it is possible to setup such synchronized environment.
Jerry Yasir - SharePoint MVP, MCT
Wednesday, May 02, 2012 4:51 PM
It is configuration changes we need to migrate to our different environments. Content is a different issue and we are using a 3rd party tool for content.
I come from a software development background where software is software and data is data and you can change software (executables, HTML/ASP pages, config files, et al.) without touching the data (Database tables, files, etc.), so I naturally think in terms of migrating software. But in Sharepoint, what I see is the lists and libraries all have their content and it's all embedded in the site. If I copy a site, I copy everything, which would effectively wipe out prod data and replace it with test junk. Without knowing the internals of how Microsoft stores all this stuff, I don't see any 'reasonable' way to migrate my configuration changes without, as I said, impacting the existing data.
Anyway, thanks for replying to my post.
Wednesday, May 02, 2012 5:04 PM
Export the site from development environment using powershell
Export-SPWeb -Identity URL -Path "D:\EXPORT\dev\devsite.cmp" (dev server)
Create a new site on prod based on the same template you used on dev.
Copy .cpm file or entire dev folder to production server
Import devsite.cmp to this new site.
Import-SPWeb -Identity URL(New site on Prod) -Path "D:\Import\dev\devsite.cmp" (prd server)
Source and destination site should have save site template
Thursday, May 03, 2012 3:34 PMThanks, I will look into this command and see if it does what I need.
Monday, July 09, 2012 6:21 PM
We have the same challenges. What did you come up with?
Monday, July 09, 2012 7:05 PMI had similar situations. I ended up using Power Shell scripts to create these configurations in all environments. It is not easy. It is like that SharePoint usability doesn't help very much when it comes to configuration migration.