136

Suggested Fri, 23 Sep 2016 05:30:27 GMT by Sabrina TopacioPlanned
Category: Portals

Be able to copy all/most of the Website records from one environment to the other.  This would be very useful when clients have a sandbox portal sites and want to push all their changes to production.

Status Details

Thank you for your feedback.  We are considering how to migrate portal content and configuration from one CRM to another and from one website to another.

Sincerely,
Shan McArthur
Principal PM, Microsoft

Comments (9)
  • A tool to migrate Portal configuration from One environment to other would be defnitely helpfull . We had a mulitlingual application and moving pages from one environment to other was really painfull.

  • Has anyone built a Scribe Online map to help migrate this data?

  • In my recent experience with both tools like XRMToolbox and Config Migration Utility I would say Config Migration did the trick for me.


    XRMToolbox tries to take entity's data(as expected) but things like Owner information ideally should not be copied/exported since it may be different between environments.


    With Config Migration Utility, it allows you select the attributes that you want to export and subsequently import. This granularity is not available in XRMToolbox but mind you this is just my requirement and may not suit everyone. And probably it was XRMToolbox's developers idea of not going in such detail to offer that configuration.


    Both tools are great but they have their pros and cons w.r.t. Portal data.

  • We've found that using the SDK Config Migration Utility to initialise environments and then XRMToolbox Portal Records Mover if you want to update few records works well.

  • For those of you not aware of it, I released a plugin for XrmToolBox that allows to export/import portal content and configuration : Portal Records Mover


    Give it a try!

  • After wasting a bit of time we have done this with the SDK's DataMigrationUtility.exe


    Would have been nice if Microsoft provided a pre-configured Schema.



    • Identity all the entities comprising the Portal (look at the solution files in CRM - ignore standard CRM entities)

    • Create a DataMigrationUtility Schema containing all the identified Portal entities 

    • Remove entities that contained only data (rather than metadata) such as Session and Invitations entities from the Schema

    • Update the Schema to disable Plugins on import

    • Update each entity in the Schema to force the use of the unique Id for the entity

    • Export from the source using the Schema

    • Import to the target.


     

  • I am not fan of another tool, there are already a  good tools to migrate data in SDK - Configuration Migration Tool - it would be enough if Microsoft can provide us the supported schema file for that tool which we can use to export data from one instance and import to another instance - the advantage is that this data can be used with Package Deployer to automatically deploy.

  • This is definitely needed, but I think I would be cautious in creating another websitecopy only tool.  Web site data often has other data dependencies so a website only tool will only work for simple scenarios.  The previous version of websitecopy also did not support update where as the ALM based tools did, this is very critical that an update to exist records is supported as it is likely you will be importing many versions over the course of development.


    The benefit of CRM ALM tools was to copy more than just a website or be very selective about the data that you wanted to move.  If ADX ALM or Xrm.Data.Powershell or Configuration Manager were utilized with a more friendly GUI and included pre-defined packages for portals or even other D365 services like field and project service then that would be the best for all use cases.  We need it approachable for those that just want to easily clone web sites but powerful for those that need to do that and much more.  Package deployer/configuration manager is a little too cumbersome currently to be the tool of choice for the non-technical as well as even the technical audience as it does not provide an easy way of repeating the same process.

  • Could this be done by adding a import records to a solution. That way as part of a solution roll out required records can be ported from one environment to another. 


    I would see providing an advanced find of the records I wanted ported from one environment to another automatically creating the xml required for the import, and then on publish of the solution in the new environment, it would need to verify the import was successful (Create or Update depending on if the record ID already existed in the imported Organization) as part of the solution import.