COME SEE MY TRAINWRECK!! customized portal migration worked but the portal now shows elements from both environments

(0) Share

Report

Posted on by urklnme

168

The example customer service portal was provisioned in DEV, TEST, PROD environments. (by first timer tech staff.)

I customized the portal in DEV. removing most of the boilerplate stuff. I have a home page and a page that contains and entity list of cases. The only action on the list is View. No create or edit actions.

Question 1: Did I use the correct schema file?

Using the Configuration migration tool, I exported the DEV portal using CommonDataService_Starter_Portal.xml schema file. I wasnt sure if I should have used that one or Customer_SelfService_Portal.xml

The export worked well.

The import into the TEST environment went well and imported fine.

When I start the portal in TEST, I see my customizations and the original boilerplate functionality on the same page.

The home page has the forum stuff and the Get Help contact stuff and the standard images.

Example, the navigation at the top of home should have fewer items in it. it actually contains items from both my customized portal and the customer service example portal. see attached image.

QUESTION 2: Is there a way to migrate a customized portal and have it not meld with the example customer service portal.

QUESTION 3: Is it true that a portal has to be provisioned already in the target environment before you can migrate portal to it?

Please help an old guy with his technology struggle LOL!

Categories:

Power Apps portals

I have the same question (0)

All responses (4)

Answers (1)

Sort by

Fubar Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!
You need to use the correct schema file (otherwise in some cases some data may not migrate). In the Portal Management app, click on Websites menu item unless you have renamed it the name defaults to they type of portal that was installed (edit: starter portal is usually the blank or custom portal, you most likely wanted customer self service schema)
not sure what you mean by 'meld'. Moving a Portal between environments is basically copying, matching on the internal GUIDs (if one is found overwriting it). Note: moving a portal between environments does not delete from the target it will Upsert (so if you are deleting from your source, you need to also delete from the targets).
Yes. Portal has to be provisioned in each environment (of the same type e.g. all Customer self-service).

Was this reply helpful? Yes No
justinburch Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!

To piggy-back on @Fubar's excellent answer, any initial clean-up work you do should be done in a way that can carry-over - which is one reason it's extremely important to have the same portal types in all environments. As an example, if you have pages or web link sets or anything that you don't plan on using, first do a deactivate in your dev environment until you've deployed at least once. This will deactivate in all environments and you can delete the inactive records later. For the "upsert" mentioned also, this is why I prefer the Portal Records Mover. That upsert has caused me too many unnecessary bugs post-deployment. If helpful, you can find many blogs on best practices there, and I've got some written up here: Portal Development Tips | Justin Burch

Was this reply helpful? Yes No
urklnme 168 on at

Like
a
(0)

Report
Copy link

Link copied!

meld - blend; combine.

sorry about that... ben using that word a long time. it is not common usage.

thank you for the answers.

all of my instances had the same portal provisioned.

I customized the portal in the DEV instance. When I migrated it to TEST. D365 blended my customizations with the portal already in Test. This is what D365 and solutions do, they apply only the changes to the target instance.

So, after migrating to the TEST instance I have to re-customized the portal to remove example portal components and I will have to do again when I migrate to the PROD instance.

Is there way to, only on initial migration, overwrite/replace the portal in the target? instance?

OR

Is there a way to delete the content of the portal and still have it provisioned?

Was this reply helpful? Yes No
Verified answer

justinburch Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @urklnme,
Yes, by doing as I suggested, you can overwrite on initial migration. You can also delete the Website record (which will take some time to also delete all dependencies) and then any orphaned records, but there will be a lot of risks here.
I'd suggest doing the following:
Move from Dev to Test
Deactivate the default records in Test that haven't been updated but you want removed
OPTIONAL: Move everything, inactive and all, from Test to Dev to keep synchronized. This is your new starting point.
Move the components from Dev (or Test, if not moved to Dev) to Production, UAT, SIT, whatever it is you still have
With this, every deployment will overwrite or deactivate the base records and each environment will be aligned

Was this reply helpful? Yes No