It seems that every company has at least one application built on aging technology and held together by virtual duct tape. Have you been that developer, fighting to upgrade a solution before it breaks? Have you been that business guy making the tough budget decision—maintenance or new development? This post is for both of you.

How did we get here?

• Just make it work now, we’ll fix it later.
• If it’s not adding new value, we’re not investing in it.
• We know it’s a problem, but it’s not a priority

Technical Debt

What is Technical Debt? Many developers would say it simply represents all the code they would fix if they had the time to do it. It’s sometimes described as the gap between making something work and building it the right way.

The term technical debt received a lot of well-deserved attention in recent years. If you don’t maintain code periodically, it has a way of eventually commanding attention, not because code wears out, but because it’s part of an ecosystem of other moving parts and dependencies that continue to change. Sooner or later those changes will expose problems in apps if they are ignored long enough. Sometimes you know it’s coming, but frequently it creeps up on you.

Technical debt comes in many forms and is most commonly just code that developers make work, knowing that there’s a right way and a fast way to get things done. The fast way helps code get out the door to meet a deadline. “The right way” is often postponed for a future release when more time will be allocated to fix things. When dev work gets delayed, it’s sometimes hard to measure the true risk of doing so. From a business perspective, why invest time and money unless the effort delivers clear value (aka – new features)? This is a game we all play to ship code on time and prioritize resources.

Support Lifecycle

When we talk about Technical Debt, it’s important to consider Support Lifecycle. They go hand in hand. As a developer, you might not upgrade code just because a new SDK becomes available, but when it has been deprecated, risk is elevated significantly. For example, when support for Windows XP ended, Microsoft stopped fixing bugs and patching security vulnerabilities. Many customers wanted to continuing using it, because “it still worked.” This is an incredibly risky position to be in since new vulnerabilities are imminent and eventually the changing technical landscape will expose products to threats they were not designed to handle. After support ends, the end user (not Microsoft) absorbs the risk for all issues and when a business system depends on deprecated products, it’s just a matter of time before they are compromised. Being aware of the Support Lifecycle for all the technologies in any solution is critical to planning upgrades on your terms and not under crisis conditions.

Most IT and business teams are able to track the support lifecycle of major products, but ignore more granular changes with developer libraries. For example, .NET went through some major transitions in January 2016 to deprecate older versions and move everyone to a current, supported set of .NET runtimes. Another example is the Azure Storage library which was scheduled to deprecate various REST endpoints this August. The VB6 runtime can still be found all over custom applications and while it has managed a very long support lifecycle, not every runtime and SDK is so lucky. Missing one of these deprecating changes can leave you unsupported or dealing with a costly outages when they stop working.

Consider: Effort and Risk

• Do you know all the component and runtime dependencies of the line of business apps that are critical to your business?
• Do you know what support lifecycle they follow?
• If you had to modernize an application, how much technical debt stands in the way of that effort?
• If an application stopped working tomorrow, what would the impact be to your business?

Real Life Perspective

Imagine a critical line of business application that was deployed into hundreds of worldwide field offices. It’s used by thousands of workers every day and depends on a library that works but is several releases behind. The library vendor releases many updates and fixes over the years but the business app is not updated with them. Over time, the technical debt builds as the amount of work it would take to modernize the application and make it work with current code seems too costly to invest in. The unthinkable happens. A critical security patch is pushed that closes a vulnerability which just happens to be something those old libraries needed to work. Sites are completely offline and business stops. Now the business must choose to ignore the critical patch and run global sites with the risk of exploitation *or* upgrade the application to use a current library and overcome all the technical debt between the last release to get there. This would also involve a prioritized effort to finish code, test software, and perform a global release and migration while business is halted. That effort, performed in crisis mode, is estimated at a multi-million dollar project. It’s a true story and this scenario happens more often than you think.

Premier Support works with Microsoft’s largest and most strategic customers. We see it all—the best and the worst. As diligently as we try to help customers stay in a supported state and get the most from Microsoft technology, we frequently end up getting the call when critical applications are neglected and fail.

Practical Tips to minimize Risk

While most of Microsoft’s Support Lifecycle is published online, it’s a big job to keep track of all the moving parts in your business. Premier can help you stay ahead of the changes and drive awareness through regular Support Lifecycle communications and planning with your organization.

With Premier Support for Developers, your ADM can help assess the dependencies in the applications that drive your business and work with development teams to stay current and align to our technology roadmaps.

For any organization, it’s a good idea to:

• Establish a roadmap and lifecycle for your applications so there is a projected end of life date and/or an established project plan to modernize the code.
• Periodically assess your line of business catalog and ask some key questions:
  • When are the major lifecycle transitions that will impact the application?
  • What are the component dependencies of the application?
  • How big is the effort (time, cost, people) to update the application?

Finally, talk to your developers about technical debt track the work with ALM tools like Visual Studio to eliminate surprises and mitigate risks often and early.

Contact your Premier ADM or email us to learn how Premier Support for Developers can help you minimize technical debt and ensure your solutions stay supported with Microsoft by your side.