Best-Practices for moving legacy customizations into Applications

[aaron_damyen]

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.

[aaron_damyen]

I have found that the Application File records also contain the original information.   This information is not retained when creating an Update Set.   Thus, without being able to recreate this information, Update Set information cannot be directly converted to Application File records.   I think that bringing back this original information will require a lot of 'fudging' and may not be as reliable as I want it to be.

If anyone else has tried something like this, please let me know what you did and any results you got.

[aray · Accepted solution]

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!

[jcraneNYC]

I think it's going to be very challenging, if possible at all, to fit legacy application creation into the new method. Do you plan on lifting out individual applications and installing them elsewhere or something? Just trying to figure out the use case.

You could have a clean dev instance and spend some time and copy/paste code and rebuild tables and columns to recreate your customizations as apps. I can't really think of a better way to convert update sets to applications.

[aaron_damyen]

A little history may help clarify, Jon Crane .   Our instance has been around since 2009, we're one of the early customers.   Over the years, we've made thousands of changes and promoted them through update sets from the lower environments to the uppers.

However, as we were testing with the upgrade to Dublin, we found that numerous (about 1600) updates were being skipped because the destination had been customized.   These skipped updates contain details we were counting on.

We've been working with ServiceNow to find out why these updates were skipped.   The first question was, did you customize it?   Obviously, yes, because that's the error message.   But we also found that Applications don't cause this update skipping as the Application is re-applied after any updates.

With this, I was thinking that if I can get the customizations into an Application (or a few of them), then we can begin to reapply the updates to ensure we are keeping up-to-date.

With the introduction of Dublin, ServiceNow themselves have started to put plug-ins into Applications.   That seems like a reasonable practice for probably the same reason, update skipping.   Thus, I'd like to clean up our dinosaur of an environment.

The options of dropping our update sets into a clean environment to rebuild the applications does seem possible, but just very tedious.

Andy Ray, I like the possibility of moving the customization.   I'll check up on that as it would be great for an initial review of customizations.   I've been finding that a lot of customizations are just the updated and updated_by changing on the record.   I'm guessing that some administrator changed something and then changed it back.   These are now worthless customizations and should be removed completely.