
Announcements
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
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.
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.
In a clean Dev environment:
Import all the existing solutions (unmanaged) so you have the full behaviour.
Create new, clean solutions that follow your target structure.
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.
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.
Create a fresh Test environment.
Deploy your new clean solution set there (managed).
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
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.
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.
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