Apply Production Changes to Development in Managed Solutions
DRAG DROP
You are making changes to a solution in a development environment. The solution is deployed as managed to the production environment.
You observe that changes were made directly in the production environment, which is not in line with the software development lifecycle.
You apply the changes made in the production environment to your development environment and delete a table column that is no longer required. You add several views to the model-driven app.
You need to apply all changes in production to mirror development without impacting users.
Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.
Community Insight
The core concept is maintaining SDLC integrity by converting unmanaged production changes into a managed solution format before upgrading.
This question addresses the proper sequence for migrating direct production customizations back into a managed solution lifecycle. It establishes that you must first export, then clean up the unmanaged layer, and finally import as an upgrade.
Candidates often attempt to import changes directly or fail to remove the unmanaged layer, leading to conflicts or loss of customization history.
Community Discussion (2 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct sequence is: 1) Export the solution from development as managed; 2) Remove the unmanaged layer from the model-driven app in production; 3) Import the solution as an upgrade. First, you must capture the current state of development (including the new views and deleted column) into a managed solution package. Second, because users made direct changes in production, an unmanaged layer exists on top of the managed solution; this layer must be removed to prevent conflicts and ensure the base solution is clean. Third, importing the newly created managed solution as an 'upgrade' applies the development changes (new views, schema changes) to production, effectively mirroring development while preserving user data.Why the Other Options Are Wrong
Any option suggesting importing without removing the unmanaged layer is incorrect because it causes customization conflicts. Exporting as unmanaged is not suitable here because the target is a managed environment where controlled deployments are required. Directly editing production is explicitly stated as non-compliant with the SDLC.Community Comment Notes
Community consensus supports the three-step process. As one commenter noted, "Because the problem statement says: 'changes were made directly in production … not in line with SDLC'... That means there’s an unmanaged layer sitting on top." Another user confirmed the order: "1 Export as managed... 2 Remove the unmanaged layer... 3 Import as an upgrade." The key insight shared is that the unmanaged layer must be cleared before the upgrade can successfully apply the new schema and view changes.Exam Strategy
Always check if an unmanaged layer exists when dealing with managed solutions in production. If direct changes were made, you must address the unmanaged layer before performing any solution upgrades to avoid deployment failures.
Frequently Asked Questions
Why must I remove the unmanaged layer before importing?
Direct changes create an unmanaged layer that conflicts with managed solution updates. Removing it ensures the upgrade applies cleanly.
Can I import changes directly without exporting from dev?
No. You must export the current development state as a managed solution to capture all changes (views, columns) in a single package.
Related Analysis
Practice All PL-400 Questions
Access 85 questions with complete answers and detailed explanations.
View Full PL-400 Practice Test →