https://www.infopathdev.com:443/forums/46.aspx For questions concerning issues in the integration of SharePoint and Microsoft InfoPath.enCommunityServer 2007 SP3 (Build: 31118.962)https://www.infopathdev.com:443/forums/thread/62883.aspxFri, 07 Jan 2011 05:39:51 GMT033a2e2d-04e2-4a9d-be01-a4634161eefd:62883Patrick Halstead0https://www.infopathdev.com:443/forums/thread/62883.aspxhttps://www.infopathdev.com:443/forums/commentrss.aspx?SectionID=46&PostID=62883<p>Hi LBellows,</p> <p>Sorry for the delay. Somehow we missed this over the holidays. </p> <p>The key thing is to make sure the content model (i.e. the data source or schema) for the two forms is compatible. If the schema for v1 and v2 are compatible, you can just publish your new form to SharePoint. Hopefully you are using a Content Type (instead of just a Form Library) but it will work in either case. The Content Type approach allows you to handle promoting different fields to same columns if the schemas have diverged (see <a title="Side-by-Side Versioning with Content Types" href="http://www.infopathdev.com/blogs/jo-anne_alfafara/archive/2010/10/06/side-by-side-versioning-with-content-types2.aspx">Jo-Anne&#39;s blog from October</a>) and are no longer strictly compatible. We have a training module in our InfoPath Master Class on how to do versioning and it may be useful for you to review that too - email CourseManager (at) Qdabra (dot) com for more info.</p> <p>If you have added fields to v2 and are wondering if it&#39;s still schema compatible, it will be if the new fields were not added as &quot;required&quot;. Moving the 700 v1 forms should not result in issues unless they include surrogate keys, like SharePoint list IDs, etc. Best practice moving forward is not to use surrogate keys for the data. Use a natural key instead that is derived from a set of fields in your InfoPath form (and concatenated into a new field that also resides in your main data source). That way, moving the forms won&#39;t break them. Once again, with content types and a library that has multiple InfoPath content types bound to it you can work around the promoted property issue (since there is separate mapping for each content type).</p> <p>We also have tools to allow you to move forms and XSNs around and even to batch version upgrade the data.&nbsp;Send me email if you are interested in these. </p> <p>Hope this helps a little,&nbsp;</p> <p>&nbsp;</p>https://www.infopathdev.com:443/forums/thread/62293.aspxTue, 14 Dec 2010 17:10:14 GMT033a2e2d-04e2-4a9d-be01-a4634161eefd:62293lbellows0https://www.infopathdev.com:443/forums/thread/62293.aspxhttps://www.infopathdev.com:443/forums/commentrss.aspx?SectionID=46&PostID=62293<p>I&#39;m sure this is a common question but I can&#39;t seem to find any guidance. </p> <p>What is the accepted approach to migrating your dev/UAT environment to Production? We are moving structural changes, new infopath forms and event handlers, but we want to preserve the content already existing on production. </p> <p>We have some 700 submitted forms on production using v1.0 of our form template. We now have v2.0 of the form template on UAT, along with sharepoint changes such as workflows and views that we want to push to production via backup/restore. This would overwrite the submitted forms on prod that we want to keep and use with v2.0 of the template.</p> <p>It seems if I copy the forms then try to copy them back I run into a bunch of issues. Some stem from addition of columns or fields in the IP form, some could be version differences, list guids.... a lot can go wrong. </p> <p>Whats the best way to accomplish this without the least amount of headache? Is there a widely accepted approach? </p>