Re-Evaluating The Reason for Periodic System Freeze

In a typical IT Application Management Policy, there are periodic system freezes, sometimes for mission-critical applications only, but usually for all applications.  This means that in the week or weeks preceding a fiscal month-end or quarter-end, and a week after, no changes are to be made in production systems.  An exception process will require higher management approval from both business and IT application owners.

The main reason was that any downtime, in order to make system changes, or as an unintended result of system changes, will delay or stop critical business processes, such as order processing or closing of accounting books.

In the days of applications hosted in-house, and even today with monolithic ERP systems, it makes sense to freeze entire applications.  Such applications may require entire servers, or at least application services to be restarted, even to deploy a fairly simple change.  In order to reduce risk of applications not starting back up, or behaving improperly after the change, or simply introducing bugs, change freezes should be imposed on the entire application.

With cloud-based applications like Salesforce.com, this policy should be tweaked depending on what is hosted in Salesforce.  For example, if Salesforce handles Opportunity Management and Quotation Management, a freeze must be imposed on objects that support those functions.  However, if it also hosts a custom application, for example, a partner locator, the freeze should not apply to configuration changes related to the partner locator.

Installing packages from the AppExchange should also be allowed if they do not affect the processes that are deemed critical by the organization.  As in the example above, if it does not affect Opportunity Management and Quotation Management, which are deemed critical in closing the quarter, an app, say for example, the EverNote App, can and should be installed, if the business need dictates that the new feature be available in the next quarter.  Applications published on the AppExchange have gone through a Security Review conducted by Salesforce to reduce the risk on all their customers' Salesforce orgs and data.

Here is an example of what isn't allowed: Do not introduce a new required field on a quote two weeks before the end of the quarter, because that will slow down users who have gotten used to completing quotes in a certain way.  Another example that should not be allowed is installing the DealMaker by The TAS Group.  This affects Opportunity Management.  While it is possible to install the app and not show it to any users yet, it still affects the Opportunity object.

It can be argued that any custom Apex code should not be deployed, as the deployment will cause all test classes to execute.  Some poorly written test classes may affect critical processes.  This author recommends that Apex deployment should be avoided during a system freeze.

A colleague pointed out an analogy: like remodeling a house, work can be done in the bedroom downstairs, and the rest of the house is still habitable.  There is no need to shut off the power or the water supply.

In conclusion, the reason for a system freeze in a cloud-based multi-tenant application, such as Salesforce.com, should no longer be about potential system downtime.  Rather, it should be a more business-focused one: system and process changes should not disrupt closing deals in the current period, or chasing revenue, or ensuring product shipments, or anything else that will adversely affect users and customers.