Tech debt: every company has it – and it drastically hinders innovation if left unchecked. The vast majority (70%) of organizations say tech debt significantly impacts their ability to innovate, with many spending roughly 30% of their IT budget and 20% of their other resources in an attempt to manage it. 

You can think about tech debt in the enterprise like lead pipes or asbestos in an old house: it’s not visible from the outside, but it can be insidious and harmful nonetheless. And the longer a company has been around, the more this debt compounds.

Over the years (or decades), enterprises accumulate either custom, home-grown, or various packaged applications that they tailor to fit their unique needs. As the business evolves, new requirements are often built on top of legacy workflows rather than taking the effort and doing a wholesale redesign, causing companies to rack up significant tech debt. What feels like a wonderful near-term decision turns into a long-term albatross. When you peel back the layers, it’s not uncommon for long-standing enterprises to have code dating back decades underpinning their critical operations.

The result? Innovation slows to a crawl. Making even small changes to existing systems becomes expensive and cumbersome since years of customization create complex dependencies, undocumented logic, and fragile legacy code that engineers must carefully navigate (and often the original authors of the code have long since moved on). This eats away at precious time that could be spent building new capabilities to help the business stay competitive. In addition to hindering innovation, security suffers. Organizations with significant tech debt experience up to 50% more security incidents.  

An enterprise’s knee-jerk reaction to these issues might be to modernize its systems across the board; migrating workloads, refactoring applications, and updating infrastructure for cloud and hybrid environments. But it’s crucial to take a strategic, measured approach (you don’t need to tear down the whole “house”).

Similar to how it’s not recommended to start sanding away at asbestos ceilings that are in good condition, companies shouldn’t upend their legacy systems just for the sake of modernization. What they should do is determine where different workloads need to run based on their stage in the application life cycle. This is the key to managing tech debt and accelerating innovation.

Here are some general rules of thumb for applications at various maturity levels:

Stage 1: New applications

New applications are best suited for beginning their life in the public cloud. The early stages of the application lifecycle are characterized by constant change, unpredictability, and an abundance of experimentation. As engineers build, test, and iterate on these apps, they’re simultaneously attempting to establish product market fit and whether people will actually use and find their app helpful. 

If an organization tries to do this on-premises, they’ll quickly run into barriers around infrastructure, security, and resources. The public cloud provides the fast provisioning and flexible infrastructure engineers need to build apps quickly without the friction and constraints associated with on-premises. 

Stage 2: Established (but scaling) applications

Even after a company has built an app and established product-market fit, some degree of uncertainty remains. It’s often unclear how much time people will spend using the app and how quickly its user base will grow, making resource demands difficult to predict.

For this reason, running applications in the public cloud is still the most practical option from a scalability standpoint. Only the public cloud can provide the on-demand compute and resources necessary if your app suddenly jumps from 100 to 50,000 users in a matter of days or weeks. 

Stage 3: Steady-state applications 

For most applications, once adoption has reached steady state, its usage is generally predictable with minor deviations. At this point, the public cloud is no longer economically efficient for running the workload, and it makes sense for organizations to bring things back on-premises so they can run their applications cost-effectively on dedicated infrastructure.

The exception for this is applications that are exceptionally elastic and experience significant spikes in usage patterns around certain seasons or times of year (e.g., tax preparation apps around tax season). During these periods, enterprises might opt to provision additional resources from the public cloud to keep costs in check and meet dynamic compute needs. 

Mobility is crucial for unlocking innovation

The innovation journey starts in the public cloud and usually ends up back on-premises, but as noted, companies may need to leverage public cloud resources periodically. This makes mobility essential. Enterprises must ensure their workloads are portable and their data is available both in the public cloud and on-premises from the start. 

Mobility is only becoming more crucial as organizations increasingly adopt AI: they need the ability to seamlessly move their data and workloads between environments. For example, model training must take place in the public cloud, but inferencing will often occur closer to the edge. Furthermore, the data companies use to train AI models may not be available in the public cloud, so they need a way to access that training data without continuously moving massive volumes of it across networks.

Running applications where they’re most efficient and ensuring data and workloads can move freely across environments is the key to mitigating tech debt and unlocking new levels of innovation – especially as AI continues to proliferate. Just like maintaining an older home, progress comes from knowing what to preserve, what to repair, and what to rebuild, not tearing everything down.