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

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:

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!

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.

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).

Original purpose: Traffic engineering, fast reroute, and VPN services with label-switched paths.

Why it’s still used: Core component in service provider networks, widely deployed, extremely stable.

Deprecation criteria: If you’re ready for Segment Routing (SR-MPLS or SRv6), and your infrastructure supports it, and if you’ve tested interop, migration paths, and OAM tooling, then it might be time to plan the shift. Otherwise, traditional MPLS stays.

Segment Routing offers a range of benefits compared to traditional MPLS, particularly in terms of the control plane. However, it does have some drawbacks. Still, it's the way forward.

Instead of thinking in binary terms (dead or alive), think of a technology’s lifecycle like this:

This mindset enables you to make informed decisions about the technologies in your infrastructure by evaluating them based on environmental needs and practical requirements, rather than following industry trends or hype cycles.

It provides a framework for understanding where each technology fits within your organization's specific context, helping you make strategic decisions about adoption, maintenance, or retirement based on concrete operational requirements and business objectives, rather than relying on popular opinion or market buzz.

A step-by-step framework for network engineers

Let’s say you believe a protocol, platform, or mechanism needs to be retired. How do you go about it responsibly?

Here’s a battle-tested framework:

Ask:

💡 Avoid “because it’s old” as a reason.

Ask:

💡 Sometimes the new tech solves 80% of the use case but misses critical edge features. Know what you’re giving up.

Create a side-by-side breakdown:

💡 If the new system fails more often, needs constant tuning, or is poorly understood by the team, then it’s not a win.

💡 Migrations fail when assumptions go untested. This is where you find the stuff that breaks before it hurts customers.

A great plan includes:

💡 A technology is only dead when your ops team no longer needs it to survive.

The real value in deprecating a technology isn’t just ripping it out. It’s replacing it with something that brings measurable improvement in:

Therefore, it’s not a demolition. It’s a redesign.

You’re rethinking how the network behaves under pressure and how humans interact with it.

If your replacement is just “different,” but not better, you’ve created churn, not progress.

So, no, STP isn’t dead.
OSPF isn’t irrelevant.
MPLS isn’t archaic.

Technologies don’t die because someone tweets they should. They evolve, plateau, or fade based on context. As engineers, our job isn’t to sound futuristic.

Our job is to build systems that are resilient, operable, and aligned with business needs.

If this content resonates, join The Routing Intent newsletter to go even deeper, with hands-on insights, mental models, and career strategies for next-gen network engineers.

Please share your thoughts or questions in the comments. I read every one.