Configuration vs Customization: Key Differences to Consider

I recently sat down with Jason Robohm, the Field CISO from CyberOne Security, and had a very detailed conversation on the conceptual merits and pitfalls of customization versus configuration. Most customers want and need a solution that meets their exact requirements. However, the more complex the requirements, the less likely it is that a commercial off-the-shelf (COTS) solution is going to come out-of-the-box meeting their business needs. To meet their objectives, the software must either be configured or customized, and depending on the solution, only one option may ultimately be available to meet their needs.

While the topic may sound a little obtuse up front, the real-world implications of this decision when deploying a new solution or migrating to the cloud could be showstoppers—or expensive lessons—if they are not fully understood by your organization. Depending on which option you choose (customization vs configuration) and the specific circumstances of your implementation, making the wrong choice could expose your organization to hidden costs, added risk, and increased future effort.

In this blog, I’ll recap our conversation about the pros and cons of customization and configuration, the most important things to consider when choosing between them, and the solutions that support one method or the other.

What is the difference between software configuration and customization?

To unpack the concept behind customization versus configuration, let’s now define each term:

• Customization: The ability to modify or enhance a product to meet desired objectives. This can be achieved by using supported (or unsupported) methods to implement changes and functionality that are not provided out-of-the-box by the manufacturer. This can include custom code or third-party add-ons that perform desired functions.

• Configuration: The ability to alter a solution via a user interface, configuration files, command line, etc. to change runtime behavior and attributes to support a business or compliance requirement. Configuration changes are typically supported by the manufacturer, or it will be clearly stated when they are not supported and have the potential to introduce undesirable outcomes. Configuration changes generally do not have any custom code to implement, nor will they require a software developer's kit for implementation, as would be required for customization.

Cloud vs on-premises: Does implementation change the need for customization or configuration?

In years past, organizations typically deployed enterprise solutions on premises and customized the solution to meet business objectives. The configuration of the solution was implemented based on business policies, but the customization allowed it to be tailored as best as possible to established workflows, use cases, and jobs to be done.

Today, consider the cloud. Customization of cloud SaaS solutions is rarely available, and if it is, it may inhibit upgrades based on the customization you may have implemented. While some SaaS vendors allow extensive customization, major changes in their platform often require a complete code review of existing customizations to ensure the upgrade will be successful and that intended changes actually will “hold” in the latest versions. Ironically, most SaaS solutions do not allow extensive customization in order to avoid this problem, and any changes are considered feature enhancements. This does not include any configuration options that may be a part of the SaaS solution, unless the functionality is specifically depreciated or enhanced between versions.

The problem comes when organizations who are continuing on their digital transformation journey attempt to move their on-premise implementations into the cloud. Legacy on-premise implementations that have been customized (not configured) rarely can be migrated to the cloud without extensive, expensive, and complicated rework—unless you cloud wash the entire implementation in a private cloud environment. This is because most modern SaaS solutions do not allow extensive customization in mult-itenant environments similar to the individual customization when software is installed on-premise.

Modern SaaS solutions have predefined workflows, preset configurations, and software development kits designed to enhance the solution, but not necessarily customize them extensively to change workflows and add functionality. When upgrading from a legacy system, organizations must grapple with either changing their workflows to meet the SaaS solution’s implementation, or compromising to some middle ground in order to make the solution work. The customization that worked on-premise probably does not exist in the cloud, and unfortunately, it may not even be possible to recreate. This is a hard truth and is way outside of the bounds of any configuration that you may implement.

How do you know whether customization or configuration is best for your business case?

Since choosing between customization and configuration can have such a stark impact on your organization, it’s important to consider these important questions:

When should you choose customization?

Organizations that need technology and software solutions that meet unique business requirements and use cases that cannot be obtained out-of-the-box should opt for customization. This also implies that the business is not flexible enough to change its behavior to meet the workflows of a given solution. While some SaaS solutions allow extensive customization, this is not the norm and may be just as problematic as customizing on-premise technology.

When should you choose configuration?

Organizations can leverage configuration changes to meet individual business requirements when features or workflows are supported with, figuratively, the “flip of a switch”. Typically, people think of these as “Settings” for an application, and they can exist on premise or in the cloud. Realistically, SaaS solutions prefer to provide features via configuration settings so every client can leverage them, in contrast to customization, which is unique per client.

What questions should you ask when planning a migration to the cloud?

The next time your organization considers another project to move to the cloud, remember customization versus configuration, and ask the following important questions:

• What customization has been done to the solution to meet internal business objectives?
• Can customizations be replicated in the cloud without changing existing workflows, required jobs to be done, and use cases?
• Do the on-premise configuration settings have equivalent functionality in the cloud?
• Is the business using a third-party solution to enhance customization?
• What is the effort to migrate customization to the cloud? What are the costs?
• What expertise (internally or through a partner) is needed to recreate any customization?

Conclusion: Choosing between customization and configuration

The decision to opt for either configuration or customization for any solution will have profound implications for any business moving to the cloud. My conversations with Jason demonstrated that even the simplest solutions on-premise can have extreme hidden costs when moving to the cloud if these considerations are not addressed up front. And with today’s rapid adoption and expansion of cloud, multi-cloud, and hybrid cloud systems, it’s critically important for organizations to incorporate customizations and configurations into their plans when moving to the cloud.