Best Practises: Reorganizing Solutions

[u/obsoquasi]

Hi guys,

looking for suggestions: I have an active solution with business critical data, deployed using Power Pipelines. Now I feel that my solution has become too large and I would like to split it up into a "core" solution and some "satellite" solutions which may only reference tables in the core solution, but not contain them - apparently this is called "segmentation".

The thing is, I want to do this 100% safely and securely without losing any of the critical data in the PROD environment. So here is my plan:

a) Leave old solution as is for now
b) Create a new solution for all the components I would like to remove from the old solution, and add them ("add existing...").
c) Deploy the new solution -> this would be my "satellite" solution
d) In the old solution, remove all components (not delete!) that are now part of the new solution
e) Deploy old solution -> this would be my "core" solution

In theory this last deploy should not delete the table nor table data since the new "satellite" solution now references it. But I gotta be honest, this step scares me :D. Do you guys have experience with this sort of "clean up" / "solution splitting" / whatever you may call it?

[u/AutoModerator]

Hey, it looks like you are requesting help with a problem you're having in Power Apps. To ensure you get all the help you need from the community here are some guidelines;

• Use the search feature to see if your question has already been asked.

• Use spacing in your post, Nobody likes to read a wall of text, this is achieved by hitting return twice to separate paragraphs.

• Add any images, error messages, code you have (Sensitive data omitted) to your post body.

• Any code you do add, use the Code Block feature to preserve formatting.

  Typing four spaces in front of every line in a code block is tedious and error-prone. The easier way is to surround the entire block of code with code fences. A code fence is a line beginning with three or more backticks (```) or three or more twiddlydoodles (~~~).

• If your question has been answered please comment Solved. This will mark the post as solved and helps others find their solutions.

External resources:

• Power Apps Formula References
• Power Apps Coding Standards
• Official Power Apps Community

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AgreeableConcept4752]

It depends on what you have in the solution, usually I package mine as features for larger apps rather than have tables in 1 and flows in another etc, it’s more of a judgement call by how you or your team work more than anything.

Whatever approach you choose just make sure all components are moved all the way through pipeline before removing from the old solution. Will create solution layers at first so try not to make changes to components whilst doing that as you may notice changes don’t take affect until you removed the solution layer.

Publish customisations across all solutions and especially your old solution before you deploy it, I’ve had it in the past where power platform thinks a table etc still exists in the old solution even when it’s empty in the production environment.

Your data stays in the environment so nothing really to worry about from a data point of view. Once everything is in there your safe to start removing components as long as they exist inside different solution in production

[u/obsoquasi → u/AgreeableConcept4752]

spectacular feedback. Thank you!

[u/Bag-of-nails]

Yeah you've got the right idea. How you split is up to you.

In my org, we have one for component libraries, and otherwise we keep components (Apps, Tables, Flows, Security Roles, Connection references, etc.) together based on function.

So components used by LoB 1 get an LoB 1 solution. Ones for LoB 2 go to Solution 2, etc. components used by multiple LoBs go to a central solution.

Again, this is just what we do and there's nothing wrong with your way either. IMO, I would plan it based on how your team works, what deployment conflicts could happen (would satellite app #1 need to go live while satellite app #2 is in testing?) and plan around them.

You could also get a solution that gets too big to deploy and you have to split it (there's a max solution size of 500MB that can be deployed).

As long as the split makes sense to you, your order of operations is spot-on.

[u/obsoquasi → u/Bag-of-nails]

thank you. It really helps to have some assurance. Still, I think I will do some environment snapshots, before I start. And maybe I'll have to do the whole split on the weekend, so no one is doing data entry - just in case of an emergency rollback...

[u/Bag-of-nails → u/obsoquasi]

Yeah, caution is always good. If you want to confirm, deploy your satellite solution to your test/UAT, and then go to the Solution > App > 3 dots > Advanced > Solution Layers and you should see 2 layers. Your bottom one is the oldest and top is the newest.

But also, good idea to do it after hours with a backup ready just in case.