What if the IT systems your business depends on every day are working perfectly, right up until the moment they are not?
In this episode of IT Infrastructure as a Conversation, I speak with Chris Bruce, founder of Idextrus, about the hidden technical debt inside mid-sized companies, why uptime should never be confused with infrastructure health, and what IT leaders should be looking for before aging systems become an operational or security crisis.
Chris has spent more than 20 years working with companies across manufacturing, wholesale, retail, consumer packaged goods, software, and e-commerce. His approach begins by understanding how technology is actually used across the business, talking with employees and examining the systems, dependencies, security controls, and processes operating behind the scenes.
One of the most dangerous assumptions Chris encounters is simple: "It just works." A server may have been running for years, but if it has not been patched or properly reviewed, that does not necessarily make it stable. Companies can also have business-critical systems that nobody fully understands, infrastructure maps that no longer exist, former employees whose knowledge was never documented, shared credentials, excessive permissions, and legacy applications that everyone is afraid to touch.
We discuss the different forms of technical debt that infrastructure teams need to identify, including dependency debt, credential debt, documentation debt, and years of deferred upgrades. Chris explains why documentation can become one of the biggest infrastructure risks when the only person who understands a business-critical system leaves the company.
The conversation also provides a practical framework for deciding what to do with legacy technology. Should a system be modernized, integrated with newer platforms, isolated while a migration plan is developed, or finally retired? Chris explains how business value, security exposure, architecture, dependencies, and maintenance costs should influence that decision.
Cloud migration is another major theme. Simply moving an existing workload from an on-premises environment into AWS, Azure, or Google Cloud does not fix the problems already inside it and can make infrastructure more expensive. Chris explains why successful modernization begins with understanding what should move, why it should move, and whether the underlying architecture needs attention first.
We also examine the AI readiness gap. As businesses introduce AI agents, automation, IoT, and increasingly connected applications, weaknesses in data quality, infrastructure, security, and system architecture can become more visible. Every new integration can also create another potential attack surface.
For CIOs, infrastructure leaders, IT teams, and mid-sized businesses planning cloud modernization or AI adoption, Chris offers a practical infrastructure health check. Review your external attack surface, patching processes, software lifecycle, access permissions, backups, and system dependencies. Most importantly, test whether the business can explain how its critical systems connect and what would happen if one of them failed.
This conversation is a reminder that infrastructure resilience is not measured by how long a system has managed to stay online. The better question is whether you understand what is running, who has access to it, what depends on it, how quickly you could recover it, and whether the infrastructure you have today is ready for what the business wants to do tomorrow.
Useful Links
00:00:00 Neil: So thank you for joining me on the podcast today. Can you tell everyone listening a little about who you are and what you do?
00:00:07 Chris Bruce: Yeah. So my name is Chris Bruce. I've, uh, I spent the greater part of over twenty years working with midsize companies in wholesale, retail, consumer packaged goods manufacturing. Uh, but not as an employee. I've had, I've had my own business for this whole time. Uh, and I've really positioned myself as a technology partner that companies call when they see that there's a gap between where they are and where they need to be, and that becomes impossible to ignore. Uh, and at that point, my job is to, to look at what's actually happening in their infrastructure, security posture, their systems, and, uh, and to put together a fix, put together a plan for getting them, uh, you know, successful, making sure that things aren't going to break, uh, or if they are going to break, we can take care of it in quick order. Um, and, and do all of that, especially nowadays before we move them into the cloud or any AI things.
00:01:05 Neil: Wow. I mean, two decades working in the industry there. You've seen everything from, uh, mainstream internet going crazy around the world and we've had what, um, cloud and digital disruption mobile. Now a, I, I've got to ask, when you audit an IT environment for the first time and you've got all this experience behind you, what are the patterns that you see again and again tell you if the infrastructure is creating business risk, and even if it appears on the surface that everything is just working fine, what do you look for?
00:01:41 Chris Bruce: Yeah, that's a great question. There's there's several patterns that I find all the time. There's the classic one is the it just works. Yeah. Um, so people, uh, companies are happy to, because they need to be, they need to say that everything works. So they need to sell. Um, but they likely they've had systems that haven't been touched in years. Nobody's had a reason to touch them. And, and they, they equate uptime to health. They are not the same. Um, and, uh, you know, like a server that's running for years without a patch, it's not stable. It's just undiscovered. Um, so that's one, two. Nobody, nobody owns the infra infrastructure map. Um, they don't know how things connect. Uh, when you ask them about, they, they just kind of shrug and and that right there points to a risk for me. Um, then third one is, uh, like the security theater. They've got a firewall, they've got SSL, but there's a whole bunch of other stuff that's just wrong. Headers aren't configured correctly. The certificates all whack. Um, there's not, they don't subscribe to third party audits. Um, they just basically audit themselves. Um, and then the last one is, is, um, you know, what I call the canary that nobody watches. It's like, uh, there's, there's something in the system that everybody in the business knows is, is really fragile. And it's often the one thing that the, that the whole business runs on and nobody wants to touch it. Yeah. if they've not done a security scan and there's all these headers and configurations and everything went wrong are wrong. It's typically, um, culture driven. It It's this top down. Nobody wants to do it, so nobody does it.
00:03:27 Neil: Yeah. Oh, I'm getting flashbacks from my IT past there. It is so true. And getting downtime on some of those tier one applications that everyone doesn't want to go down for a second is so difficult. And many midsize organizations, as a result, continuously delay infrastructure upgrades because as you said, nothing is broken. It just works. But from your experience, what hidden technical debts tends to cause maybe the biggest operational and security problems further on down the line? And how can it leaders that are listening, that are maybe nodding in agreement to everything we're saying, how can they better spot some of these warning signs earlier?
00:04:07 Chris Bruce: Uh, well, I'd like to think there's several types of debt. Um, there's, there's debt of dependency. So these are systems that were integrated several years back. Um, and nobody knows what breaks if you touch them. Um, so because they don't know what, what, what goes on down that line. Uh, this is where modernization just goes to die because those things just, they can, it's too often, sometimes these dependencies might be, uh, so insecure, but but they don't know how to update it or the company has gone away or who knows what. Uh, there's also credential debt. Of course, in any company, people leave, uh, they share passwords because it's easier just to share a password or they create an account that nobody remembers creating. And, uh, and then they've, they've, they've created these permissions. And then when you revoke it, it breaks something, um, like, which basically falls right into the third type of debt, which is I think the worst one, which is documentation debt. This one haunts every business, uh, myself included. Like we are constantly on my team to document, document, document because, uh, It's the worst debt. Uh, technical debt is not code. It's documentation. Uh. So what happens is I've seen this so many times when, when a person leaves a company and they're the only person who know how to how something worked and now they're gone. And they and then I talked, I talked to the, the replacement who calls me up say, okay, we got this system you guys worked on and blah, blah, blah left. And, uh, how does it work? I'm like, do you not have documentation? Um, so that's the dependency credential documentation. That's, and then the, the last one really is like just deferrals of upgrades that just keep on compounding. Uh, and, and the question I think you said is how, how, um, how it leaders can spot this. It's quite easy if they, if they just look at their, at their, uh, accounting, what they're spending their money on. Um, if more than forty percent of their, of their work is spent maintaining versus actually building. They have technical debt.
00:06:26 Neil: Yeah. And again, getting flashbacks there. Nothing worse than coming across that tech note from twenty twelve with somebody's name who was long gone. And then you might see version three, five, nine and from other people that have added things on to it and trying to make sense of it all is so difficult. And of course, legacy systems like this often remain in place because they do actually support business critical processes. And I've even seen a server on a chair in a server room named after an X I T members mum, but nobody knew exactly what it did, so it just stayed on.
00:07:00 Chris Bruce: Don't touch it. Just leave it there. Don't even look at it.
00:07:05 Neil: I mean, how do you decide whether a system should be modernized, integrated, isolated, or even finally retired? And again, what technical factors influenced that decision? Because it is a daunting prospect. And I've got a few examples there and people will have even crazier examples. I know, but, uh, yeah. Where would you begin with this?
00:07:24 Chris Bruce: Yeah, that's the, the classic four option framework, right? Modernize, integrate, isolate, retire. Like what do we do here? Um, so I look at it, um, and I, I, I suggest to clients to modernize, um, when the current systems that can support their core business model, um, they're actively used, um, and the underlying architecture can be brought forward without a full rebuild. Essentially the business logic is good. The, the platform is the problem that, that, that's, that's an idea where you can just modernize it. Um, integration, uh, is like when the system works, uh, but it sits in an island and can't talk to anything. It's very, very common around ERP backends. Um, where we've done many things where we've moved companies from like old as400 mainframes into, you know, sage or epicor or whatever the, some of the, the modern, more modern ERPs. I find that nobody really likes their ERP anyway. Um, but you have to integrate with them. So if it's, if the ERP is solid, you can integrate with that. Uh, I think that's a good idea. Um, isolate, um, just your, your, uh, your example of the server sitting on a chair of somebody, somebody's name on it. So isolate that, put, put a wall around it, limit its attack surface. Um, create a path for migration for what you're going to do. Somebody should be looking at that. Um, but again, to your point, it's really important to find those weak things and isolate them. Um, as a temporary state, not as a strategy. It's just for now we're going to isolate and then retire is, is the, is the hardest one to get agreement on because there's always somebody who's going to say that they still need it. But it's typically when a system is, it's no longer used, it's going to cost more to maintain than it delivers. Um, and, or, and, or there's a security, uh, liability there and there's no path to, to remediate just to retire and replatform.
00:09:32 Neil: one hundred percent with you and elsewhere. Security audits, they frequently uncover issues that have existed for years without anyone noticing. Everyone gets nervous when that audit is taking place. You mentioned security theater earlier. What goes on underneath that? But without naming any clients, you've had a lot of time in the field, picked up a few war stories. What are the most common vulnerabilities that you encounter and why do they persist, and what are the practical steps infrastructure teams maybe should be prioritizing first?
00:10:04 Chris Bruce: I'll pick that apart a little bit differently. Why do they exist? Because, um, the bad guys just keep getting worse. So, uh, and I mean that, uh, there, it's secure today. It might not be secure tomorrow with nothing changing except for the way that people are looking at things. So, uh, the quick, the most common ones, like, uh, security headers, if they have a website, uh, and they've not configured HTTP security headers, like, um, content security policy, X-frame-options, h s ts, etc. they're free to implement. They're not necessarily easy to implement and they're kind of like voodoo people don't really understand. content security policy especially is a, is an expensive one to implement, but it can do a lot for you. people don't really understand that. and I think if they did, basically this says, here's the only things that we're going to allow in and if it doesn't exist, but people just say, well, let's allow everything in and then we'll shut down when things start happening. It's easier to do that, although it's whack a mole. they might have, configuration issues. That's another one, with, TLS, SSL, they're using as a TLS is. I think it's, one point two now, and they might still be on one point zero, one point one. Um, it's there, but it's not configured correctly. very common one is, uh, is, uh, like unpatched systems. So, uh, if you do a security scan, you'll, you'll. It'll tell you your CVEs or your common vulnerability vulnerabilities and exposures. They may be public for months or years. And it's not very difficult to find out what those are and what your percentage, um, of exploits that have happened on each. and then, the over permissioned access, this is a very common one. And I touched on it a little earlier with, sharing passwords or giving admin rights to people who don't really need them. Um, the, the cloud, one of the cloud principles that we've adopted here for years is the principle of least privilege. Do you need to have access to this? I have people on my team who work in the security side of my team, who don't have access to every system, because they just don't need it. Yeah. And if they and if they do, they'll ask me and then I'll set up something just for what they need. Uh, and then the last one be, uh, you don't have a way of measuring what's happening. Uh, you don't know a vulnerability because you're not, you're not alerting yourself when things happen. You don't, your software hasn't got something in it that says, here's what's going on. You're not watching. Um, and those, those five things I think are the most common.
00:12:45 Neil: And cloud migration is also something presented as the obvious next step in many scenarios, but the reality is typically much more complicated, especially in present day when you throw AI into the mix too. But what separates organizations that are successfully modernizing their infrastructure from those that just keep moving those existing problems into the cloud or move moving stuff around rather than doing anything about it?
00:13:11 Chris Bruce: Well, yeah, you said it right there. It's the lift and shift. Yeah. They just they just say, oh, we have to move it into the cloud. Let's take it from a shared or an on prem system and move it into AWS or Azure or Google Cloud or whatever it may be. Um, and they just basically look at it, pick it up, move it, drop it, and go bam. That causes a raft of problems. Um, typically the problems that they had here are not solved by going to the cloud. And actually what will happen is almost for sure it'll just become more expensive.
00:13:44 Neil: Yeah.
00:13:45 Chris Bruce: Because cloud is cloud is reasonable. If uh, from a cost perspective, if you, if you basically optimize it, if you just drop things wherever you want to drop them, you're not going to find it. So, um, the smart companies, the organizations that successfully modernize, they do an audit before they migrate. So they know exactly why they are moving. Uh, they accept that it's part of business transformation, not just an IT project. So you have the CFO is in the room, understands that, okay, we're going to have this potentially existing cost, but it's because we've taken these things out of the problem areas. Um, and often they don't migrate everything at once. They identify low risk, uh, or the lowest risk, highest reward, uh, workload and move that first and test and just kind of iterate. And then, and then, like I said earlier, they rightsize, uh, typically you in cloud, you would overprovision out of the gate and then measure over after the first month or two is done and then start to, to rightsize because so, so you get your costs down. Uh, it's not a destination. It's an operating model, I like to say.
00:15:01 Neil: And looking at your work, one of the things that stands out is it spans manufacturing, distribution, software development and e-commerce. And these are all areas where availability, performance, etc. all directly impact revenue. So how has the role of infrastructure architecture changed when we're starting to add things like AI workloads, automation agents, and increasingly connected business systems, all placing more demands on network storage and compute resources? It feels like quite an overwhelming time to to be alive and be responsible for this stuff. But what are you seeing?
00:15:38 Chris Bruce: Yeah, it it's kind of dangerous, isn't it? This is a this is a loaded question. Uh, Neil, I, I, um, I, uh, I certainly, um, you know, just in our experience, uh, when you give automation's AI workloads, when you throw these things at systems, they're going to, they are typically going to operate at X factor faster than humans could. Yeah. So what will happen is just it'll exponentially expose problems. Okay. So your infrastructure, um, you need, uh, like, like AI workloads they require. Well, they don't require, but you're going to find problems if you don't have clean, accessible and well structured data. Mhm. Most midsize organizations do not have it, believe it or not. Wow. They their data is their data models are not great. There's no relational, uh, structure in it. Um, and now when now you throw AI and it's, it's got to try and, um, it's got to try and fix from the logical AI brain what may not may be illogical in your business. So that, uh, so that really, um, and that like these kind of things are like availability, availability and performance. They sit on your bottom line and now you have systems that you've put in place that are going to expose these problems. Um, you got latency expectations. So you have like internet of things, internet of things, real time inventory, um, automated procurement procurement, and again, uh, this, this, these systems will expose any weaknesses there, um, your security service expansion. So every integration point has now become an attack surface. Uh, and the more connected you are, the more these points exist. Uh, AI will expose that automation will expose that. And then I find that there's what I call the AI readiness gap companies, which is what you're really talking to companies here that aren't really ready for AI, but just want to get there because somebody above is saying, we need to get into the AI game, but they haven't looked at their whole systems. They haven't they haven't made sure that the underlying infrastructure has been audited, fixed, Altered to allow these things to really work.
00:18:12 Neil: And I'd love to give everyone listening a valuable takeaway here. Let's say somebody found our conversation having discovered that there's going to be a health check in their organization on the horizon. If you were to perform a health check on an enterprise tomorrow and look at the infrastructure, what are the the areas that every CIO or head of infrastructure should be reviewing regularly to reduce risk, improve resilience, and and make those future technology investments with extra confidence. Anything that you'd advise there for, for those people listening?
00:18:45 Chris Bruce: Yeah, for sure. It's, it's pretty easy to, to monitor your external attack surface. There's run a scan on everything with public facing presence, um, security headers, SSL configurations, ports, DNS records. You can usually run these in about an hour using various tools. Um, and see what's going what, what's happening there? Um, I would. Number two, I'd say, uh, make sure that you're patching your software regularly. Um, and when I, when I do this, I, I basically take a look and I say, okay, here's all the, here's all the third party systems or here's the underlying OS or the underlying framework that is out of, out of life. And so you have to do something. Um, the easiest thing, one of the easiest things to do is, uh, is to talk to your staff and check, make sure you have a solid, um, access hygiene, you know, who has access to what, when was the last time you audited that or are you keeping them? Keep a spreadsheet, open up a spreadsheet and say Bob Carroll, blah, blah, blah. And here's all the access and who has access to what. So that if this person leaves, you can remove it because often that doesn't happen. Um, backups. A lot of companies say I have backups and I say, okay, well, how do you, uh, how do you implement a backup? Um, and they're like, uh, we haven't tested that. Okay. We'll test that. Uh, and if and if and if a business can't, like, write out on a whiteboard in fifteen minutes, their, their dependency map, how everything's pointing, then they've, they've got a problem. They're just flying blind. They just hope things happen. Right.
00:20:23 Speaker: Do you need AI agents that you can trust? Well, with an AI data layer providing real time connection within your data platforms, you can trust your agents to provide accurate solutions. So scale your business by trusting your Agentic AI accurately getting the work done for you. Trust its capabilities with Denodo, and you can do that by simply visiting Denodo dot com to learn more.
00:20:50 Neil: Well, I think so much of what you've talked about today will resonate with people listening around the world, both in tech teams and for business leaders as well. And for anybody interested in maybe carrying on this conversation that we started today, maybe share a few of those war stories that we all have. Where would you like me to point everyone listening?
00:21:10 Chris Bruce: Yeah, they can just go to Chris Bruce dot me, Chris Bruce dot me, m e and, uh, that's where I've got pretty well. I write about, uh, things there. I, I link to my company's site as well. Um, and that's, that'd be probably the best place to find me.
00:21:28 Neil: Oh, so well, so much I love about what you do. I think, uh, when we first got started talking, you said most tech consultants show up with a proposal. I show up with questions. I absolutely love that. And I can't thank you enough for coming on here and sharing what you find when you audit a mid-size company's tech stack from the outside, the kind of businesses where the kind of patterns where a business thinks it's fine, the data says otherwise, and what the smartest operators do before it can become a crisis. This is the kind of stuff that's really valuable. So I'll add links to everything that you mentioned there. I encourage people to connect with you, but thank you again for sharing your story with today. I really appreciate it.
00:22:08 Chris Bruce: Awesome. Great time. Thanks, Neil.