Retiring Technology Debt with an Internet-First Strategy

\Tony:  Hello, I’m Tony Mangino from TC2, and this is Staying Connected—where we talk about what really matters to enterprise buyers navigating today’s technology and sourcing decisions.

On our recent 2-part series, we addressed the topic of “technology debt”, both the hard dollar costs and the constraints on innovation and transformation.  I’m joined today by Keith Cook, my long-time colleague here at TC2 to pull on that thread a little further and discuss specifically that transformational opportunity in the context of networking.  The evolution toward Internet First wide area networking can be daunting, but the upside gains in operational efficiency, application performance and sizable cost reductions demand the attention of enterprise customers.  The reality is that the longer you wait, the more expensive and disruptive that transformation and retiring that technology debt becomes. 

Keith:   Hi Tony, it’s great to be back on Staying Connected.  To set the stage, when we say ‘Internet First WAN,’ we mean a network where secure Internet access – DIA, broadband, and wireless – becomes the primary underlay for most sites and apps, and legacy private networks like MPLS are the exception rather than the default.  And, while it is true that many large enterprises have adopted Internet First WANs, it’s not true for everyone (at least yet), so don’t feel like it’s too late.  The reasons to do this are many – agility, resiliency, scalability, enhanced security, and of course lower total solution costs.  As you alluded to, the problem is often one of inertia.  That is, the enterprise has some vision as to the desired end state but no clear path on how to get there – so nothing gets done and that technology debt is carried forward.  In short, there is no strategic, transformational roadmap. 

Tony:  Keith, I agree with you, and having guided countless enterprise customers along this journey over recent years, I think it will be helpful to discuss some of the basic building blocks of these transformations here today.  So, getting right to it…the first thing to do is assess your current WAN environment.  Develop an inventory of all your sites –size, bandwidth, circuit types, redundancy, hardware and all the associated recurring costs for the estate.  Then map application flows (i.e., internal vs. cloud vs. SaaS) and identify critical performance and security requirements (i.e., voice, video, firewalls, segmentation).  Finally, assess your current vendor contracts: MPLS end dates, early termination penalties, renewal terms and the like.

Keith:  That’s right.  And once you’ve done that, it’s time to develop the plan for what your Internet-first WAN will look like.

Connectivity mix varies a great deal, but might look like this.

• DIA for business-critical functions (often dual redundant DIA for data centers and critical sites)
• Wired Broadband for secondary or tertiary links, or even primary links in some cases. We are seeing more and more of that!
• 4G/5G for backup or rapid deployment, or as secondary in some cases

Tony:  At this stage, you’ll need to determine the site types and personas that will help to organize and standardize the connectivity profile.  You’ll want to align circuit types and quantities as well as bandwidth tiers for each site.  Diversity is also key part of this discussion, do you need service diversity (DIA v Broadband v Wireless), supplier diversity, physical path diversity, etc.  This can get really complicated really quickly but it is absolutely best to determine the preferred target environment prior to approaching the market. 

Once you’ve done this, it’s time to select your suppliers — Tier 1 telcos and/or service aggregators are almost certainly in the mix here.  Keith, what’s the best way to go about this?

Keith:   RFP, no question.  For truly transformational initiatives like this there is simply no better way to ensure you maximize your negotiating leverage to drive leading edge pricing, commercial terms and SLAs than through a competitive sourcing program. 

Tony:  Keith, truer words may never have been spoken.

Keith:  The next item may, or may not, apply to your particular situation — it’s the SD-WAN solution that you will use. You may already have one that is deployed in conjunction with your legacy MPLS for example, and it may be fine.  Or it may not be.  If your existing SD-WAN is tightly bundled with your current supplier, I’d encourage you to understand the licensing and exit terms carefully before you assume you can just lift-and-shift it onto a new transport underlay.  If you don’t currently have an SD-WAN solution, you have much greater flexibility, but this should probably be addressed via a separate sourcing initiative.  There are some potential synergies of course, but the SD-WAN “overlay” can absolutely be sourced separately from the internet transport “underlay”.

Tony:  Good point to source your SD-WAN solution separate from your circuits.  Many network transport suppliers have their “preferred” partners, but our experience suggests it’s often best to go directly to the supplier of the solution. 

Keith:  At this point, it’s time to focus on the security posture of your new internet first network.  At a high level, your organization will first need to determine whether a bundled SASE solution or custom solution stack of individual security components is the preferred approach.  A single-vendor SASE solution is generally preferred by organizations prioritizing streamlined operations, consistent policy enforcement, and a holistic approach to network security.  At the other end of the spectrum is the “best-of-breed”, multi-vendor, approach which is suited for organizations with significant existing investments, specific functional needs, and the in-house expertise to manage complex integrations.  Ultimately, decisions on security for your internet first WAN should be guided by an assessment of your specific use cases, current infrastructure, long-term IT strategy, budget, and the available internal resources for deployment and ongoing management.  And of course, this just scratches the surface on the subject of securing your internet first network, but the key takeaway here is to treat security as a first-order design decision, not something you bolt on after the connectivity decisions are made.

Tony: Keith, before we wrap up, let’s talk about execution, because this is where a lot of Internet First programs stall. It’s one thing to design a great target architecture and pick your suppliers, it’s another to actually move traffic and shut off the old network. When you’re helping clients make this real, where do you start?

Keith: The key is to resist the temptation to “boil the ocean.” We typically start with a pilot – maybe one region, a handful of branches, or a subset of site personas. The goal is to prove out the design and the operating model in a controlled way before you scale.

Tony: And that pilot needs to be measured, not just “did anything catch fire.” What kinds of success metrics do you like to see defined up front?

Keith: Exactly – “it seems fine” is not a success metric. Before you start, define what “good” looks like. That usually includes end-user experience for key applications, incident and ticket volumes, failover behavior during link or device outages, and an early read on the cost trajectory versus the legacy WAN. If you can’t show that users are at least as happy, operations is not drowning, and you are on a path to lower total cost, then you’re not ready to scale beyond the pilot.

Tony: The important thing is scalability: standard designs, standard playbooks, and clear ownership between the carrier, the SD-WAN provider, and your internal teams. You want to get to the point where you’re effectively running a factory for site turn-ups and cutovers.  And then there’s the unglamorous bit – turning things off.

Keith: That’s right, and it’s where a lot of value gets left on the table. As you progress through those migration waves, you need an explicit decommissioning and contract clean-up plan so you’re not paying for MPLS ports, access loops, or CPE that no longer carry any production traffic.  Align your migration schedule with contract milestones and make sure someone is accountable for validating billing changes. Otherwise, you’ve built a shiny new Internet First WAN and you’re still paying for the old one.

Tony: Keith, thanks for your time today and for a great primer on how to leave that technology debt in the rearview mirror and get going on your internet first transformation in 2026. 

To our listeners, if you would like to discuss Internet First sourcing strategies, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Keith, me, or any of our TC2 and LB3 colleagues, please give us a call or shoot us an email.

You can also stay current by subscribing to Staying Connected, by checking out our websites, and by following us on LinkedIn.