web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Community site session details

Community site session details

Session Id :
Service | Customer Service, Contact Center, Fie...
Suggested Answer

Solutions re-arrangement

(0) ShareShare
ReportReport
Posted on by
Our company has just made me in charge of a large CRM implementation that was developed by a third party and has now been dumped on our department. We have our Dynamics implementations so I am familiar with D365 however I have never had to deal with such a convoluted and messy system. This CRM/Dataverse implementation doesn't have any clearly defined deployment strategy. There are like 3 to 4 dozen managed solutions in production instance with their names after Jira tickets!! Whereas we inhouse either always had a "Core" solution style or Solutions defined around shared components. My first job is to clean up this new implementation. On the outside, it looks like creating new solutions and just adding old components into these from the old solutions in the correct order and making sure every component is there in the new solutions, deploy that on test and check everything work. If it does, remove the old two dozen solutions named after tickets. Test again with an eye on any data loss because if a column wasn't there in the new solutions but was there in old messy solutions, it will get deleted and all data will be lost. But I am also worried about circular dependencies, conn references and environment variables. Frankly, this is the first time I am doing this kind of "clean up" on this huge scale. If anyone has done this in the past, I would appreciate any advice you can give, things to keep an eye and edge cases to be aware of. 
I have the same question (0)
  • Suggested answer
    Suriyanarayanan V Profile Picture
    109 on at

    1. Change the goal: stabilise first, then refactor

    Instead of thinking “clean up production,” think:

    Stabilise what’s there → understand it → then refactor via new ALM going forward.

    You don’t need to fully “rebuild” the solution structure in production immediately. You do need:

    • A source of truth (Dev/Test)

    • A repeatable deployment path

    • A clear map of what’s in those Jira‑named solutions

    2. Get visibility: inventory and dependency mapping

    Before touching anything:

    • Export all managed solutions from Prod (keep them safe).

    • In a non‑prod environment (ideally a fresh Dev/Test), import them as unmanaged in the same order they were originally deployed (if you can reconstruct it).

    • Use:

      • Solution layers (per component)

      • Solution dependencies view

    Your goals here:

    • See which solution actually owns which component

    • Identify overlaps (same table/column/view in multiple solutions)

    • Identify shared components (plugins, flows, env vars, conn refs, site settings, web roles, etc.)

    This step is boring but critical. Take notes.

    3. Define your target solution strategy

    You already have a good mental model: Core + feature‑based solutions or shared components + vertical slices.

    Define something like:

    • Core / Foundation solution

      • Global tables, shared columns, global plugins, shared PCFs, global env vars, conn refs

    • Feature solutions

      • E.g. “Sales Extensions”, “Portal/Power Pages”, “Integrations”, “Case Management”, etc.

    Don’t try to perfectly refactor the past—design a clean target model you’ll move towards.

    4. Rebuild in a clean Dev environment (not in Prod)

    In a clean Dev environment:

    1. Import all the existing solutions (unmanaged) so you have the full behaviour.

    2. Create new, clean solutions that follow your target structure.

    3. Start adding components from the existing mess into the new solutions:

      • Tables, columns, views, forms

      • Model‑driven apps, Power Pages, flows, plugins, PCFs

      • Env vars, conn refs, site settings, web roles

    You’re not deleting anything yet—you’re just building a new, coherent solution set that fully represents the current state.

    5. Validate coverage: avoid silent data loss

    Your concern here is spot on:

    “If a column wasn’t there in the new solutions but was there in old messy solutions, it will get deleted and all data will be lost.”

    To avoid that:

    • For each table:

      • Compare all columns in the environment vs what’s in your new solution.

      • Make sure every column that’s used in forms, views, flows, plugins, or reports is included.

    • For each flow/plugin:

      • Check references to columns, env vars, conn refs.

    • For Power Pages:

      • Check table permissions, web roles, site settings, web templates, content snippets.

    Only when you’re confident the new solution set fully represents the current behaviour do you move on.

    6. Test the new solution set in a separate Test environment

    1. Create a fresh Test environment.

    2. Deploy your new clean solution set there (managed).

    3. Run:

      • Regression tests on key business processes

      • Portal/Power Pages end‑to‑end tests

      • Integration tests (if any)

    If something is missing, go back to Dev, add the missing components, redeploy.

    This is where you iron out:

    • Circular dependencies

    • Missing env vars / conn refs

    • Plugin step registrations

    • Portal bindings

    7. Plan the production cutover carefully

    When you’re confident in Test:

    • Deploy the new managed solutions to Prod.

    • Do not immediately delete the old Jira‑named solutions.

    • Run Prod smoke tests:

      • Key forms, views, flows, portal pages, integrations.

    Only after a stable period (and with backups in place) should you consider:

    • Removing old managed solutions gradually, starting with the ones that clearly don’t own anything unique.

    • Always check solution layers before removing a solution:

      • If a component’s top layer is from a solution you’re about to delete, understand what that means.

    8. Edge cases and gotchas to watch for

    • Environment variables & connection references

      • Make sure they’re in the right solution and not duplicated across many.

      • Standardise names and usage going forward.

    • Plugins & custom workflow activities

      • Check assembly registrations and steps.

      • Ensure they’re all included in your new Core/Feature solutions.

    • Power Pages

      • Web roles, table permissions, site settings, web templates, content snippets, web files.

      • These are often scattered across multiple solutions.

    • Security roles

      • Sometimes customised roles live in random solutions.

      • Decide where they should live long‑term.

    • Managed vs unmanaged

      • From now on, treat Dev as unmanaged, Test/Prod as managed.

      • Don’t customise directly in Prod.

    9. Going forward: enforce ALM discipline

    Once you’ve stabilised:

    • Define a solution naming convention (no more Jira ticket names).

    • Use branching + solution layering in source control if possible.

    • Make sure every change:

      • Starts in Dev

      • Goes through a solution

      • Is deployed via pipeline or at least a controlled manual process

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Congratulations to our 2025 Community Spotlights

Thanks to all of our 2025 Community Spotlight stars!

Leaderboard > Service | Customer Service, Contact Center, Field Service, Guides

#1
Tom_Gioielli Profile Picture

Tom_Gioielli 27 Super User 2025 Season 2

#2
TAHER_El_Mehdi Profile Picture

TAHER_El_Mehdi 14

#3
Suriyanarayanan V Profile Picture

Suriyanarayanan V 11

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans