Best-Practices for moving legacy customizations into Applications

aaron_damyen · ‎04-03-2014

My instance has been around for quite awhile. And there are many, many customizations done to it using Update Sets (or directly in Prod).

Now with Calgary and the rise of the Application, I would like to start the clean-up. After reading up on the Application wiki pages and how customizations are retained when using Applications, I want to start collecting all those old customizations into an Application (or multiples once I can sort them). Applications are not going away and I'd like to begin to treat our customizations like plug-ins (which will have Application records in Dublin).

I want to know if anyone has experience doing this and some of the best-practices they have found. If you have a process for this, please post it.

aray · ‎05-16-2014

I have a good amount of experience with dividing customizations into applications.

We have applications, and then each of those applications have add-ons on top of that. So our setup is tiered. The application is an application, then the add-ons are separate applications.

Example:

App1 = Cake
- App2 = Icing
- App3 = Sprinkles
App5 = Pizza
- App6 = Peperoni
- App7 = Mushrooms

The first tier is basically all of the main tables. In calgary, my experience is that the best place to start moving something to an application is to start at the table level. When you go to the table editor, you can select "Move to Application" and it will fairly reliably move most of the related things (business rules, client scripts, etc) into the application.

If that's more than you want to do and is too broad of a stroke (for example, say your customizations are to incident) you might have to go customization by customization. In this case you have two ways to do it. One is to find each customization, and choose "Move to Application".

The other option is similar to what you might do with an update set, where you select the Application from the top bar to begin working in that app. After you add or edit the customization (update description to a client script for example) it will pop up and ask you "Move to Application XYZ?"

My advice when doing this is to be extremely disciplined in making sure you are working in the right application as you do your customizations, and do a check of your application records at the end of each day to make sure you (or another developer) hasn't mistakenly dropped a bunch of junk in your application. It's much easier to keep it clean from the beginning, and clean up small mistakes immediately, rather than sort out the mess after the fact.

Good luck!

View solution in original post

aray · ‎05-27-2014

I was out last week so sorry for the slow response -- but I think you're on the right track.

My purposes are different than yours so I'm not the best person to validate suitability for what you're needing, but taking your customizations and turning them to be part of "applications" such as "Aaron's Incident Customization #1" should not be difficult.

When you add something to be be part of an application, you're not really disturbing it as it sits. You're just creating an application record which links that "thing" (table/ui policy/whatever) to your application. Your previous update sets remain intact.

So to my knowledge there is no requirement to rebuild in a clean environment, and then move. If you don't like how it comes out, you can always just delete the application records, and disassociate your customizations from that application, and they will return to the original state of having no application attached.

Best way I found to describe it to my own team....

- Update sets are like "recordings" of what you've changed. When you reapply them, it's just repeating your customization steps.

- Applications are another dimension, it's like putting various "things" in a group. When you want to move those things to another system, you "publish to update set", and it will take a snapshot and bundle up everything in the group as it sits, and create an update set based on current state.

In your case, you'd want to watch carefully how that update set is applied, but I think you would have a cleaner view of exactly what you're moving across. I find application records a bit easier to manage than sorting through an update set.

Hope this helps. You could try it for a small subset of customizations to see how you like it and get comfortable with how it works.

aaron_damyen · ‎10-03-2014

Thanks Andy Ray. Your advice was a big help.

I've begun to move the tables into Applications. The Move to Application... feature catches most of what I need. As a note to others, that feature is broken in Dublin before Patch 4. After the patch, everything works well.

aray · ‎10-06-2014

Awesome -- glad it worked out for you.

Uncle Rob · ‎05-27-2014

Before you do anything, get clarity from your salesreps that all your previous apps are grandfathered into the current license model. The last thing you want to do is start invoking new license costs on stuff you've already been using.