Platform Modernization: Navigating the Build-to-Buy Continuum

Author Details

By Meghan Stiling

Chief Digital Officer

Follow the author:


Content Body

Amid increasing competition and shortened technology life cycles, businesses of all sizes are modernizing their IT platforms and IT systems. Nearly two thirds of respondents to the 2018 Gartner CEO and Senior Business Executive Survey reported that “their organizations have a management initiative or transformational program in place to make their business more digital.”

Accordingly, IT budgets increased by an average of 20 percent in 2019 to support platform modernization and other IT initiatives. This year’s Spiceworks report on the State of IT revealed that much of corporate spending will go toward replacing outdated infrastructure, cybersecurity systems, and supporting digital transformation initiatives.

However, when IT leaders decide to modernize their company’s technology platforms and IT systems, they soon realize the task isn’t going to be a quick fix. For most, platform modernization efforts become more of a journey where no single off-the-shelf solution is the clear path.

If this is a reality for you, consider including custom components in your architecture to build organizational agility into a packaged backbone. Custom components can help you organize your digital transformation into manageable pieces. Starting with API frameworks, or other abstraction layers, can give your business the flexibility and access to data it needs, while you tackle breaking down a large legacy system along a platform modernization roadmap.

Evaluating technology decisions across a continuum of build-to-buy components allows you to take advantage of a packaged core, yet support the differentiated needs of your business, your customers and your employees with custom-built components in your digital transformation roadmap.


Before going too deep into the continuum of platform modernization decisions, it’s important to agree on the factors driving your platform modernization. These factors could include industry, company size, competitors and business goals. Below are a few realities commonly driving these decision making processes.

  1. Performance can’t cope with demand: Systems initially built to support a growing business now strain to cope with daily demand. Batch processes that used to easily complete overnight are now consistently taking six, seven, eight hours or more. Capacity levels once selected based on peak times are the new baseline.
  2. Spending on maintenance outpaces innovation: Your organization is spending too much time and money on patches, backups and troubleshooting software and hardware issues. Your budget includes funding for specialized legacy resources and extended support/maintenance contracts. The opportunity cost of focusing on maintenance is time that could be better spent creating innovative systems that lead to competitive advantage.
  3. Platforms are spliced together by workarounds: People are spending more time working around systems than within them. It takes years of tribal knowledge to understand and execute core business functions. A significant portion of your business logic is duplicated and spread across disparate and unscalable technologies.
  4. Project delivery is not based on business value: You are avoiding or delaying critical projects that support new priorities because of unknown ripple effects. Duplicative phases are built into projects to reanalyze and re-document impacts to processes and interconnected systems.
  5. Security and compliance: Upgrade paths have been abandoned due to customizations, undocumented subroutines and incompatibility with enterprise limitations. Software versions and patch levels are behind and out of date, leaving you at risk for known exploits or security vulnerabilities. You are unable to keep up with requirements needed to comply with a changing regulatory and compliance landscape.

There also can be a less measurable, but equally as real of a motivation to modernize platforms— fear of missing out in a fast-moving business environment that rewards companies that are first-to-market. Software development velocity is increasing and companies that can innovate rather than focus on operations will benefit.

Assessing these motivating factors is just the beginning. The next step focuses on how to evaluate the right new components, optimize your existing environment and assemble it together to make the most effective investments.


Now that you have made the decision to modernize, how do you get there? Large software manufacturers will often sell the promise of buying modernization, but rarely is it that simple. Experience shows that no two businesses are exactly the same, and no single software effectively covers the breadth and depth of every business.

Should you build it all yourself then? Unless software is your business, your organization is likely not setup to support and maintain a complex portfolio of custom applications and development processes. Additionally, you will lose the efficiency packaged products provide to the common central processes existing in most businesses.

How do you reconcile this choice? Don’t treat modernization as a binary buy vs. build decision. Rather, consider options along a continuum of build to buy components assembled together. This will allow you to take advantage of commodity processes provided by commercial applications, satisfy the unique needs of your users and optimize the value that still exists in your legacy systems.


The ideal approach is a bespoke solution along the build-to-buy continuum that combines the right mix of options and flexibility to meet your unique business requirements. Here are four examples to illustrate solutions along this continuum.

Example 1: Consider a commercial enterprise HR solution that functions across multiple geographies.

A software evaluation process shows alignment with the majority of critical business functions in geography A. In geography B, however, governmental regulations present unique requirements that are at odds with the out-of-box functionality. Does this disqualify the purchase? Do you now have to build all the base functionality to account for the unique requirements of geography B?

No, in this case, custom components included at the right locations in the landscape allow you to take advantage of the core HR functions while also allowing for regional variances.

