Before You Kill It Off: How Network Engineers Should Think About Technology Lifecycle

In partnership with

1440: Your Weekly Business Cheat Sheet

Expand your business and finance knowledge with 1440. Get clear, conversational breakdowns of the key concepts in business and finance—no paywalls, no spin. Every Thursday, 1440 delivers deep dives, interactive charts, and rapid market rundowns trusted by 100k+ professionals.

Sign Up Today

If You Replace Technologies Like You Switch To a New Phone, You Are Wrong About It

We’ve all seen it:

It’s trendy to dismiss “old” technologies. Declaring things dead on social media feels edgy and forward-thinking, but let’s be real: most of these declarations are shallow and dangerously misleading.

I've seen it on social media, particularly on LinkedIn, people often rush to call older technologies outdated just because they've been around for a while. Again, these quick dismissals are misleading and suggest that people don't fully understand how technology evolves and develops in the real world.

Here’s the truth:

Just because a technology isn’t shiny doesn’t mean it’s dead. And just because something new exists doesn’t mean it’s the right replacement, or even a fit for your environment.

This article is a call for technical maturity.

It’s time for network engineers to learn how to think critically about:

• Why a technology still exists

• When it’s appropriate to deprecate it

• How to select a viable replacement

• And what the real trade-offs are in doing so

Understand the Purpose Before Declaring Death

Before you say (technology) “X is dead,” ask yourself:

What problem was this technology solving?

Let’s take a look at some common “not-dead-yet” examples, and trust me, I am NOT making this up; I saw it!

STP (Spanning Tree Protocol)

Original purpose: Avoid bridging loops in L2 Ethernet topologies.

Why it’s still used: Many access networks and branch deployments still use simple, cost-effective switches without fabric capabilities.

Still relevant for: Interop with legacy gear, brownfield campus environments, and minimal L2 deployments.

Deprecation criteria: Are you running a modern L3 access model (e.g., routed access), or using EVPN-VXLAN with multihoming? If yes, you can probably sunset STP but only with careful planning.

OSPF (Open Shortest Path First)

Original purpose: Link-state routing within autonomous systems for fast convergence and scalability.

Why it’s still used: Mature, robust, well-supported across vendors. Ideal for enterprise IGPs, and even used in many data centers. Plus, it is one of the major players in service provider networking.

Inside the Autonomous Systems (thinking of real BGP use cases here), you need IGP routes to transport the internal BGP (iBGP) sessions among the Loopback interfaces, as well as for the NEXT_HOP path attribute's recursivity.

What will you use instead of OSPF? Static routing? RIPv2? EIGRP? Give me a break.

Your only options are OSPF and IS-IS, really. EIGRP could be used, but since it lacks traffic engineering extensions (either MPLS TE or Segment Routing), it really doesn't make sense to stick with EIGRP, especially in service provider networking.

Deprecation criteria: If your environment has transitioned to full BGP-only routing (for example, in hyperscale or data center fabrics), OSPF may no longer be necessary.

Modern IP fabrics often utilize BGP for both the underlay (e.g., AFI 1, SAFI 1) and overlay (e.g., AFI 25, SAFI 70). Additionally, there are indeed some complications when running OSPF in certain Clos topologies due to the split in Area 0.

Aside from that, if you have OSPF in place, why would you want to remove it in the first place? What benefits do other routing protocols, especially IGPs in this case, offer you? Unless you clearly understand what you dislike about OSPF and know that IS-IS will perform better (there are some valid points here).