*** NOTE: ALL INFORMATION IS ACCURATE AT DATE OF PUBLISHING ***
You’ve created an epic portal in your D365 developer organisation but now it’s time to make it live. So how do you get it there? At this current time (January 2018) the only way (short of copying and moving your entire organisation) of moving dynamics 365 portals is to use the Configuration Migration Tool. This blog will explain how to do this, with specifics on version 9.x and any gotchas along the way. ** Be sure to read the links provided in this article for full details. **
The first article I started with was this one,Β Configuration Migration Tool (for v8.x Portals). The article gives a comprehensive step by step guide to exporting the information required for a portal from one organisation and importing it in to another organisation. The first step is to create a new solution containing all elementsΒ of your portal.
A few points to be aware of (discovered by trial and error!):
- Make sure you include the Notes entity. These are used as part of the Web File entity and store the actual file. If you don’t bring them over you will be missing all files, even though the Web File record will exist. You will know instantly when you look at your portal because the absence of any stylesheets will make it look pretty bad!
- You are able to have multiple records (Web Pages, Website Access Permissions etc.),Β with the same name, but when exporting and importing, it will only bring across one of them. Keep this in mind and do a quick check of your records first. You can then rename them and change the names back if required once the import is complete.
- If you aren’t sure if you need an entity in the solution and it has adx_ at the prefix of the name, bring it in just in case.
Once you have your solution ready, it’s time to use the Configuration Migration Tool. If you are using v9.x you will have issues once you attempt the first step of trying to connect to an instance via the tool. Each time it looks like you have logged in and are able to select the organisation you need, it will refresh and revert back to the login screen. That’s where this article helps:Β Download tools from NuGet.
The article provides these steps:
- In your Windows Start menu, type Windows Powershell and open it.
- Navigate to the folder you want to install the tools to. For example if you want to install them in a devtools folder on your D drive, type cd D:\devtools.
- Copy and paste the provided PowerShell script into the PowerShell window and press Enter.
If you’ve never done anything with Windows Powershell before it might seem daunting, but it’s very quick and straightforward. It will look like this:
Once complete, you will be able to find the Configuration Migration utility. Double click on the DataMigrationUitlity file (the first one in the list, not the executable file). You will be asked what you would like to do (Create scheme, Export data or Import data). First we will create the schema.
On the Login page, select Office 365 for the Deployment time, and tick the boxes for ‘Display list of available organizations’ and ‘Show Advanced’. Select the Online region (pick Don’t Know if you aren’t sure) then enter the username and password for the environment you are trying to connect to. If you have multiple organisations you will be prompted to select the right one, otherwise you will take directly to this screen below. Find the portal solution that you created from the list on the top left. Click Add All on the right. This will add all of the entities you added to your solution.
Make sure to click on Tools, then Configure Import Settings. Tick the box to Disable plug-ins on all entities for import.Β This stops plugins from running during the import process and will automatically reactive the plugins once the import is finished. Once this is done, click on File, then Save Schema. Give the schema a logical name and place to save it to.
For exporting the data, if you exited the tool previously you will need to select the Export data option and will be prompted to log in again. If you didn’t you can simply click the Export Data button from the top of the screen. Pick the schema file (which is the one you just created) and then the file where you are going to save the data (all of the records for each entity). Give the data file a logical name. This will be exported and saved as a zip file.
Click on the Export Data button at the bottom of the screen. The export process will then begin. You will be able to see each entity along with the number of records it contains as it starts importing. Once it’s finished, click Exit to close the tool.
Now you are ready to import your portal to the new organisation. Start the configuration migration tool again, and this time pick the Import data option. Connect to the correct organisation. Then browse out and find the zip file you created in the Export data step above. It will show you how many entities are ready to be imported.
The process will begin! You can watch the progress for each entity and see how many records have been updated. Good to keep an eye on this so you have an idea of any potential issues. Keep in mind that the import is done in multiple passes so not everything is imported for an entity first go round. Once it gets to the end you will see that the plugins get activated again, and the import process will have completed. You can also see how long it took (less than 5 minutes each time I have run this).
So, a few steps to walk through when moving dynamics 365 portals but a relatively simple process. Even though the process completes, it is a good idea to compare the number of records for each entity in your source organisation and your destination entity. This was how I realised not all Web Pages had been migrated, simply because I had multiple pages named the same thing. While this was needed for the portal functionality and navigation, those page names needed changing prior to exporting the data. Go through all of your Portal related entities to check everything looks as it should. Once you are happy you have everything in your destination organisation, use the Dynamics 365 Admin portal to access the portal add-on application. Use the Manage Dynamics 365 Instance option to select the instance you imported the portal in to. You will need to also select the Portal Audience and Portal type to be deployed. Once you have this selected, you should see the new portal you migrated over. After a few minutes, the portal URL will now be pointing to the newly migrated portal in your destination organisation.
Check out the latest post:
Split Your Audience By Number Or Percentage In Customer Insights - Journeys
This is just 1 of 480 articles. You can browse through all of them by going to the main blog page, or navigate through different categories to find more content you are interested in. You can also subscribe and get new blog posts emailed to you directly.
> This was how I realised not all Web Pages had been migrated, simply because I had multiple pages named the same thing. While this was needed for the portal functionality and navigation, those page names needed changing prior to exporting the data.
The reason this happened is because the default matching of records during import is on the primary name field of each entity. You can change this during the schema creation to instead match each entity on its primary id field (e.g. adx_webpageid on web page), which will then make each record be treated as unique during import.
Thanks Alan! That is really helpful and should help anyone else going through this process. I figured there had to be a way, but it certainly tripped me up the first time around.
Hi Megan!
Hope you are well!
Any advantages or disadvantages of provisioning the portal before or after using the data migration tool?
I would have thought we need to install and configure the preferred solution prior to moving the records across.
Any thoughts you have would be most appreciated.
Cheers,
Lachlan
Hi Lachlan, thanks for the comment! I haven’t tried provisioning the portal after using the data migration tool, and I am not sure that would work. I would suggest the approach you were thinking…. install and configure the portal first, then move the records across.
Once you are happy you have everything in your destination organisation, use the Dynamics 365 Admin portal to access the portal add-on application. Use the Manage Dynamics 365 Instance option to select the instance you imported the portal in to. You will need to also select the Portal Audience and Portal type to be deployed. Once you have this selected, you should see the new portal you migrated over. After a few minutes, the portal URL will now be pointing to the newly migrated portal in your destination organisation.
So I first do the migration to the new environment and then only commission the portal? Will this not overwrite whatever was migrated?
Hi, so sorry for the delay in responding. You can commission the portal first, or last. However, if you commission it first, you will still need to come back and point your portal to the new web site you migrated over.
Is there a way to do this via powershell so I can automate it as part of a full CI/CD process?
Hi Mauro. That’s not something I have experience or knowledge on (powershell), so not sure. Perhaps a good question to post in one of the Microsoft Community Forums. Much smarter people than I in there who could help!