This way, it is not just about buying the commodity, it’s about where to insert a custom component to maximize the organizational agility and fit of these backbone applications. You still receive the efficiencies from the packaged applications, but you can selectively add functionality to meet specific or unique needs.

Example 2: Imagine you’re part of a business that relies on complex reports and analytics as a competitive advantage.

Data is combined from multiple operational systems across their enterprise. Assembly is manual in nature. Should you buy a new operational platform that centralizes all the information into a single location? Or build a reporting and API management platform from scratch?

No, the introduction of an off-the-shelf API management tool allows you to leverage core functionality while also allowing flexibility to create customized APIs, ultimately reducing the manual effort needed to access underlying data.

This abstraction layer will also give you the flexibility to access additional data or add new systems into the ecosystem without negatively impacting operations. Furthermore, this will allow you room to tackle breaking down a large legacy system along a broader modernization roadmap.

Example 3: You’re a technology leader for a well-known brand that deals across several unrelated business lines and industries.

The business has a history of making acquisitions and bringing new companies and their customers under its banner. It also has just moved into yet another unrelated line-of-business via acquisition. The software packages that support this new acquisition provide sufficient functionality but lack visual appeal and branding. Do you need to build a new system from the ground up in order to gain user satisfaction and brand consistency? Or should you try to adapt your current systems to incorporate this new line of business?

Likely not; by skinning the acquired unit’s systems with custom UIs that offer cohesive branding, layouts and design you can retain the existing systems and fill the experience gap.

Legacy or packaged software may meet your functional requirements, but it doesn’t “feel” like a fit for your business, brand or customers. In these cases, you can create custom experiences, UIs and processes around the application’s core. This approach is useful both to supplement a new packaged application that doesn’t quite fit, or to modernize user interaction with legacy solution components.

Example 4: Your company is planning to develop a custom application to meet the needs of a new business unit recently established to improve efficiencies in the organization.

The first focus is to improve the field sales team’s processes and effectivity. The business has a history of developing custom applications and has an established DevOps practice and agile methodology. The recently established product team documented the key product features and is moving to estimation and prioritization. One core feature is the ability to scan and interpret paper purchase orders from the field into the primary corporate systems. Should the development team build a bespoke OCR application? Does the decision to build a custom application need to be abandoned?

No, you should leverage a commercially available OCR tool as part of the overall solution architecture. Leveraging existing OCR technology will allow you to efficiently include the necessary capabilities, and direct its development resources toward integrating the data and developing the unique features of the solution.

Even if your organization is primarily focused on custom development, rarely is it efficient to build every feature or capability. Be sure to break down solutions into feature sets and analyze those features against commercial available tools. Oftentimes you will be able to find a fit for one or more areas and allow your development teams to focus.

Each of these examples illustrate the value obtained by combining custom components with legacy or commercial applications. While there are costs to this strategy related to ongoing maintenance, resourcing and DevOps, deployed strategically, it’s absolutely worth it. The customizations give your business the necessary flexibility and nuance while enabling you to take advantage of existing investments, efficiencies and processes within your organization. This approach supports Gartner’s recommendation that “CIOs should emphasize the ability to combine various digital technologies and techniques in innovative ways to solve their problems,” (2018 Gartner Market Guide for Digital Business Consulting Services).


Once you have made the decision to take advantage of custom components and move to the right on the buy-to-build continuum, it’s important to set your technology organization up for ongoing success. Ensure your teams are prepared to manage and maintain not just the commercial software, but also the custom components.

Commercial software management requires skills related to vendor relations, licensing and upgrade coordination. Custom components require holistic DevOps skills to keep them healthy. Just as with full-scale custom applications, even custom components will require ongoing care and feeding. Changes due to adjacent applications, continued progress along your digital roadmap or ongoing enhancements due to changing business requirements will need to be performed.

By planning for this maintenance and support during the transformational program, however, you’ll put your organization and IT ecosystem in a position to continue to respond to changing business demands. By selecting a partner focused on collaborative development, you can build these skills into your organization throughout the modernization effort. This approach can take much of the organizational stress out of the process, ultimately allowing you to obtain technical autonomy, rather than relying on an agency for ongoing support following the initiative.

The path to platform modernization is rarely a case of build or buy. Instead, to create flexible, efficient, and modern ecosystems, IT leaders should focus on the options available across the build-to-buy continuum. Leveraging custom components at specific points in your ecosystem will allow you to get the most value out of your commercial products, the most satisfaction from your users, and the most efficient use of your resources.

Learn how Nerdery can help through our platform modernization services.

Published on 05.13.19