Preparing for Managed Solutions

Many environments grew unmanaged for historical reasons. The customizations sit "unmanaged" in production, and some of the development was done directly there. The wish for a clean process with managed deliveries usually comes with an occasion, such as a new service provider or an audit. The switch is doable, but it is a project and not a toggle.

What has to be clarified beforehand

The technical switch is the smaller part. Before it, three decisions are needed that are more organizational in nature.

From now on there is a single development environment from which you export. All other environments only receive. Whoever develops around it creates the layers again that you want to get rid of.

There is a way for urgent fixes. The most common reason for working directly in production was always the emergency. The new process needs a fast path for it, for example a small fix solution (hotfix) with a shortened approval. Without it, the process is bypassed in the first emergency, and then discipline is gone.

The decision on how to deal with the existing stock is the real knot.

The existing stock: unmanaged in production

The existing unmanaged customizations in production do not disappear just because you deliver managed from now on. On the contrary: they sit as the top layer above everything and make sure that managed deliveries have no effect on exactly these components.

The thorough way first rebuilds the development environment from the production state. Then you roll out managed. After that, the active unmanaged customizations in production are removed, component by component. The platform offers removing the active customization on the single component for this. It is diligent work with a check after every step. It can be organized well in waves: uncritical components first, then the core objects.

The pragmatic way accepts a mixed state for legacy components and only switches new things to managed consistently. This is the more common choice, and it works as long as it is documented which components are still in the old state.

The publisher question belongs in the same cleanup phase: will everything run under one common publisher from now on, and which one? Old components keep their prefix anyway. But from the switch onward, new things should be uniform. Otherwise the export documents the switch as another break instead of a fresh start.

The dress rehearsal

Before production is touched, the complete procedure should be tested once against a copy: export from the new development environment, managed import into a test environment restored from production, assignment of the connection references, and then a check of the critical processes. Only when that runs cleanly is production next.

The export of the existing environment already tells you quite a bit about the scope in advance: how many components are affected and where dependencies to other solutions exist. These numbers turn a gut feeling into an effort estimate. It decides in the end which of the two ways is realistic.