How to correctly transfer scoped application and resolve application scope validation issues?

[Todd O]

I have built a scoped application in my dev instance. It has many things (tables, forms, workflows, business rules, etc). My goal is to transfer the entire scoped application (from source instance) into another dev (target) instance. The problem is that I'm having errors during the import to my target instance and I'm not sure how to resolve.   Below are further details to clarify the steps I've taken thus far. Thanks in advance for any help here.

1. I started with my source instance and navigated to the "System Applications -> Applications" section.   I then chose to "edit" my scoped application.
2. Within the edit of my scoped application, I chose the option to "Publish to an update set." I then downloaded the xml output that it created during that process.
3. Next, I went to my other target instance and navigated to the "System Update Sets -> Retrieved Update Sets."   Within this location I chose the "Import update set from XML." I proceeded to upload the xml file that came from my source instance described in #2 above.
4. The import process worked but it contains over 1,200 errors.   Most of them look like the sample below. I'm not sure how to resolve. I tried a few things such as the following...
   1. I created an empty scoped application with the same name has my source application (i.g., 'TDO').   Then I tried "Run Preview again" on my update set but still same errors.

Sample error:

Cannot commit Update Set 'TDO' because: Update scope id '3dbfd5170f1b42008e030dbce1050e04' is different than update set scope id 'global'. Resolve the problem before committing.

p.s., I've read the SN documentation on how to resolve these types of errors but it did not address the items I'm seeing.

p.s., I've also read Cory's post about the philosophy of scoped applications and I think I'm doing everything correctly (although I must not be).

[Lane Roberts]

This issue generally occurs when the 'Export to XML' UI Action has been previously customized before the upgrade to Fuji or later versions is completed, causing the update to be skipped on upgrade. Scoping was introduced in the Fuji+ releases, and as such various updates were made to functionality including the 'Export to XML' UI Action, if you are using an older version of this UI Action that does not include the scoping related addendum's, then all update sets that are not in the global scope will have this error when you attempt to import and commit them into a target instance, as they are not being packaged properly on XML export from the source instance.

Reverting the Export to XML UI Action to base system, following by re-exporting any previously affected update sets to XML, will resolve this issue.

Regards,

[Loudigi]

Why did you go the import xml route? Why didn't you try to "Install" the app from within the target instance first?

[Lane Roberts]

If the intention is to simply install the application for testing or use on the target instance, then yes, utilizing the 'make app available to other instances' UI action, followed by 'installing' the app from the company repository, is the preferred method.

However, those that wish to move an app with the purpose of continuing development on the target instance, going forward, must move the application through update set by using the 'Publish to Update Set' UI action followed by exporting the newly created update set to XML via the 'Export to XML' UI action. This method is the only way to move an application in its entirely with the purpose of moving where further development of the app originates from.

[phsdm]

I have a question related to this.   After I have moved the application, the Edit option is still available in the source instance.

How do I make it disappear?   I don't want to fork my edits by forgetting what instance I'm in...