@DamianosD

I think you are on the right track. I typically:

1. Save As the bottom-most application that has the rulesets you want to 'move';
2. In the new Org-layer application, remove the Implementation rulesets from the ruleset stack;
3. Revisit Case types, Data classes and all configuration across the rest of the Org-layer application rule to ensure you are not referencing items that are more specialized.
   1. I'd say it is unlikely that you will use the Org layer as the top-most layer for 'doing work', so it is perhaps unlikely that you will list any Case Types here. That's up to you. 
   2. For Data Classes you will want to list what you want Dev Studio and App Studio users of this Org layer to see on their respective Data Explorers. These include organization-wide data types that you would use to compose other data types in App Studio, as well as those for which you want to use the Records editor to capture and maintain concrete instances of that data type in the Pega database.

If you are using Skin Inheritance, you would hopefully have a Skin rule at the organization level, from which your implementation layers are inheriting so as to implement application specific formats and overrides. If your implementation layer Skin inherits directly from a Platform skin, now is the time to consider re-architecting this into which formats are organization-reusable and which formats are implementation-specific.

Once the Org-layer application rule can be saved, update other Application rules that reference the Org-layer rulesets:

1. Add the Org-layer application as a "Built on application";
2. Remove the Org-layer rulesets, as the previous step is what includes these on the ruleset stack.

Access Groups are then a case of what access you want to grant. For the org layer, it may only be "developers" who are building reusable assets into the organization-level rulesets; but there's no single answer for this. Yes there are some decisions to make on Design time configuration and Work Pool, but for an Org-layer application you either:

1. Likely won't utilise these, in which case the values you choose are less significant (but should still make sense); or
2. Know you will use them as you have real case types in this layer, in which case the answer should be clear.

For the Access Roles you configure into the Access Group, utilize Pega's Dependent Role framework (new in 7.4 or early 8.x) to 'inherit' the Platform Access Roles without cloning them. This separates the platform access control you want to leverage, from the 'overrides' you specifically want to apply for your Org layer. This:

1. Makes it clear what your Org layer access control is that different from the Platform
2. Is more resilient to upgrades because future changes to Platform Access Roles are inherited by your Access Roles and not masked by a clone created from an older Platform version.